I'm thinking about how to best handle schema migrations

datomic transactions are idempotent so as a default one could install their schema on startup every time

but just because datomic will only transact new values does not mean that updating the schema without some sort of versioning system is harmless. specially, some attribute changes require altering data (e.g. changing the type of an attribute).

so along with an installs property that list the attributes to install, it's likely necessary to require a schema name and version to serve as metadata for tracking schema changes.

{:name :my-schema
 :version "1.0"
 :installs [#attr {:user/username :db.type/string]}

To reinstall schema attributes, the use just has to up the configured version.

now, regarding migrations, I considered requiring the prior version, i.e. :version-before "1.0" so that we can know whether it is necessary to run a migration. but that might be unnecessary given that Datomic encourages schema growth, and thus rollbacks are unnecessary. perhaps giving each migration a name will be sufficient and we can keep track of the ones we have/haven't ran, and always run them in order:

{:name :my-schema
 :version "1.0"
 :installs [...]
 :migrations [{:name :change-foo :tx-fn 'myapp.migrations/change-foo} 
              {:name :change-bar :tx-fn 'myapp.migrations/change-bar}]}

Similar to attribute installs, the user has to change the database version so that we can know to recheck/rerun the necessary changes.

Uniqueness can be declared on attributes of any value type, including references (:db.type/ref). Only (:db.cardinality/one) attributes can be declared unique.

not flexible enough in regards to positional vector arguments, plus it encourages thinking of design of schema in wrong way

e.g. entity attrs and predicates

currently we provide a vector shorthand that expands into datomic attribute map

namely, we have the #attr pattern: [ident type cardinality ?(unique | component) ?pred]
*if type is db.type/ref then third index is a db/isComponent boolean otherwise it is a db.unique value.

examples:
-#attr [:user/username :db.type/string :db.cardinality/one :db.unique/identity]
-#attr [:note/owner :db.type/ref :db.cardinality/one true]

This works great because the majority of attributes require an ident, type, and cardinality so it's easy to pick up on the pattern, and for other cases we provide other reader literal shorthands (i.e. #ent, and #spec.)

Note, I also considered providing shorthands for the :db value forms but every alternative considered loses semantic meaning. i.e. the keyword :one is less semantically meaningful than :cardinality/one and we can't just do :cardinality/one because that implies it is a non-namespaced attribute, which it's not.

Of the fourth alternatives below (fourth one being default datomic attribute map), the third variation offers succinctness without losing important meaning.
-#attr [:user/username :string]
-#attr [:user/username :type/string cardinality/one]
-#attr [:user/username :db.type/string :db.cardinality/one]
-{:db/ident :user/username :db/type :db.type/string :db/cardinality :db.cardinality/one}

One alternative that would have been great is if namespaced keywords were allowed in EDN files, i.e. ::type.one could be expanded into db.type/one but unfortunately that's not allowed so for now we'll stick with fully specifying datomic attribute values.