Make domain properties nullable by default (Grails 8)

[codeconsole]

Summary

Change GORM's default constraint so an unconstrained persistent (domain) property is nullable (optional) rather than required. Today Grails applies an implicit nullable: false to every persistent property; this PR flips that default to nullable: true.

The default lives in DefaultConstraintEvaluator and is controlled by a new YAML‑friendly boolean that defaults to nullable‑by‑default:

# application.yml — set false to restore the legacy required-by-default behaviour
grails:
  gorm:
    default:
      nullable: false

Scope is the validation layer only. Command‑object validation (Validateable.defaultNullable()) is intentionally left required‑by‑default and unchanged in this PR.

Why this should be the Grails 8 default

Grails is the only mainstream JVM data framework that is required‑by‑default. Every comparable layer treats an unconstrained property as nullable and makes you opt into "required":

Framework	Default for an unconstrained reference property
JPA / Hibernate	nullable (@Column(nullable=false) / @NotNull to require)
Spring Data JPA	nullable
Spring Data MongoDB	nullable (schemaless)
Micronaut Data	nullable (@NonNull / Kotlin non‑null type to require)
Jakarta Bean Validation (JSR‑380)	nullable — no constraint = valid; @NotNull is the opt‑in
Grails / GORM (today)	required (nullable: true to allow null)

The case for flipping it:

1. Principle of least surprise / ecosystem consistency. Developers arriving from Spring Boot, Micronaut, JPA, or plain Bean Validation expect "nullable unless I say otherwise." Grails inverts that — one of the most common first‑week surprises ("why does saving fail when I didn't mark anything required?").
2. It contradicts the storage layer. SQL columns are nullable by default; MongoDB is schemaless. Grails' validation default is stricter than the database it maps to, for no structural reason.
3. It inverts the JSR‑380 contract. Bean Validation defines "absence of a constraint ⇒ the value is valid (including null)"; @NotNull is the explicit opt‑in. Grails' implicit nullable:false is a silent, framework‑specific reversal of the spec it otherwise embraces.
4. It breaks composition. Fields contributed by traits, base classes, or shared modules — or simply a new field added to an existing domain — silently become required, surfacing only as a runtime ValidationException on the first save (often in an unrelated path, e.g. a BootStrap seed). Mixing in reusable field sets is exactly the modular design Grails 8 should encourage; required‑by‑default punishes it.
5. A major version is the right time. Defaults that no longer match the ecosystem should be corrected at a major boundary. Grails 8 is that boundary.

Backward compatibility

Deliberate behavior change, with a one‑line opt‑out to restore the legacy behavior per application. Either set the boolean flag (YAML or groovy):

# grails-app/conf/application.yml
grails:
  gorm:
    default:
      nullable: false

// grails-app/conf/application.groovy
grails.gorm.default.nullable = false

…or use the existing wildcard‑constraint form, which also still works:

grails.gorm.default.constraints = {
    '*'(nullable: false)
}

The grails.gorm.default.constraints machinery applies '*' constraints before the framework default and skips the default when one is set (canApplyNullableConstraint), so either opt‑out composes cleanly with per‑property overrides.

Command objects are unaffected (still required‑by‑default). If you additionally want command objects to be nullable‑by‑default, that remains an explicit per‑class opt‑in via static boolean defaultNullable() { true }.

Test suite

The affected test suite has been swept and the full ./gradlew test is green. Rather than disabling the new default wholesale, each spec that asserts required‑by‑default semantics now declares the specific field(s) it depends on explicitly (nullable: false), reproducing the prior baseline for just those fields. A module‑wide grails.gorm.default.constraints opt‑out was deliberately not used as the general mechanism because that closure is also evaluated against the GORM mapping builder and can perturb per‑property mapping (e.g. formula:/derived‑property detection used by f:fields/f:all), and because several specs define their own grails.gorm.default.constraints that a module‑wide file would clobber.

A new NullableByDefaultSpec demonstrates the change without any opt‑out (an unconstrained property validates while null, while a property with an explicit nullable: false is still required), and verifies that grails.gorm.default.nullable = false restores required‑by‑default through DefaultValidatorRegistry.

Notes / scope

• Validation layer only. Column/DDL nullability is governed separately by the mapping layer (Property.nullable / GrailsDomainBinder) and is not changed here; aligning the DDL default is a documented follow‑up for maintainers.
• Opening against 8.0.x.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 48.4341%. Comparing base (3be255b) to head (b112a97).
⚠️ Report is 26 commits behind head on 8.0.x.

Additional details and impacted files

@@                Coverage Diff                 @@
##                8.0.x     #15721        +/-   ##
==================================================
+ Coverage     48.3185%   48.4341%   +0.1155%     
- Complexity      15212      15266        +54     
==================================================
  Files            1875       1875                
  Lines           85818      85859        +41     
  Branches        14969      14972         +3     
==================================================
+ Hits            41466      41585       +119     
+ Misses          37980      37865       -115     
- Partials         6372       6409        +37     

Files with missing lines	Coverage Δ
...core/src/main/groovy/grails/config/Settings.groovy	100.0000% <ø> (ø)
...y/org/grails/validation/ConstraintEvalUtils.groovy	85.7143% <100.0000%> (+1.0989%)	⬆️
.../tck/domains/ClassWithListArgBeforeValidate.groovy	100.0000% <100.0000%> (ø)
...ng/tck/domains/ClassWithNoArgBeforeValidate.groovy	100.0000% <100.0000%> (ø)
...k/domains/ClassWithOverloadedBeforeValidate.groovy	100.0000% <100.0000%> (ø)
...n/constraints/eval/DefaultConstraintEvaluator.java	81.0811% <100.0000%> (+0.3914%)	⬆️
...nstraints/registry/DefaultValidatorRegistry.groovy	87.5000% <100.0000%> (+0.5435%)	⬆️
...g/core/connections/ConnectionSourceSettings.groovy	33.3333% <ø> (ø)
...pport/DefaultConstraintEvaluatorFactoryBean.groovy	100.0000% <100.0000%> (ø)

... and 19 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jdaugherty]

@jamesfredley created a documentation file for our default values and you're now changing that default, but not changing those files

[jamesfredley]

Updated the default-values metadata JSON: grails-core/src/main/resources/META-INF/spring-configuration-metadata.json now includes grails.gorm.default.nullable with defaultValue: true, matching the Grails 8 nullable-by-default behavior.

done

[jdaugherty]

You added this to grails-core instead of grails-datastore-core.

[jdaugherty]

@jamesfredley why are we not adding a specific configuration file for the datastore project? That's where the constraint is actually used.

[codeconsole]

@jdaugherty there is no similar file in grails-datastore-core. I put it where all the other grails.gorm.* keys are. It wouldn't make sense to put it a location different from where the other keys are.

[jdaugherty]

I agree, and we shouldn't let this block this change. But I think we've made a larger mistake here - the config keys were supposed to exist in the projects where they're used/defined. It's my understanding that hasn't happened based on this.

[bito-code-review]

The configuration metadata for grails.gorm.default.nullable was added to grails-core because it defines a core framework property that affects how Grails domain classes handle nullability by default. While GORM-specific logic resides in grails-datastore-core, the spring-configuration-metadata.json file in grails-core is the standard location for documenting framework-level configuration properties that are exposed to Spring Boot and IDEs for auto-completion.

[testlens-app]

✅ All tests passed ✅

🏷️ Commit: b112a97
▶️ Tests: 41860 executed
⚪️ Checks: 43/43 completed

---

Learn more about TestLens at testlens.app.

[jdaugherty]

I think this can be merged after we discuss in the weekly. This PR identified a configuration issue that I believe we need to discuss before merging. I'd suggest we merge this after Wednesday's meeting.

[codeconsole]

@jdaugherty but if the hold up is just the json file, why not just approve and I can do a separate PR to address all the data mapping json changes. Unless you want just my 1 change by itself in a json file which I can do here if you want.