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.

[testlens-app]

✅ All tests passed ✅

🏷️ Commit: c27b930
▶️ Tests: 35599 executed
⚪️ Checks: 43/43 completed

---

Learn more about TestLens at testlens.app.