You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently long and BigDecimal values are serialized as numbers. A JavaScript number is an IEEE 754 64-bit double-precision floating-point format number, which is not enough to safely represent a sufficiently large long or a sufficiently large and/or precise BigDecimal.
For example, an attempt to store Long.MAX_VALUE (9,223,372,036,854,775,807) in a number will result in 9,223,372,036,854,776,000 (maximum value that can be safely represented as a number is 9,007,199,254,740,991).
We might prefer to serialize long and BigDecimal values as strings instead.
Datatype-independent serialization
Currently serialization format depends on datatype. It means that change in datatype format has to be replicated on client side. It might be better if REST API would use standard datatype-agnostic formats for data transfer.
Currently offset is only supported for OffsetDateTime and OffsetTime. Other temporal types implicitly have server's offset. The server's offset is not known on client side. This may lead to wrong values being displayed/saved if server and client have different offsets.
Support for big numbers
Currently
long
andBigDecimal
values are serialized asnumber
s. A JavaScriptnumber
is an IEEE 754 64-bit double-precision floating-point format number, which is not enough to safely represent a sufficiently largelong
or a sufficiently large and/or preciseBigDecimal
.For example, an attempt to store
Long.MAX_VALUE
(9,223,372,036,854,775,807) in anumber
will result in 9,223,372,036,854,776,000 (maximum value that can be safely represented as anumber
is 9,007,199,254,740,991).We might prefer to serialize
long
andBigDecimal
values as strings instead.Datatype-independent serialization
Currently serialization format depends on datatype. It means that change in datatype format has to be replicated on client side. It might be better if REST API would use standard datatype-agnostic formats for data transfer.
Support for offsets
(Related to cuba-platform/frontend#91)
Currently offset is only supported for OffsetDateTime and OffsetTime. Other temporal types implicitly have server's offset. The server's offset is not known on client side. This may lead to wrong values being displayed/saved if server and client have different offsets.
The text was updated successfully, but these errors were encountered: