This is a fundamental limitation of javascript Numbers, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number#number_encoding

Integers can only be represented without loss of precision in the range -2^53 + 1 to 2^53 - 1, inclusive (obtainable via Number.MIN_SAFE_INTEGER and Number.MAX_SAFE_INTEGER), because the mantissa can only hold 53 bits (including the leading 1).

There is BigInt though, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt

Thanks. That was a difficult to track down bug - could not work out why my data wasn't being pulled from a normalized database.

Thank you. That's really helpful.

I ended up with the following in a normalized database:

#object[Long 9496401000001106] {:info.snomed.Concept/id #object[Long 9496401000001106],
                                 :info.snomed.Concept/preferredDescription {:info.snomed.Description/term "Istin"}},
 398762003 {:info.snomed.Concept/id 398762003,
            :info.snomed.Concept/preferredDescription {:info.snomed.Description/term "Zonisamide-containing product"}},
 #object[Long 9322401000001109] {:info.snomed.Concept/id #object[Long 9322401000001109],
                                 :info.snomed.Concept/preferredDescription {:info.snomed.Description/term "Rebif"}},
 #object[Long 9396901000001109] {:info.snomed.Concept/id #object[Long 9396901000001109],

Yea, that is super tricky.

For anyone interested, searching for in:#cljs-dev BigInt will pull up some interesting cljs numeric tower discussions.

I am masochistic enough to possibly do that at this point!

Given that SNOMED CT identifiers will need(?) to be strings at the edges of your system anyway, and within your system the kind of "integer" you would need is not the cheapest kind, and the warping and creaking of the database will dwarf any minor clevernesses,... strings were a great invention and might be less trouble.

Yes except not all of my edges fail to support 64-bit integers.... but you might well be right, The server uses lmdb internally so these data structures are are natively 64-bit ints and so any change will require mapping at one of the strata of the stack as switching to strings all the way down is not tenable.

See the discussion here and below: https://clojurians.slack.com/archives/C07UQ678E/p1698353101153739 tl;dr: no implications.

thanks!