Client-side schema

[alex-dixon]

Starting assumptions:

1. We currently derive the cardinality and uniqueness of attributes from a Datomic schema that only covers facts backed by persistent storage
2. For data that is not persisted, there is a need to insert facts for an entity where more than one value is associated with an attribute (e.g [1 :some-list "a"] [1 :some-list "b"]).
3. All facts are enforced as one-to-one by default
4. Maintaining separation between client-side data and persistent data is beneficial because it allows us to write facts to a database
5. It is not necessary to enumerate every client-side fact in order to separate them from persistent facts so long as we know the persistent attributes

Assuming the above, proposing def-tuple-session receives a list of one-to-many attributes.

[alex-dixon]

Suggest rename defsession's :schema option to :db-schema and add :client-schema.

Client schema could be Datomic-style schema or our own syntax. Which we choose seems less important than implementing support for the feature as others will be able to conform any schema definition to what we expect to receive.

The simplest expression would be [[:attr :one-to-many] [:attr :unique-identity] [:attr unique-value]]. That may make it cumbersome to expand in the future, say if we wanted to support more schema enforcement than just uniqueness and cardinality, e.g. component or even types.

A map syntax offers greater flexibility:

{:attribute :my-attribute
 :cardinality :one-to-many}

Compared to Datomic's:

{:db/partition :db.part/user
 :db/ident :my-attribute
 :db.cardinality :db.cardinality/one-to-many}

[alex-dixon]

Added #63