This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # ai (2)
- # beginners (12)
- # bitcoin (1)
- # boot (41)
- # chestnut (5)
- # cider (9)
- # clara (24)
- # cljs-dev (11)
- # clojure (107)
- # clojure-dev (2)
- # clojure-italy (4)
- # clojure-nl (4)
- # clojure-russia (10)
- # clojure-spec (19)
- # clojure-uk (71)
- # clojurescript (121)
- # cursive (3)
- # data-science (7)
- # datacrypt (1)
- # datomic (72)
- # docs (7)
- # duct (2)
- # emacs (3)
- # ethereum (1)
- # figwheel (1)
- # fulcro (58)
- # graphql (16)
- # hoplon (9)
- # jobs (2)
- # jobs-rus (1)
- # lein-figwheel (1)
- # leiningen (25)
- # luminus (2)
- # lumo (5)
- # off-topic (6)
- # onyx (22)
- # pedestal (3)
- # portkey (1)
- # proton (2)
- # re-frame (7)
- # remote-jobs (1)
- # ring-swagger (3)
- # rum (2)
- # shadow-cljs (38)
- # specter (7)
- # yada (30)
Is there any way to make datomic with sql storage use a different table name than datomic_kvs?
@favila not at present. The last time somebody hit this I think they found they could do a level of indirection on the SQL side.
In a transaction, I’m stuck trying to retrieve the (temp) entity id or the (temp) transaction id and using it as a value for unique attribute. Use case: I want to create a low-cost, shortish unique id for an entity that will survive backup/restore and other cross-database operations.
db:/id seems like the obvious choice, but I am slightly worried about their stability across backup/restore.
Is there any way to have the tempid usable as the value for a custom attribute? What would be the
db.valueType of such an attribute?
I’ve considered an alias to
:db/id, but I think that would suffer from the same stability issues across backup/restore.
Alternatively, can anybody confirm that
:db/id is intended to be stable across backup/restore?
We think we've discovered a bug in Datomic related to string tempids being resolved incorrectly (two entities get mixed up in single transaction under certain conditions). Does anyone know what's the proper channel to report it to the Datomic team?
@cch1 Cognitect has warned that :db/ids are not guaranteed to survive backups/restores and should not be used as stable identifiers. (but they have been stable so far). I don't get how a tempid would help you though!
By “retrieve the (temp) entity id” I mean “reference the (temp) entity id so that I can assign it as a value to my attribute”.
That’s enough to illustrate my example. In that case,
:db/id is assigned a value (reported in the tempid resolution key of the transaction) and my custom identifier uses the same value. Significantly, my attribute does survive backup/restore because it is stored independently of the
if :my/identifier is not a ref type, there is no replacement done, what gets written in is literally whatever you put
yes, it would work, but also be pointless for what you seem to want, which is a short stable identifier
IFF it were stored separately, it would be stable across backup/restore. But as a reference, that would probably not work.
What I really need is access to the tempid creation mechanism as a value, not a reference/entity-id
The resolved value is unique, short-ish and very cheap (already computed in fact). I just need to get it assigned as a value during the transaction. But maybe that is not possible.
yes, but suppose datomic renumbers db/ids at some point. your "unique id" mechanism is now broken, because newly-issued ids may collide
external systems couldn't tolerate uuids because they were too long, and we couldn't find an encoding method that could compress them enough
Your scenario sounds exactly like mine. I was hoping for a solution that leveraged the internal uniqueness of tempids, but your point about clashes post-restore is the kiss-of-death for that.
I also vaguely heard that there are counter services (which just issue guaranteed-monotonically-increasing counters), or you could build something with zookeeper; and call these from within a tx fn
our solution doesn't have gaps and doesn't require coordination with other services, but has the one-increment-per-tx limitation