Clojurians Log v2
datomic
If I have a schema in a var, and then I add an additional field to it, is it reasonable to transact the whole schema again in its entirety, or better to work out what's changed and upload only the differences?
the other thing to do is to make schema ensuring part of your CICD pipeline, and not part of instance startup
commit -> build -> test -> ensure-schema -> update-pods
Datomic transactions are a DSL for describing changes not a desired end state, so your default stance should be to transact what changed. There happens to be enough upsert-y features that in many cases there's no difference.
what is the context? Are you just tooling around in a repl? if so, just transact. Are you in a prod system? Then you should separate deploying schema from deploying applications. (Your question sounds suspiciously like the context is "I have a var holding schema that I want to transact unconditionally when the application starts up".)
I have used https://github.com/qtrfeast/conformity with success for managing schema changes. (although using https://github.com/qtrfeast/conformity/pull/53 for when the schema got large.)
Another happy conformity user here 👋
I was wondering if I could get away with not using a schema migration system like conformity if I was only ever adding to the schema. That is, if I don't need to worry about changing existing data.
you probably can, until you can't
the conditions for that being possible are: only assertion datoms, only on idents, and never reassign idents (e.g. outside the schema)
But in general it's better to start with some sort of schema management system, in your opinion?
yeah
it doesn't have to be as complicated as conformity. it could be a single entity with a counter for e.g., and each transaction change is assigned a number in code, and include a :db/cas advancing the counter by one when transacting
conformity tries to do schema and data migrations, and name each norm, and allow a granular dependency tree of them
you may not need all that
Schema that consists of vars can give a good introspection of what the actual combinations of entities/attr within the system looks like if designed right. That said, you can transact the schema as much as you want with only the changes persisting, vcs is enough in most cases to monitor what changed within the schema file. Used this within a production system running for 5+ years without issues, worthy of note though is, its a small team, as there could be an argument otherwise when multiple devs change that file.
If you prefer going the migration lib route, adding this to the mix: https://github.com/recbus/caribou
We've been using caribou in production for several years. Disclaimer: I am the author.