Composite (embedded) @Id columns are not excluded from UPDATE SET clause

[krasnovdm]

Bug description

When an entity uses a composite identifier via @Id on a property whose type is itself an entity/record (the pattern used for composite ID support, see https://spring.io/blog/2025/07/22/spring-data-jdbc-composite-id/ and #574), the columns belonging to that composite id are incorrectly included in the SET clause of the generated UPDATE statement, in addition to the WHERE clause.

For a simple (non-composite) @Id, the id column is correctly excluded from SET — only the composite/complex-identifier case is affected.

Root cause (traced in source)

org.springframework.data.jdbc.core.convert.SqlGenerator.Columns:

• populateColumnNameCache() detects a complex identifier via Association.isComplexIdentifier() and recurses into the referenced identifier entity:

  populateColumnNameCache(association.getRequiredTargetIdentifierEntity(),
          prefix + property.getEmbeddedPrefix());

• Inside that recursive call, each property of the identifier entity goes through initSimpleColumnName(property, prefix), which classifies the column via:

  if (!property.getOwner().isIdProperty(property)) {
      nonIdColumnNames.add(columnName);
  } else {
      idColumnNames.add(columnName);
  }

  Here property.getOwner() is the identifier entity itself (e.g. a plain record MyCompositeId), whose own fields are not individually annotated @Id — the @Id annotation lives on the root entity's property that references this identifier type. So property.getOwner().isIdProperty(property) returns false for every field of the composite id, and all of them end up in nonIdColumnNames instead of idColumnNames.
• Later, updatable.removeAll(idColumnNames) therefore does not remove the composite id's columns, so they remain in updatableColumns and get emitted in the generated UPDATE ... SET ... statement.

Steps to reproduce

class Entity {
    @Id
    CompositeId id;
    String someField;
}

record CompositeId(String partA, String partB) {}

interface Repo extends CrudRepository<Entity, CompositeId> {}

1. Save a new Entity (insert) — works fine.
2. Load it and call repo.save(entity) again (update path, since id is non-null).
3. Inspect the generated SQL.

Expected behavior

UPDATE entity SET some_field = ? WHERE part_a = ? AND part_b = ?

Composite id columns should be excluded from SET, consistent with how a simple @Id is handled.

Actual behavior

UPDATE entity SET part_a = ?, part_b = ?, some_field = ? WHERE part_a = ? AND part_b = ?

The composite id's columns are redundantly included in SET.

Why this matters beyond redundancy

Most relational databases silently accept SET pk_col = <same value> as a no-op, so this goes unnoticed there. On a database that rejects any assignment to a primary-key column inside UPDATE ... SET at statement-validation time — regardless of whether the value actually changes — this makes save() unusable for entities with a composite @Id, forcing a bypass of the standard repository save() path entirely.

Environment

Observed with the composite-id feature introduced in 4.0.0-M4 (https://spring.io/blog/2025/07/22/spring-data-jdbc-composite-id/); please let me know if this is already fixed in a more recent build.

[adityaanikam]

To answer the question in your last line first: no, this is not fixed on current main. All four line references you cited are still accurate: SqlGenerator.java line 1467 (updatable.removeAll(idColumnNames)), 1481 to 1482 (the isComplexIdentifier() recursion), 1498 (initSimpleColumnName), and 1504 (property.getOwner().isIdProperty(property)). Your read of the mechanism is exactly right, the owner passed into isIdProperty is the identifier record itself, which has no @Id annotated fields of its own, so every composite id field lands in nonIdColumnNames regardless of how the root entity declared it. Happy to open the PR, the fix looks contained to teaching initSimpleColumnName (or its caller) that a property reached through the complex identifier recursion is implicitly an id column.