Summary

jakarta.persistence.GenerationType.TABLE is rejected at boot. Support it, so that a counter can live in an application-named collection with application-named fields, as @TableGenerator describes.

Why it is not free

The storage mechanism already exists: sequence-style generation keeps each counter in one document holding the next value to hand out and the increment, allocated with a single findAndModify. @TableGenerator is the same counter with the collection name, key field and value field supplied by the application instead of fixed.

What blocks it is that Hibernate ORM composes these statements itself rather than routing them through the dialect's translator. org.hibernate.id.enhanced.TableGenerator builds buildSelectQuery from SimpleSelect with a PESSIMISTIC_WRITE lock, and buildUpdateQuery/buildInsertQuery by string concatenation. Those strings reach the JDBC adapter as SQL text such as select next_val from hibernate_sequences where sequence_name = ? for update and fail to parse as MQL.

Note also that the generator's algorithm stays Hibernate's: select, then a conditional update guarded by the value just read, then retry on a lost race. That is two or more round trips per allocation where the sequence path takes one.

Scope

• A TableGenerator subclass overriding buildSelectQuery, buildUpdateQuery and buildInsertQuery to emit MQL.
• Interception of generator resolution so GenerationType.TABLE selects that subclass.
• Removal of the boot-time rejection.

Acceptance

An entity with @GeneratedValue(strategy = TABLE) and a @TableGenerator naming a table, key column and value column persists and reloads. Allocated identifiers are unique under concurrent inserts. A pooled optimizer consumes a block without a round trip per row.