[jdaugherty]

Fixes #16688

Problem

A domain property mapped with a Hibernate CompositeUserType, as the GORM guide documents for multi-column types,

amount type: MonetaryAmountType, {
    column name: 'amount'
    column name: 'currency'
}

fails the HibernateDatastore bootstrap under grails-data-hibernate7 with

java.lang.IllegalArgumentException: Named type [class com.example.gorm.MonetaryAmountType] did not implement BasicType nor UserType

The binder puts every type: on a BasicValue, and Hibernate 7 resolves the type name of a BasicValue through TypeDefinition, which accepts a BasicType or a UserType only. A composite user type is not a basic value in Hibernate 6 and 7: @CompositeType is bound as a Component whose type name is the user type, with one property per attribute of the embeddable() class, in alphabetical attribute order, read through getPropertyValue(value, index) and rebuilt through instantiate(ValueAccess).

Fix

• HibernatePersistentProperty.getCompositeUserType() resolves the composite user type of a property from its own type: or from the user-type registered for its class.
• GrailsPropertyBinder routes such a property to the new CompositeUserTypeBinder, which builds the component the way Hibernate's own EmbeddableBinder does: a property per attribute of the embeddable class in alphabetical order, each a BasicValue typed by reflection on the embeddable class and accessed through Hibernate's composite-user-type property access strategy. The attributes are the components of a record, or otherwise the fields and the readable bean properties of the class, less the static, transient and synthetic ones, the names in transients and the properties backed by a transient field. No setter, and no accessor at all, is required: Hibernate never writes the embeddable class, so an immutable value class or a class with private fields only (the shape in the CompositeUserType javadoc) works.
• The columns of the property mapping are assigned to the attributes in that order and go through the existing ColumnBinder, so sqlType, length, index, unique and the property's nullable constraint apply. An attribute without a configured column is named <property>_<attribute>. More columns than attributes is a MappingException naming the property, the counts and the attributes. typeParams are logged as ignored, because Hibernate instantiates a composite user type itself.

Tests

CompositeUserTypeMappingSpec (new) covers the reporter's mapping with two properties of the same type, the metadata and schema (char(3), NOT NULL on the required property, nullable columns on the optional one), insert, read-back, update and clearing to null, HQL on the whole value and on an attribute path, criteria eq, findAllBy and countBy, default column names, a type registered with user-type, an embeddable() record distinct from the value class, a Groovy @Immutable value class with getters only whose computed getter is listed in transients, an embeddable() class with private fields and no accessors, and the column-count error. GrailsPropertyBinderSpec gets a binder-level case and GrailsHibernatePersistentPropertySpec covers getCompositeUserType(). ListSecondPassBinderSpec and MapSecondPassBinderSpec, which wire GrailsPropertyBinder by hand, pass the new binder. All eight features of the new spec fail on 8.0.x with the reported exception before the fix.

Run locally on JDK 21: the full :grails-data-hibernate7-core:test suite, :grails-data-hibernate7-core:codeStyle and validateRepositoryConventions.

Docs

• GORM guide, Custom Hibernate Types: new Composite User Types section with the Hibernate 7 contract (embeddable class, alphabetical attribute index, column order, default names, user-type registration, typeParams).
• type mapping reference: the multi-column example follows the attribute order and uses sqlType: "char(3)" (an explicit sqlType is emitted verbatim, so a separate length has no effect).
• Grails 8 upgrade guide, Hibernate 5 to 7 migration: new Custom User Types note on the UserType API change and on the column order of a ported CompositeUserType.

Not verified against the reporter's example application end to end (it would need a local snapshot publish); its grails-data-hibernate7 branch also calls a non-existent Currency.of(String) in instantiate, which fails independently of this bug.

[borinquenkid]

Reviewed at 68a5522 (base 8.0.x). I read the binder against Hibernate 7.4.10's EmbeddableBinder (fillEmbeddable, processCompositeUserType, compositeUserType()), PropertyAccessStrategyCompositeUserTypeImpl and PropertyAccessGetterImpl, and ran one throwaway probe spec in grails-data-hibernate7-core on H2 at this head, which I then deleted. CI is still queued.

The approach is the right one and matches what Hibernate does for @CompositeType: the component's type name is the user type, its class is embeddable(), the properties are sorted, and PropertyAccessStrategyCompositeUserTypeImpl gets the sorted names and types. One thing to fix before merge.

1. A value class with getters but no setters binds no attributes. attributesOf keeps a bean property only when it has a read and a write method, so an immutable value class, which is the natural shape for a monetary amount, yields no attributes at all. Probe at this head, a Groovy @Immutable class ProbeImmutableMoney implements Serializable { long amount; String currency } behind a type that is otherwise the spec's CompositeMoneyType:

org.hibernate.MappingException: Property [amount] of class [ProbeImmutablePayment] maps 2 columns, but the
embeddable class [ProbeImmutableMoney] of its composite user type [ProbeImmutableMoneyType] has 0 attributes: []

Hibernate never writes the embeddable: it is "never instantiated at runtime" (CompositeUserType javadoc), values come from getPropertyValue(value, index) and go back through instantiate(ValueAccess). Its own metadata read, processCompositeUserType, resolves each attribute's type through PropertyAccessStrategyGetterImpl, which takes a getter method or, failing that, the field (PropertyAccessGetterImpl.fieldGetter), and the javadoc's reference embeddable is a class with two private fields and no accessors at all. So the write method should not be required, and a field without an accessor should count too: an attribute is a non-static, non-transient field, or a readable bean property, less transients and the GORM-excluded names, in alphabetical order. A case in CompositeUserTypeMappingSpec with a getter-only value class would pin it (a Groovy @Immutable class, or a Java class with final fields and getters).

Verified as correct

• getCompositeUserType() resolves the per-property type first and the owner's user-type registration for the value class second, and only when the class implements CompositeUserType; getUserType() keeps its behaviour through the shared classForName.
• The dispatch in GrailsPropertyBinder.bindProperty runs the composite check before isUserButNotCollectionType(), so a composite type no longer reaches BasicValue and the did not implement BasicType nor UserType failure in #16688; every other branch is untouched.
• Column handling: the configured columns are assigned in alphabetical attribute order, which is the index order of getPropertyValue; each goes through ColumnConfigToColumnBinder and ColumnBinder, so sqlType, length, index, unique and the property's nullability apply; a missing column is named <path>_<property>_<attribute> through the naming strategy; more columns than attributes fails with the property, both counts and the attribute names.
• Instantiation mirrors Hibernate's compositeUserType(): the managed-bean registry when CDI extensions are allowed, a plain instance otherwise. typeParams are logged as ignored, which is right, since @CompositeType takes none.
• The spec covers the reporter's two-property mapping, char(3) and NOT NULL, insert, read-back, update, clearing to null, HQL on the value and on amount.currency, criteria, dynamic finders, default column names, user-type registration, a record embeddable() distinct from the value class, and the column-count error; GrailsPropertyBinderSpec and GrailsHibernatePersistentPropertySpec cover the binder and the resolution.
• Docs: the guide's new section states the alphabetical index contract and the column order, the type reference example follows it, and the upgrade guide names both the UserType API change and the ported CompositeUserType column order. The skill file lists the new binder.

Two follow-ups outside this PR, which I'll take. The 9.0.x native binding has no equivalent yet: GrailsDomainGenerator.decideType rejects a class that is neither a UserType nor a registered type, so this mapping fails there too; the counterpart is an @Embedded field with @CompositeType and @AttributeOverrides for the columns. And the Java-to-Groovy branch of the module (#16572) will need this binder ported by hand when it merges up, as the files it touches are renamed there.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 62.2352%. Comparing base (d1f7b1e) to head (fd71dca).
⚠️ Report is 109 commits behind head on 8.0.x.

Additional details and impacted files

@@                Coverage Diff                 @@
##                8.0.x     #16695        +/-   ##
==================================================
+ Coverage     62.1164%   62.2352%   +0.1188%     
- Complexity      26776      26947       +171     
==================================================
  Files            2237       2242         +5     
  Lines          110433     110762       +329     
  Branches        20152      20222        +70     
==================================================
+ Hits            68597      68933       +336     
+ Misses          32617      32567        -50     
- Partials         9219       9262        +43     

see 37 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.

[borinquenkid]

LGTM

[jamesfredley]

Not approving. Binding a CompositeUserType as a component is the right shape, and the basic multi-column path is sound. Three production problems remain.

The component is registered as the embeddable template class rather than the value class, so whole-value queries describe the template. An explicit mapping type such as serializable loses to a globally registered composite type, because the alias does not resolve as a class and the fallback then picks the registration. And unique: true is applied once per attribute column, so a money value rejects (20, EUR) after (10, EUR).

The integration spec does exercise public GORM save/load. It does not catch these three. A smaller compatibility note: GrailsPropertyBinder's previous constructor is removed rather than overloaded, which is source-incompatible for any external caller. That one is not the reason for holding the approval.

[jdaugherty]

The previous GrailsPropertyBinder constructor is back as a deprecated overload in 4fa1565. It binds every property it bound before; a property mapped with a composite user type, which it could never bind, fails with a MappingException that names the missing CompositeUserTypeBinder. GrailsPropertyBinderSpec covers both.

[jamesfredley]

The three earlier comments are fixed. The component class is the value class, an explicit type wins over a global composite registration, and unique: true is one key across the attribute columns rather than one unique flag per column. Not approving yet because the new unique-key path drops quoting and cannot group another composite property.

[jamesfredley]

The two earlier comments are fixed. Quoted column names are kept on the unique key, and a composite property in a uniqueness group contributes every column. Those threads were already resolved. Not approving yet because three other composite mappings still fail at startup.

[testlens-app]

✅ All tests passed ✅

🏷️ Commit: fd71dca
▶️ Tests: 98934 executed
⚪️ Checks: 95/95 completed

---

Learn more about TestLens at testlens.app/docs.

[jamesfredley]

Approving. Each composite user type column is bound from its attribute, so a two-column decimal mapping no longer calls getScale() on the composite. A CDI user type is resolved once, including in a uniqueness group. An enum mapped with a composite user type is bound as a component. The three earlier comments are resolved.