Stream: implementers
Topic: 64-bit integer types
Gino Canessa (Nov 11 2019 at 20:42):
Came across the need to describe event counts in subscriptions, and the integer value types only go to 32-bit, which will overflow in production systems.
As a workaround, we are using the decimal type with guidance that only integer values should be used, but using decimal has performance implications.
Thought I'd ask here for thoughts/comments/questions (unless there is somewhere more appropriate). Thanks!
Grahame Grieve (Nov 11 2019 at 21:12):
where do we need to describe event counts in subscriptions?
Gino Canessa (Nov 11 2019 at 21:23):
There's a sequence number sent to clients so they know if they have missed anything. Right now it is defined as both a field on Subscription (to discover current state) and an extension on bundle (for inclusion in notifications).
Grahame Grieve (Nov 11 2019 at 21:26):
a sequence number for each subscription? and that will roll over past 2^32?
Gino Canessa (Nov 11 2019 at 21:28):
That's feedback we've been getting, yes.
Grahame Grieve (Nov 11 2019 at 22:05):
hmm
Paul Church (Nov 11 2019 at 22:17):
It's only 2^31. We have had FHIR stores with more than 2^31 resources in them. If you're doing 1000 operations per second it rolls over in less than a month. It's just not a large enough number.
If Subscriptions are only used at the patient level then this doesn't become a problem, but there are use cases with much broader criteria.
Grahame Grieve (Nov 11 2019 at 22:27):
Oh I'm sure the stores roll over that fast. And the total subscription count will too. but on a specific subscription.. not so obvious.
Grahame Grieve (Nov 11 2019 at 22:27):
anyway I'd rather use string than decimal, and either change the range of int of introduce a new type in R5
Gino Canessa (Nov 12 2019 at 14:48):
Created GF#25208
Josh Mandel (Nov 13 2019 at 15:31):
anyway I'd rather use string than decimal, and either change the range of int of introduce a new type in R5
Can you say more about why string? Are you thinking the new R5 "int64" type would also have a string representation in JSON? Because if not, we would be changing the serialization in addition to the models.
Grahame Grieve (Nov 13 2019 at 20:33):
if it's an extension you'll be changing the serialisation anyway
Grahame Grieve (Nov 13 2019 at 20:37):
I figured that going with string would avoid the weirdities of decimals and variable precision, but it looks like we can at least claim that [-(253)+1, (253)-1] would be expected to be supported
Josh Mandel (Nov 18 2019 at 19:52):
Yeah, I wasn't imagining an extension in the interim; was imaginging decimal in the interim.
Grahame Grieve (Nov 18 2019 at 19:53):
it's already an extension, no?
Josh Mandel (Nov 18 2019 at 19:56):
I mean, Subscription.eventCount in the current build is an unsignedInt (http://build.fhir.org/subscription-definitions.html#Subscription.eventCount), and we've been talking about switching to decimal.
Josh Mandel (Nov 18 2019 at 19:57):
(There's also a way to convey this inline with each notification, as https://build.fhir.org/extension-bundle-event-count-definitions.html#extension.bundle-event-count -- but this uses the same datatype as Subscription.eventCount.)
Grahame Grieve (Nov 18 2019 at 19:58):
ok well, I guess the serialization of the extension in bundle is going to change whatever but the json type doesn't change if you use decimal
Grahame Grieve (Nov 18 2019 at 19:58):
I don't know if any json implementations have problems with lossy precision for high values of decimals
Pascal Pfiffner (Nov 18 2019 at 21:06):
The default NSJSONSerialization library on iOS / macOS has problems with those because it uses doubles internally.
natus (Nov 23 2019 at 11:27):
also why no LongType in fhir base types ? Using decimal is a poor workaround
Grahame Grieve (Nov 23 2019 at 13:20):
No one had identified a use case. But here we have one, so we’re talking about it. But JSON doesn’t have it...
Florian Briand (Nov 25 2019 at 16:28):
With JSON, the community used to store "real life decimals" as string, because in most of the case, the loss dues to binary numeric precision is not acceptable.
The problem is well explained on this stackoverflow thread : https://stackoverflow.com/questions/35709595/why-would-you-use-a-string-in-json-to-represent-a-decimal-number
Last updated: Apr 12 2022 at 19:14 UTC
