Skip to content

Conversation

@dlindhol
Copy link
Member

@dlindhol dlindhol commented Feb 4, 2026

We've had a number of datasets where we use longs and it would be a shame to prevent them from hapi access. There is the risk of overflow, however. One that we've ignored in other cases. The hapi spec (https://github.com/hapi-server/data-specification/blob/master/hapi-3.3.1/HAPI-data-access-spec-3.3.1.md) says thjis about data types:

Note that there are only a few supported data types: isotime, string, integer, and double. This is intended to keep the client code simple in terms of dealing with the data stream. However, the spec may be expanded to include other types, such as 4-byte floating-point values (which would be called float), or 2-byte integers (which would be called short).

Not even mentioning 64-bit integers (i.e. longs). We do support floats but since doubles are supported, we only risk precision noise.

Maybe we could convert to 32-bit integers, maybe using fill values for those that exceed the max int?

I still need to test the behavior of the 3 output formats.

@dlindhol dlindhol requested a review from lindholc February 4, 2026 16:25
@dlindhol
Copy link
Member Author

dlindhol commented Feb 4, 2026

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant