Question about type of numeric LWM2M attributes. about leshan

[sbernard31]

@PFnord, @mgdlkundera, @jvermillard, @JaroslawLegierski any opinion about it ?

[jvermillard]

Is there a way where, if the number is received as an integer, to store it and use it as an integer, and if it's a float number, decode it as double?
I think if you try to use only double for those parameters you will have errors in strict equality with a lot of integer values

[PFnord]

As I understand it those attributes are "Float" explained in an older spec (2018_OMA_SPEC in Data Types appendix):

Represented as a binary floating point value [IEEE 754-2008] [FLOAT]. The value may use the binary32 (4 byte length) or
binary64 (8 byte length) format as indicated by the Length field. When transmitted over network, the data is represented in
network byte order (big endian)

I would assume, treating a float attribute as double seems ok to me.

Spec specify we can have 64bit integers resources, which I would assume means we can have 64 bit integer attributes (or close to it). I would agree with @jvermillard and treat them as integer/long when possible?

[sbernard31]

As I understand it those attributes are "Float" explained in an older spec (2018_OMA_SPEC in Data Types appendix):

I understand the data type appendix is about LWM2M Resource typing, I don't think this is about attributes typing.

Spec specify we can have 64bit integers resources, which I would assume means we can have 64 bit integer attributes (or close to it).

During comparison this should be OK but as I said if someone send me a st=9223372036854775807, it will be converted in 9223372036854776000. In that case we can eventually raise an error or log a warning or change the code to support it.

Is there a way where, if the number is received as an integer, to store it and use it as an integer, and if it's a float number, decode it as double?

Not really, currently the attribute is strongly typed.
We can eventually change the type to :

• String and create corresponding number only when needed but if want to make validation handling String will be painful. (and probably less efficient than BigDecimal anyway)
• BigDecimal from a design point of view this is the simple and more elegant one. (but with probably some memory usage overhead : http://javamoods.blogspot.com/2009/03/how-big-is-bigdecimal.html)
• Number and try to create the smaller possible type without data loss but this will lead to a painful code and a not so easy to use API (mainly because Number abstraction in java abstract almost nothing ...). I'm not sure this kind of optimization really worth it. 😬

For now, I feel acceptable solutions could be :

• use BigDecimal to fully support it
• keep the Double limitation but warn or raise exception when we get a string value which can not be store in double.

Maybe moving to BigDecimal, is not so Bad ?