From bf5e9cd597a51ca3dec60b4532d55146ce123040 Mon Sep 17 00:00:00 2001 From: Richard Newman Date: Mon, 18 Jul 2016 15:27:29 -0700 Subject: [PATCH] Updated Consumer API (markdown) --- Consumer-API.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Consumer-API.md b/Consumer-API.md index c32a7d0..098bb4b 100644 --- a/Consumer-API.md +++ b/Consumer-API.md @@ -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