borinquenkid opened a new pull request, #16026:
URL: https://github.com/apache/grails-core/pull/16026
## Summary
`NumericColumnConstraintsBinder` applied one hand-rolled default precision
(`15`, or `126` for Oracle) to every `Number` subtype when no explicit
precision/constraints were configured. That conflates two different meanings of
"precision":
- **NUMERIC/DECIMAL** (`BigDecimal`/`BigInteger`) precision is a **decimal
digit** count.
- **FLOAT/DOUBLE** precision is a **bit** count (IEEE-754) — Hibernate
converts whatever decimal-digit value it's given into bits when rendering
`float(n)` DDL.
Feeding a decimal-oriented default (Hibernate's own `Size.DEFAULT_PRECISION`
= 19, or naively a dialect's already-bit-valued
`getFloatPrecision()`/`getDoublePrecision()`) overflows H2/PostgreSQL's 53-bit
ceiling and produces DDL those dialects reject — **silently**, since
`hibernate.hbm2ddl.auto` only logs the failure rather than throwing, so the
table is never created.
**Fix:** `Float`/`Double` now leave precision unset, letting Hibernate fall
back to the dialect's own correct float/double DDL type directly.
`BigDecimal`/`BigInteger` default from `Dialect.getDefaultDecimalPrecision()`,
which every dialect already computes correctly — removing the need for the
Oracle-specific special case entirely.
Along the way this also caught a real gap in `SimpleValueBinderSpec`'s test
double (`JdbcEnvironment.getDialect()` was never stubbed, returning `null` —
previously harmless, now exposed as an NPE since the fix calls
`dialect.getDefaultDecimalPrecision()` directly). Fixed the mock rather than
adding defensive null-handling in production code for a scenario a real
Hibernate bootstrap can't produce.
## Root cause, reproduced with real DDL
Reverting to Hibernate's own `Size.DEFAULT_PRECISION` (19) against H2
produces:
```sql
create table numeric_type_message (
big_decimal_value numeric(19,2) not null,
double_value float(64) not null,
float_value float(64) not null,
...
)
```
```
org.h2.jdbc.JdbcSQLSyntaxErrorException: Precision ("64") must be between
"1" and "53" inclusive
```
logged as a `WARN` via `ExceptionHandlerLoggedImpl`, not thrown — the table
is silently dropped from the schema.
## Test plan
- [x] New `GormNumericTypeColumnPrecisionSpec` (H2, no container): covers
the default-precision behavior for `Float`/`Double`/`BigDecimal`, plus a
live-DDL check that the table is actually created with valid columns.
- [x] New `GormNumericTypeColumnIntegrationSpec` (Postgres/MySQL/MariaDB via
Testcontainers, Oracle excluded per the existing `RLikeHibernate7Spec`
precedent): confirms valid, creatable DDL across dialects.
- [x] `NumericColumnConstraintsBinderSpec`: updated for the new
`propertyType` parameter, added cases for the Float/Double/BigDecimal split and
a parameterized dialect check (H2/Postgres/MySQL/Oracle) proving no per-dialect
special case is needed.
- [x] Confirmed RED against unmodified code (H2: `float(64)` rejected; with
my first, incorrect attempt at feeding `dialect.getFloatPrecision()` through
`setPrecision()`: `float(80)`, still rejected) and GREEN after the fix
(`float(24)`, `float(53)`, `numeric(38,2)`).
- [x] Full `grails-data-hibernate7-core` suite: 3020 tests, 0 failures, 24
pre-existing skips.
- [x] `codeStyle` (checkstyle + CodeNarc): clean.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
