datomic

Ask questions on the official Q&A site at https://ask.datomic.com!
Nassin 2020-11-04T03:27:49.309Z

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?

Nassin 2020-11-04T03:37:15.310100Z

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

1✔️
kschltz 2020-11-04T13:40:14.321300Z

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

pithyless 2020-11-04T12:21:24.316500Z

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: https://docs.datomic.com/on-prem/best-practices.html#use-aliases 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?

favila 2020-11-04T12:40:19.318300Z

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

favila 2020-11-04T12:42:48.320400Z

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

favila 2020-11-04T12:43:07.321100Z

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

kschltz 2020-11-04T13:40:14.321300Z

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

pithyless 2020-11-04T14:29:36.321700Z

Thanks @favila; 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.

favila 2020-11-04T14:30:50.321900Z

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

pithyless 2020-11-04T14:30:51.322100Z

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.

pithyless 2020-11-04T14:31:31.322300Z

Thanks for pointing me in the right direction!