-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
BigDecimal conversion broken in division #4043
Comments
There is no Modern versions of H2 treat But results of your query look like SELECT CAST(16 AS NUMERIC) / 100, CAST(16 AS NUMBER) / 100;
-- H2 2.1.214:
> 0.16000000000000000000 | 0.16
-- Current H2:
> 0 | 0.16 Scale of quotient was changed recently for this data type. So you need to check how exactly your table was created, because JPA can create it automatically with different column types. Division is a very unreliable operation in SQL, because both precision and scale of quotient aren't standardized. Usually it is safer to use multiplication by 0.01 in such queries, because scale of product must be a sum of scales of its operands in every standard-compliant database system. |
Right, this table is created by Liquibase, the definition of the column
which was working well. Changing it to Thanks for pointing that out. |
Given a table created as
we're using Spring Data JPA to select and calculate values from this table
and some test data
which works well with H2 v2.1.214 rendering the expected BigDecimal with stringCache="1.16", intCompact=116, precision=3, scale=2
Upgrading to v2.2.222 renders a different BigDecimal with stringCache="1.00", intCompact=100, precision=3, scale=2 which is obviously wrong.
I've narrowed it down to being related to org.h2.expression.BinaryExpression and maybe #3737 and commit e6ce81e, since replacing the BinaryExpression class with the one from version v2.1.214 produces the expected result.
The text was updated successfully, but these errors were encountered: