FHIR Chat · integer64 · fhir/infrastructure-wg

Stream: fhir/infrastructure-wg

Topic: integer64

Grahame Grieve (Dec 06 2019 at 02:00):

I'm going through adding the integer64 type. I'm going to use it for Attachment.size....

Bryn Rhodes (Dec 06 2019 at 03:04):

Well that's future proof :)

Josh Mandel (Dec 06 2019 at 03:23):

Yeah, didn't realize we effectively had a 2Gb limit

Lloyd McKenzie (Dec 06 2019 at 04:04):

Is that something that can be done without breaking our backward compatibility rules?

Paul Church (Dec 06 2019 at 04:15):

Bundle.total for use in searchset? I guess that one is already normative though.

Grahame Grieve (Dec 06 2019 at 04:18):

Bundle.total > 2billion? really?

Grahame Grieve (Dec 06 2019 at 04:19):

Is that something that can be done without breaking our backward compatibility rules?

how would it break them?

Lloyd McKenzie (Dec 06 2019 at 05:13):

New systems could send values that would blow up old systems

Grahame Grieve (Dec 06 2019 at 05:21):

yep. If we're going to make a rule that that's not an allowed change, we can shut up shop once we go normative

Josh Mandel (Dec 06 2019 at 06:04):

In fact every value from the new system would be a string in JSON, which would break every old system... This seems like something pretty highly undesirable for a normative resource.

Paul Church (Dec 06 2019 at 06:04):

There wouldn't be a bundle with 2^31 entries (I hope), but you could have a search matching over 2^31 resources. Large numbers have come up in cases where a client wanted to do a search with _summary=count to get some broad statistics.

Grahame Grieve (Dec 06 2019 at 06:41):

carumba. that's still a very big number.

Paul Church (Dec 06 2019 at 16:35):

The normative spec needs to be stable for a long time though - 10 years from now it might not sound so large.

Jason Walonoski (Dec 09 2019 at 22:43):

Just add a BigInteger. Which in java is equivalent to -2^Integer.MAX_VALUE to 2^Integer.MAX_VALUE.... which is very very big.

Marco Visser (Jan 16 2020 at 14:37):

I see in the json examples (examples-json.zip) that the integer64 values are serialized as strings. For example the size attribute of contentAttachment in the file communication-example-fm-attachment.json:

  "payload": [
    {
      "contentAttachment": {
        "contentType": "application/pdf",
        "data": "SGVsbG8\u003d",
        "title": "accident notes 20100201.pdf",
        "creation": "2010-02-01T11:50:23-05:00"
      }
    },
    {
      "contentAttachment": {
        "contentType": "application/pdf",
        "url": "http://example.org/docs/AB12345",
        "size": "104274",
        "hash": "SGVsbG8gdGhlcmU\u003d",
        "creation": "2010-02-01T10:57:34+01:00"
      }
    }
  ]

Should that not be like this:

        "size": 104274,

?

Lloyd McKenzie (Jan 16 2020 at 15:07):

@Grahame Grieve

Gino Canessa (Jan 16 2020 at 16:35):

If you don't serialize as strings in JSON, the JavaScript parser stores as number and you lose precision. The 64-bit libs for JavaScript serialize to/from string to get around it.
We had a discussion when we were proposing adding the type.

Brian Postlethwaite (Jan 16 2020 at 22:12):

And it is documented on the json page in the spec too that in json it is serializer as a string.

Brian Postlethwaite (Jan 16 2020 at 22:12):

(I had to go look when I saw it)

Grahame Grieve (Jan 17 2020 at 00:20):

yep. we hate JSON numbers ;-)

Marco Visser (Jan 20 2020 at 09:22):

Haha ok. then I hate them too. I will serialize them as strings then. Thanks for the feedback!

Last updated: Apr 12 2022 at 19:14 UTC