datomic 2019-01-05 | Slack Archive

dmarjenburgh13:01:44

@steveb8n Not exactly sure what you intend to do, but isn’t the version derivable from the transaction that last updated an entity?

steveb8n23:01:53

Interesting idea. In that case the txn would need an annotation with something like a version so it seems like I would just be moving the complexity elsewhere

steveb8n23:01:40

what I want to do is make it simple/easy to upgrade a database prior to a release or at app read/write time

dmarjenburgh07:01:28

I was more thinking of having a single :app/version attribute that gets updated once per deploy. If the history for this attribute shows [100 :app/version "1.0"] [200 :app/version "2.0"], then transactions with ids between 100 and 200 happened on version 1.0 and all transactions after 200 happened on version 2.0.

eoliphant15:01:35

we use something similar for some of our apps, where there’s a business need for ‘versions’ of entities, where it’s a more typical, monotonically increasing int/long. We’ve also used something similar in transaction functions where we needed to make sure the transact is based fresh data. I don’t think it violates the accretion philosophy, as you’re not ‘breaking stuff’ as you evolve your schema, it just happens to be a sometimes useful (meta?) attribute,

steveb8n23:01:21

that’s my thinking as well. glad to know I’m not crazy 😉

2019-01-05

Channels