Updated Consumer API (markdown)

Richard Newman 2016-07-18 15:27:29 -07:00
parent 2fd6bd4d99
commit bf5e9cd597

@ -8,8 +8,8 @@ This is a **draft** for discussion purposes.
* Checking that your application schema is congruent (that is: if you assert datoms based on that schema, everything still makes sense) with the database schema set should be relatively cheap. This will be done on each startup.
* Concurrent consumers within the same process — *e.g.*, browser add-ons — should be aware of each other's schema changes.
* Extending a database with new attributes should be easy, routine, and cheap.
* Upgrading schema fragments in certain directions (e.g., enabling or disabling indexing) should be possible.
* Upgrading schema fragments in other directions (e.g., changing cardinality) should be possible with some effort — *e.g.*, by providing a transformer function that takes the current schema and transaction log and fills a new transaction log, allowing Datomish to rebuild the database to match. This is expected to be expensive and requires coordination with other consumers, and is thus not recommended.
* Upgrading schema fragments in certain directions (*e.g.*, enabling or disabling indexing) should be possible.
* Upgrading schema fragments in other directions (*e.g.*, changing cardinality) should be possible with some effort — *e.g.*, by providing a transformer function that takes the current schema and transaction log and fills a new transaction log, allowing Datomish to rebuild the database to match. This is expected to be expensive and requires coordination with other consumers, and is thus not recommended.
## Example in modern JS