Fork me on GitHub

If the answer is writes, will each DB have a different preferred node for transactions and does cloud tries to distribute this evenly? or will a single node, at any point in time can be the preferred one for multiple databases?


If it's the latter, sounds like you are better served by creating multiple production stacks to better distribute writes among databases than by increasing the node count for a single production stack (sounds like a nightmare though) or.. instead of increasing to such many nodes, have less nodes but increase their size, ex: to a i3.xlarge

✔️ 3

We are writing. From what we could gather, theoretically datomic would spread traffic accross nodes since it was writing to different databases. We are stable since we upgraded our stack from 704 to 715. Looks like we were having issues in GC


Using Datomic on-prem, I am trying to migrate a :db/ident to a new alias (while keeping the old one for existing code). The docs suggest this is possible: Unfortunately, the documented approach asserts the new ident and removes the previous one:

[:db/add :old/id :db/ident :new/id]
This would make sense, since the schema is a cardinality one:
;; => #:db{:id 10, :ident :db/ident, :valueType :db.type/keyword, :cardinality :db.cardinality/one, :unique :db.unique/identity, :doc "Attribute used to uniquely name an entity."}
Was this changed in some version of Datomic and the docs are not up-to-date? Is there a better way to go about introducing backwards-compatible idents? I suppose I could just change the cardinality to many, but not sure if that would break other assumptions and/or performance?


Ident lookups are special because they ignore retractions. Go ahead and try it: (d/ident db :old/id)


Cardinality many wouldn’t solve the problem: it would just make it ambiguous which ident was the preferred vs deprecated one


It also wouldn’t solve the problem of moving an ident to a different attribute


Thanks @U09R86PA4; what threw me off was querying [?e :db/ident :old/id] returned an empty set; it would only find it via [:?e :db/ident :new/id]. But that makes sense if the idents are special via ignoring retractions.


querying won’t act like this---only ident resolution


Querying for [?e :old/id ...] and [?e :new/id ...] does work. But I've still got to debug why it's not working with my datofu/conformity migrations.


Thanks for pointing me in the right direction!