search

nuagenetworks / monolithe

generic and extendable code generator from specifications.
BSD 3-Clause "New" or "Revised" License
16 stars 28 forks source link

Why is data type "time" mapped to Float #177

Open mboyerm opened 2 years ago

mboyerm commented 2 years ago

Is there a reason why the data type "time" is mapped to Float (instead of Long)? https://github.com/nuagenetworks/monolithe/blob/6ca7664df8f00775ccdb741aadba0e301fcca473/monolithe/generators/lang/java/converter.py#L40

This creates an issue when trying to set the startDateTime attribute from the ScheduledTestSuite object. http://nuagenetworks.github.io/vsd-api-documentation/v6/20.10.8/scheduledtestsuite.html#attr_startDateTime

ralphmalek commented 2 years ago

To expand on this, what I've noticed is that, when the VSPK sends this back to VSD, the output ends up being 1.234E12 rather than the long version of the value, which VSD subsequently rejects. By replacing the definition of the object with one that uses Long instead of Float, the save works correctly.

pdumais commented 2 years ago

I looked at the specs files and it looks like any places that uses "time" might be ok to be replaced by "integer". There are a few attributes that express an average time (like average RTT) but those are set as "float" instead of "time". It looks like a safe change to make but we would need to fully test all of those fields to make those changes. We need to query all fields marked as "time" and make sure they return integers. Or ask the R&D team to investigate CC @pdellaert

ralphmalek commented 2 years ago

Should this be an integer or a long? Java Date represents its time in milliseconds as a long so should we be consistent with this?

We only use one of the affected classes at the moment, but I have confirmed that switching the float to a long in that case works perfectly fine when retrieving and saving the objects.

pdumais commented 2 years ago

I mean "Integer" in the mathematical sense. But yes, a long to be more precise.