Skip to content

Deprecate MongoCustomConversions.BigDecimalRepresentation.STRING #4920

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

Open
mp911de opened this issue Mar 11, 2025 · 1 comment · May be fixed by #4957
Open

Deprecate MongoCustomConversions.BigDecimalRepresentation.STRING #4920

mp911de opened this issue Mar 11, 2025 · 1 comment · May be fixed by #4957
Labels
type: enhancement A general enhancement
Milestone

Comments

@mp911de
Copy link
Member

mp911de commented Mar 11, 2025

For Spring Data MongoDB 5.0, we should deprecate MongoCustomConversions.BigDecimalRepresentation.STRING (not for removal) and switch the BigDecimal default to BigDecimalRepresentation.DECIMAL128 to indicate that Decimal128 is the preferred data type enabling range queries.

Storing big decimals as string is still a valid option, deprecation expresses that there are certain limitations and applications can use that option if they are aware of the implications.

Follow-up to #3444 and #4916

@mp911de mp911de added the type: enhancement A general enhancement label Mar 11, 2025
@mp911de mp911de added this to the 5.0 M2 (2025.1.0) milestone Mar 11, 2025
@mp911de
Copy link
Member Author

mp911de commented Jun 12, 2025

Migrating default decimal format representation is a rather subtle change in terms of discoverability as it doesn't come with a behavior that incurs compiler warnings/errors, rather the database format is a different for queries and for the storage format itself.

For cases, where the value is stored as string, a save operation would convert the value to Decimal128. It might make sense to be rather strict in our default setup so that such cases fail fast by initially not registering StringToBigDecimal converters.

Users wanting a gradual migration could configure a mode where read converters (StringToBigDecimal) are registered for the reading case along with using the new Decimal128 default (BigDecimalRepresentation.DECIMAL128.lenient(), BigDecimalRepresentation.DECIMAL128.allowStringReads()). Our default would use a strict variant of BigDecimalRepresentation.DECIMAL128 or BigDecimalRepresentation.strictDecimal128() to improve expressivity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement A general enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants