- Se descapó
- 19 de agosto de 2026 a las 2:12 UTC
- Autor
- Kamo
- Compromit
- 25140e0
La creación de una ventaja en un mercado hipotecario fracasó con "Database tabla LEADS hace no existir. Por favor, ejecute KamoInitializerApp para crear el esquema". La mesa estaba allí. El verdadero error fue: insertar en pistas (...) valores (...) devolviendo plomo-id ERROR: no existe la columna "lead-id" (SQLState 42703) La columna de id de pistas es UID. lead-id is LeadClaimMortgage's . Hibernate 6.2 construye el INSERT de la tabla raíz ... Cláusula de la JOINED SUBCLASS columna clave, así que sólo la subclase se rompió - un Plomo simple estaba siempre bien, por eso exactamente los mercados hipotecarios fracasaron. Reproducido en aislamiento; Hibernate 6.5 hace el mismo mapeo correctamente, pero Spring Boot 3.1.5 pins 6.2.13 sobre los servicios que lo gestionan. App-UID contra APPLICATIONS) llevaba el defecto idéntico, desenganchado. Arreglar ambos mediante la obtención del identificador de singular.rowid() ANTES de la inserción. Hibernate entonces no tiene nada que leer y no emite ninguna cláusula de RETURNING, que es correcto en 6.2 y 6.5 por igual. La misma secuencia de la columna que se extrae por defecto, por lo que los ids se mantienen por encima de 2-553 y siguen serializando como cuerdas; los impagos están intactos y todavía sirve SQL crudo. Sin cambio de esquemas... KamoInitializer no necesita correr. Renominar la columna clave del niño para que coincida con la raíz era la alternativa obvia y no es viable: el ddl-auto de KamoInitializer corre ante todos los corredors de migración y Añadiría primero una columna duplicada, y el PRIMARY KEY de la mesa de niños se sienta en esa columna, que YugabyteDB no puede volver a señalar en su lugar. SequenceGenerator on kamo-unique-rowid-seq también es inseguro - haría que la secuencia fuera exportable que ddl-auto podría crear START CON 1 contra una base de datos que falta el shim, repartiendo ids debajo de 2-53.