jagiro commented on issue #14503:
URL: https://github.com/apache/grails-core/issues/14503#issuecomment-4377442272
Thanks for the detailed analysis. I'd lean toward option 2 as the
default, with option 1 available as an opt-in.
Main argument: option 2 matches the historical Grails behavior. The
same domain definitions that fail under Grails 7.x worked correctly
under Grails 3.x + GORM 6.x. Both stacks are on Hibernate 5 — the
upgrade path involved a Hibernate minor bump (5.1 → 5.6) and the
javax → jakarta namespace migration, but no Hibernate major-version
change. The validator behavior changed within the Grails/GORM layer
itself, not in Hibernate, so this is a regression on the upgrade path.
Anyone migrating 3.x → 7.x silently runs into it. Restoring option 2
as the default preserves compatibility with everything written under
that behavior.
Option 1 (skip-on-null, SQL standard) is genuinely useful for some
patterns — soft-delete discriminated by a nullable timestamp where
multiple "active" rows must coexist, for instance. So having it
available is great, but making it the default would silently change
semantics for migrating code, which is arguably worse than the current
bug because at least the bug fails loudly.
Configurable sounds ideal, something like:
foo unique: ['discriminator'] // option 2 (default)
foo unique: ['discriminator'], skipNull: true // option 1 opt-in
A short note in the constraint reference docs about how nulls are
treated would also help — that would have prevented the confusion in
this thread.
--
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]
