LengthConstraintValidationStep performs incorrect check for fixed-point numeric fields

[SanderBenschop]

I have discovered a bug in the way that JaRB validates maximum length for numeric values with fixed-point precision (used for monetary values for instance).

Consider a column amount in a Postgres database with a datatype of numeric(12,5) this means that the maximum precision is 12 and the maximum scale is 5 (see https://www.postgresql.org/docs/13/datatype-numeric.html).

I used JaRB validation on this field for the backend JSR303 validations as well as the frontend validations. I entered the amount 123456789 in the field. This passed two JaRB validations:

1. LengthConstraintValidationStep

   This validation checked that the length of the field is smaller than 12. The input value is 9 digits long so it passed.

2. FractionLengthConstraintValidationStep

   This validation checked that fraction length is smaller than 5. The input value did not have any digits after the decimal point so this also passed.

Then, when the backend tries to insert the value the database gives an error:

Caused by: org.postgresql.util.PSQLException: ERROR: numeric field overflow
Detail: A field with precision 12, scale 5 must round to an absolute value less than 10^7.

It is correct that 123456789 cannot be inserted into the database, as the maximum length of the part before the decimal point is not 12 digits, it is 12 - 5 = 7 digits. Hence the error message that Postgres is throwing.

So I think the LengthConstraintValidationStep is performing an incorrect check for these fixed-point numeric fields.

It checks:

length of input before decimal point < precision

When it should check:

length of input before decimal point < (precision - scale)