Proposal: Enable WRITE_BIGDECIMAL_AS_PLAIN serialization feature in JacksonSnapshotSerializer

[grimsa]

The existing JacksonSnapshotSerializer with its default config serializes BigDecimal values using scientific notation, e.g.: "amountInEur": 1E+2 instead of "amountInEur": 100.

I assume the non-scientific notation is the one preferred in snapshots in most applications, hence the proposal to change the default configuration in the library.

The change in code would be adding:

this.enable(SerializationFeature.WRITE_BIGDECIMAL_AS_PLAIN);

in JacksonSnapshotSerializer.

Would such a change make sense? If yes, I'd be happy to contribute a PR.

The workaround is for the application to implement its own custom serializer like this:

public class CustomJacksonSnapshotSerializer extends JacksonSnapshotSerializer {
    @Override
    public void configure(ObjectMapper objectMapper) {
        objectMapper.enable(JsonGenerator.Feature.WRITE_BIGDECIMAL_AS_PLAIN);
    }
}

and then specify it in snapshot.properties

[jackmatt2]

Agree that this should be the default

[grimsa]

Opened a draft PR: #142, then looked at this some more, and I think it's likely that changes in this lib are not needed.

Here's why.

In Jackson, the default serialization depends on BigDecimal#toString, which by itself uses scientific notation only in a subset of cases. Its javadoc says:

Returns the string representation of this BigDecimal, using scientific notation if an exponent is needed.
A standard canonical string form of the BigDecimal is created as though by the following steps: first, the absolute value of the unscaled value of the BigDecimal is converted to a string in base ten using the characters '0' through '9' with no leading zeros (except if its value is zero, in which case a single '0' character is used).
Next, an adjusted exponent is calculated; this is the negated scale, plus the number of characters in the converted unscaled value, less one. That is, -scale+(ulength-1), where ulength is the length of the absolute value of the unscaled value in decimal digits (its precision).
If the scale is greater than or equal to zero and the adjusted exponent is greater than or equal to -6, the number will be converted to a character form without using exponential notation.
Otherwise (that is, if the scale is negative, or the adjusted exponent is less than -6), the number will be converted to a character form using exponential notation.

Basically it works like this:

• BigDecimal.valueOf(100) => 100
• BigDecimal.valueOf(100).setScale(2) -> 100.00
• BigDecimal.valueOf(0.000001) -> 0.0000010
• BigDecimal.valueOf(0.0000001) -> 1.0E-7
• BigDecimal.valueOf(10000000000000L) -> 10000000000000

This seems like a reasonable default.

In our case the problem was caused by us building up the Jackson's JsonNode manually, which in turn uses the same JsonNodeFactory logic that is used when deserializing JSON. That logic had an issue of calling BigDecimal#stripTrailingZeroes which would then later result in the value of 100 serializing as 1E+2 (FasterXML/jackson-databind#3650).
As there is now a solution for that problem in Jackson lib, it seems we could overcome this by using the newly added setting which would prevent trailing-zero-stripping, which in turn would lead to having the original values in snapshots.