I believe that as long as you're aware that it is only connecting to a named db, not considering it's point in time, you'll be ok. You may just encounter an overhead by constantly connecting to you datomic system

Don’t do this evar 🙂. 1) :id is private 2) :id isn’t always a connection string. I doubt this works for in-memory dbs. 3) not getting a connection is liberating because now you know a whole tree of function calls can’t mutate the db. If you do this, you can no longer enjoy that feeling. 4) using entity-db already assumes that the function is getting an entity instead of an equivalent map. This is soapbox territory: IMO, d/entity, while convenient and cool, was a mistake because it makes it very easy to lose track of dependencies in large codebases over the long-term (i.e. what does this tree of functions need to read to do its job). Prefer d/pull for new development, which makes that explicit and also eases migration to cloud if you ever do that in the future.

that's a great point

This also breaks the “use a consistent db value for a unit of work” best practice: https://docs.datomic.com/on-prem/best-practices.html#consistent-db-value-for-unit-of-work

thanks!

we did something similar to this at a previous job. I built a type that would record the different access to entity so we could create a pull at the top of the chain that would supply all of the necessary values below. was quite fun but the migration was still kinda scary. its not a great place to be and you will have to remove (or will desperately want to remove) all of this stuff at some point in the future