Why is Hibernate's @DynamicUpdate part of the recipe for column-comparison optimistic locking, and what does Hibernate do with UPDATE statements by default without it?

## Hibernate's default: one statement per entity When the persistence unit boots, Hibernate generates and caches the SQL for each entity's basic operations. The `UPDATE` has a fixed shape: ```sql update product set name = ?, price = ?, stock = ? where id = ? ``` Every mapped column appears in `SET`, regardless of what changed, and the `WHERE` names only the identifier — plus the version column when the entity has one. Dirty checking still decides *whether* to issue the statement; it does not shape it. That is why people are surprised to see all columns written after changing one field. The design is deliberate. Building SQL once removes work from every flush, and because the string is identical every time, the JDBC driver's prepared-statement cache and the database's plan cache both hit reliably. In a hot write path that is a real advantage. ## Why column-comparison locking breaks the assumption Versionless locking needs old values in the `WHERE` clause: - With `OptimisticLockType.ALL`, the clause is `id = ? and <every column> = ?`. The *shape* is fixed, so this can in principle be pre-generated — the values differ per flush but the text does not. - With `OptimisticLockType.DIRTY`, the clause contains only the columns modified in this flush. Change the price and it is one thing; change the name and it is another. There is no single statement text, so a statement generated once at bootstrap cannot serve it. Hence `@DynamicUpdate`, which moves SQL generation to flush time: Hibernate compares the entity's current state with its loaded-state snapshot, and builds an `UPDATE` naming exactly the changed columns in `SET` and exactly the required columns in `WHERE`. ## Why pair it with ALL too Even where it is not strictly required, dynamic generation is the conventional companion: - **Fewer written columns.** Rewriting untouched columns with their existing values is pointless IO, and on wide rows or rows containing large text or binary columns it is expensive. - **Triggers and auditing.** Database triggers, change-data-capture and column-level audit tooling often key off *which* columns an `UPDATE` touches. A statement that always sets everything makes every update look like a full-row change. - **Fewer surprises with concurrent writers.** Writing back a column you never intended to touch re-asserts a stale value for it; with the full-row comparison it will be caught, but not writing it at all is simply better behaviour. ## What it costs SQL is now built on every flush that dirties an entity. The generation itself is cheap, but the consequence downstream is not free: different modification patterns produce different statement texts, so the prepared-statement cache holds more entries and hits less often, and the database sees more distinct plans. For entities updated at very high rates this is measurable, which is why `@DynamicUpdate` is an opt-in per entity rather than a global default. It is also worth knowing that batching interacts with this: JDBC batching groups identical statements, so varying statement text reduces how effectively updates batch together. If you rely on batched writes for a bulk path, verify the effect there. ## The counterpart `@DynamicInsert` is the same idea for inserts — omit columns that are null at insert time so database defaults apply. It is unrelated to locking but comes from the same trade-off family: less pre-generation, more per-operation work, better-shaped SQL. ## How to summarise it "Hibernate normally reuses one pre-built `UPDATE` per entity that sets all columns and filters on the id. Column-comparison locking, especially the dirty-columns variant, needs a statement whose shape depends on this flush, so `@DynamicUpdate` moves generation to flush time — at the price of statement-cache efficiency."