This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-03-18
Channels
- # beginners (22)
- # boot (12)
- # cider (3)
- # cljs-dev (12)
- # cljsrn (8)
- # clojure (101)
- # clojure-nl (5)
- # clojure-russia (13)
- # clojure-spec (5)
- # clojure-uk (15)
- # clojurescript (158)
- # cursive (5)
- # datascript (16)
- # datomic (8)
- # hoplon (11)
- # lumo (33)
- # off-topic (3)
- # om (25)
- # parinfer (1)
- # pedestal (8)
- # protorepl (4)
- # re-frame (8)
- # reagent (5)
- # specter (18)
- # sql (1)
- # testing (11)
- # timbre (1)
- # unrepl (2)
- # untangled (1)
@qqq you'll run out of memory before you'd have to worry about "running out of datascript ids"
Also, if you use transit to persist datascript dbs, the max-id stays persistent across sessions
@qqq 2**31
is a pretty large number, even if you can possibly do 1 new entity per ms you'll take days to get to 2**31. I wouldn't even remotely worry about it. I saw your question on datomic too, there is many other problems you'll run into. But running out of :db/id's isn't one of them.
Don't persist :db/ids and rely on them. Neither in datascript nor in datomic. Use some other identifiers (UUIDs) and treat :db/ids as implementation details
Actually, it seems like JS can do 2**53, so yeah, you'll never run out of those :db/id's. (ever ms one new entity id -> 200,000+ years until you run out)
well, if we create one every micor second, we get: 2 ^ 53 / 1000000 / 60 / 60 / 24 / 365 285.61641472415626585489
@qqq you'll have to ask the datomic folks why not. My guess is that 128 bit is 2x64 bit and would be wasteful