Fork me on GitHub

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


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


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


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.


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,


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