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

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.

Start in org.springframework.data.jdbc.core.convert.SqlGenerator.Columns, especially populateColumnNameCache() and the recursive handling of Association.isComplexIdentifier(). Trace how the embedded identifier columns enter idColumnNames and nonIdColumnNames, then reproduce the generated UPDATE SQL from the Entity and CompositeId example. Done means composite-id columns appear in the WHERE clause but not the UPDATE SET clause.