- Shipped
- August 19, 2026 at 2:12 AM UTC
- Author
- Kamo
- Commit
- 25140e0
Creating a lead on a mortgage market failed with "Database table LEADS does not exist. Please run KamoInitializerApp to create the schema." The table was there. The real error was: insert into leads (...) values (...) returning lead_id ERROR: column "lead_id" does not exist (SQLState 42703) leads' id column is UID. lead_id is LeadClaimMortgage's @PrimaryKeyJoinColumn. Hibernate 6.2 builds the root table's INSERT ... RETURNING clause from the JOINED SUBCLASS's key column, so only the subclass broke -- a plain Lead was always fine, which is why exactly the mortgage markets failed. Reproduced in isolation; Hibernate 6.5 renders the same mapping correctly, but Spring Boot 3.1.5 pins 6.2.13 on the services that run this. AppMortgage (APP_UID against APPLICATIONS) carried the identical defect, unhit. Fix both by fetching the id from unique_rowid() BEFORE the insert. Hibernate then has nothing to read back and emits no RETURNING clause at all, which is correct on 6.2 and 6.5 alike. Same sequence the column default draws from, so ids stay above 2^53 and keep serializing as strings; the defaults are untouched and still serve raw SQL. No schema change -- KamoInitializer need not run. Renaming the child key column to match the root was the obvious alternative and is not viable: KamoInitializer's ddl-auto runs before every migration runner and would add a duplicate column first, and the child table's PRIMARY KEY sits on that column, which YugabyteDB cannot repoint in place. @SequenceGenerator on kamo_unique_rowid_seq is also unsafe -- it would make the sequence an exportable that ddl-auto could create START WITH 1 against a database missing the shim, handing out ids below 2^53.