This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-11-04
Channels
- # announcements (4)
- # babashka (15)
- # beginners (147)
- # bristol-clojurians (8)
- # calva (6)
- # chlorine-clover (39)
- # clj-kondo (29)
- # clojure (95)
- # clojure-australia (1)
- # clojure-berlin (1)
- # clojure-europe (24)
- # clojure-nl (3)
- # clojure-spec (185)
- # clojure-uk (98)
- # clojured (2)
- # conjure (3)
- # core-async (26)
- # datomic (11)
- # etaoin (1)
- # events (1)
- # fulcro (26)
- # graalvm (3)
- # graphql (4)
- # jobs (7)
- # jobs-discuss (1)
- # kaocha (12)
- # leiningen (21)
- # malli (2)
- # meander (2)
- # parinfer (3)
- # pathom (3)
- # pedestal (5)
- # remote-jobs (2)
- # shadow-cljs (71)
- # spacemacs (2)
- # sql (4)
- # tools-deps (22)
- # tree-sitter (1)
- # vim (2)
- # xtdb (5)
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
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: 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?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
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.