Fork me on GitHub
#datascript
<
2017-03-18
>
rauh07:03:30

@qqq you'll run out of memory before you'd have to worry about "running out of datascript ids"

qqq09:03:06

@rauh: what if

(while true
  (add entity)
  (delete endity))

qqq09:03:13

I don't see how your claim is possibly true.

qqq09:03:37

Also, if you use transit to persist datascript dbs, the max-id stays persistent across sessions

rauh09:03:35

@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.

rauh09:03:24

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

rauh09:03:25

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)

qqq09:03:35

well, if we create one every micor second, we get: 2 ^ 53 / 1000000 / 60 / 60 / 24 / 365 285.61641472415626585489

qqq09:03:40

so it's only good for 285 years

qqq09:03:09

so if I don't persiste db/ids -- why not just generate uuids in the first place ?

rauh09:03:04

@qqq you'll have to ask the datomic folks why not. My guess is that 128 bit is 2x64 bit and would be wasteful

qqq09:03:16

one last question

qqq09:03:41

when people say UUID, they don't really guarnatee it's unique do they it's really "by the birthday paradox, you're more likely to die in an asteriod attack tha have a collision, so don't worrya bout it " right?

rauh09:03:27

@qqq IIRC most can guarantee uniqueness within the same JVM

qqq09:03:19

sure, within the same machien you can do time stamp + counter + randomness