[BUG] azure-spring-data-cosmos loses decimal trailing zeros when serializing BigDecimal

Azure / azure-sdk-for-java

This repository is for active development of the Azure SDK for Java. For consumers of the SDK we recommend visiting our public developer docs at https://docs.microsoft.com/java/azure/ or our versioned developer docs at https://azure.github.io/azure-sdk-for-java.

MIT License

2.3k stars 1.96k forks source link

[BUG] azure-spring-data-cosmos loses decimal trailing zeros when serializing BigDecimal #38691

Open Blackbaud-JasonBodnar opened 7 months ago

Blackbaud-JasonBodnar commented 7 months ago

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):

OS: Linux
IDE: IntelliJ
Library/Libraries: azure-spring-data-cosmos:3.18.0
Java version: 11
Frameworks: Spring Boot

Additional context In MappingCosmosConverter:

final String valueAsString = objectMapper.writeValueAsString(sourceEntity);

valueAsString has the correct string representation, ie 43769.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

[ x ] Bug Description Added
[ x ] Repro Steps Added
[ x ] Setup information Added

joshfree commented 7 months ago

Thanks for filing this github issue on BigDecimal not serializing properly and losing precision, @Blackbaud-JasonBodnar - someone from the Cosmos SDK team will follow up.

kushagraThapar commented 7 months ago

@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?

Blackbaud-JasonBodnar commented 7 months ago

@kushagraThapar When you say latest version do you mean 5. or 3.?

Blackbaud-JasonBodnar commented 7 months ago

Also there seems to be a regression between 3.18 and 3.42.

In 3.18, SimpleCosmosRepository.saveAll():

public <S extends T> Iterable<S> saveAll(Iterable<S> entities) {
        Assert.notNull(entities, "Iterable entities should not be null");

        final List<S> savedEntities = new ArrayList<>();
        entities.forEach(entity -> {
            final S savedEntity = this.save(entity);
            savedEntities.add(savedEntity);
        });

        return savedEntities;
    }

By calling save() on each entity of the Iterable passed, any auditing information was filled in (ie, @CreatedBy, @LastModifiedBy, etc).

But in 3.48:

public <S extends T> Iterable<S> saveAll(Iterable<S> entities) {
        Assert.notNull(entities, "Iterable entities should not be null");

        if (information.getPartitionKeyFieldName() != null) {
            return operation.insertAll(this.information, entities);
        } else {
            final List<S> savedEntities = new ArrayList<>();
            entities.forEach(entity -> {
                final S savedEntity = this.save(entity);
                savedEntities.add(savedEntity);
            });

            return savedEntities;
        }
    }

If there's a partition key, operation.insertAll(this.information, entities) does not add auditing information.

Blackbaud-JasonBodnar commented 7 months ago

3.42 did not fix this.