-
Notifications
You must be signed in to change notification settings - Fork 2.1k
[BUG] azure-spring-data-cosmos loses decimal trailing zeros when serializing BigDecimal #38691
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks for filing this github issue on BigDecimal not serializing properly and losing precision, @Blackbaud-JasonBodnar - someone from the |
@Blackbaud-JasonBodnar - I believe this issue has been fixed in the latest version of the SDK. Can you please try upgrading to the latest version? |
@kushagraThapar When you say latest version do you mean 5.* or 3.*? |
Also there seems to be a regression between 3.18 and 3.42. In 3.18,
By calling But in 3.48:
If there's a partition key, |
3.42 did not fix this. |
@kushagraThapar : Any more info on this? Is this supposed to be fixed in the latest 3.x? Or only 5.x? What about the issue with d |
@kushagraThapar Here is a repo demonstrating the issues (BigDecimal loses scale, auditable fields not populated when saving collection) with 3.42.0. |
@kushagraThapar I also created a branch with azure-spring-data-cosmos 5.x and can confirm that neither the BigDecimal or the auditable fields work with that version either. |
@Blackbaud-JasonBodnar I was out of office, will look at this earliest by this weekend. |
@kushagraThapar : Have you been able to look at this? |
@Blackbaud-JasonBodnar - I haven't been able to look at the issue above yet (and probably won't be this week) - but the only way to use BigDecimal in any json-base database like Cosmos DB is to store it as a string. JSON itself simply does not support decimal numbers at precision/range BigDecimal is using - Json implementation usually normalize around IEEE754 - which means you will loose precision for BigDecimal in any json-based database. The usual approach is to use serializers that convert to/from string for properties with values of BigDecimal or any integers outside the range of (-2^53)+1 to (2^53) - 1 |
Yes, azure-spring-data-cosmos should be storing these as a string. That's the issue here (plus the regression with auditable fields in newer versions). FYI, we are switching from Cosmos DB in mongodb mode to SQL/Document DB mode and there were no problems with BigDecimal in mongodb mode using spring-data-mongodb. |
@Blackbaud-JasonBodnar - yes, Mongo is not using Json - but the proprietary BSON format - which addresses some of the gaps JSON has around numbers - see https://bsonspec.org/spec.html and the decimal128 binary type. |
That's fine. My point is that because |
Since the ObjectMapper used for serialization/deserialization isn't exposed in azure-spring-data-cosmos it seems you need to add something like what is mentioned in this comment or at least provide a configuration setting to enable something like that. |
I discovered yesterday while going through the SDK code that it will use an
|
@Blackbaud-JasonBodnar thanks for the feedback, we will further investigate this and fix if possible in azure-spring-data-cosmos. |
… and scale are maintained, especially when value ends in 0s (Azure#38691)
@kushagraThapar PR created: #39302 |
@Blackbaud-JasonBodnar PR #40239 was just merged which may fix this issue, after the next release please let me know if this error persists. |
Describe the bug
When azure-spring-data-cosmos serializes an entity with a BigDecimal field trailing zeros in the decimal portion are lost thus ignoring the scale. For example, 43769.30 is serialized as 43769.3.
Exception or Stack Trace
There is none.
To Reproduce
Create an entity with a BigDecimal field. Set the value to 43769.30 and save it to cosmos. Look in cosmos or retrieve the entity. The value is 43769.3. The important thing is the scale. Because according to BigDecimal.equals():
"this method considers two BigDecimal objects equal only if they are equal in value and scale (thus 2.0 is not equal to 2.00 when compared by this method)"
Expected behavior
43769.30 is saved as 43769.30
Setup (please complete the following information):
Additional context
In MappingCosmosConverter:
final String valueAsString = objectMapper.writeValueAsString(sourceEntity);
valueAsString
has the correct string representation, ie43769.30
but:
cosmosObjectNode = (ObjectNode) objectMapper.readTree(valueAsString);
ends up with a child node with a value of
43769.3
Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report
The text was updated successfully, but these errors were encountered: