From 3174a5120e4ea66f59347ddbb3c4307ec80a4acc Mon Sep 17 00:00:00 2001 From: Richard Newman Date: Wed, 19 Oct 2016 09:05:58 -0700 Subject: [PATCH] Updated Proposal: application schema coordination and versioning (markdown) --- ...application-schema-coordination-and-versioning.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/Proposal:-application-schema-coordination-and-versioning.md b/Proposal:-application-schema-coordination-and-versioning.md index 028e426..66dfe5e 100644 --- a/Proposal:-application-schema-coordination-and-versioning.md +++ b/Proposal:-application-schema-coordination-and-versioning.md @@ -22,10 +22,14 @@ One is "head in the sand". If your vocabulary doesn't change, or only grows new If your vocabulary changes, however, you will need a way to evolve it using the primitives available to you: altering attributes, renaming idents, and retracting and transacting schema fragments and data datoms. -One approach to doing so is to track some kind of version identifier outside of the datom store. This is straightforward, but prone to error when the datom store and external version identifier don't change together (*e.g.*, when a database file is restored from backup). +The first step is to decide *when* to evolve the schema. + +One practical approach to doing so is to track some kind of version identifier outside of the datom store. This is straightforward, but prone to error when the datom store and external version identifier don't change together (*e.g.*, when a database file is restored from backup). Another approach is to track the version identifier inside the datom store itself. This is more foolproof, but requires vocabulary for versioning. +An application might also directly inspect the schema to come up with a migration plan, but this is likely to be error prone and inefficient. + ## Multiple applications with disjoint schema @@ -35,6 +39,8 @@ These applications can entirely pretend that the other application doesn't exist [:find ?x :in $ :where [(fulltext $ :any "some text") [[?x]]]] ``` +This should be viewed as a strength! + ## Multiple applications with read-only interrelationships @@ -60,11 +66,11 @@ Schema names and versions are added or updated as schema fragments are transacte Applications should ensure that no attribute is present in more than one schema fragment; an error will be thrown in that case. -These pieces of metadata are themselves stored in the datom store. Applications can listen for changes in order to pick up new vocabulary added by other applications accessing the same datom store. +These pieces of metadata are themselves stored in the datom store. Applications can listen for changes. In response to changes, they can pick up new vocabulary added by other applications. The API exposes operations: -- Check whether this schema fragment is at this version. This allows for read-only applications to adjust their behavior accordingly. +- Check whether this schema fragment name is at this version. This allows for read-only applications to adjust their behavior accordingly. - Ensure that this fragment is at this version; if not: - Create it if needed. - Optionally, attempt to automatically transact the difference between the two schema fragments. For example, an attribute with `:db/cardinality :db.cardinality/one` can always be safely altered to `:db.cardinality/many`.