jamesfredley commented on code in PR #16756: URL: https://github.com/apache/grails-core/pull/16756#discussion_r4369964455
########## grails-doc/src/en/guide/upgrading/upgrading80x.adoc: ########## @@ -1460,7 +1460,7 @@ A type that spans several columns no longer implements `UserType` with several ` Under Hibernate 7, an owner with two or more unidirectional `hasMany` associations wrote no rows to their join tables: an element added to any of them was lost at flush (issue https://github.com/apache/grails-core/issues/16665[#16665]). This is fixed when each association has a join table of its own, which is the default (`item_roles` and `item_tags` for `static hasMany = [roles: Role, tags: Tag]`) and also the case when two associations to the same class map different tables with `joinTable`. Each such join table is written, as under Hibernate 5. -Two unidirectional sets mapped onto one shared join table, with a key column each, are written as well: each association keeps its rows unique by its own key column and the element. A list or a map is left as it was: its join table is keyed by the index, and its elements may repeat. On most databases that is a unique key per association; on Oracle and on Db2 for Linux, UNIX and Windows, which compare the non-null columns of a partially null row in a unique key, it is one unique key over the key columns of both associations and the element. A schema created by an earlier Grails 8 release has the single unique key Hibernate made for the first association: `dbCreate` of `update` adds the second one, and on Oracle and Db2 for Linux, UNIX and Windows a migration has to replace that key with the wider one. +Two unidirectional sets mapped onto one shared join table, with a key column each, are written as well: each association keeps its rows unique by its own key column and the element. Two lists or two maps sharing a join table are written too (issue https://github.com/apache/grails-core/issues/16700[#16700]): each keeps its rows unique by its own key and index columns, since a position or a map key is taken once while an element may repeat, and the table has no primary key, because the one Hibernate makes over one list's key and index columns rejects every row of the other list. A schema created by an earlier Grails 8 release has that primary key and `NOT NULL` index columns, which `dbCreate` of `update` does not change: drop the primary key and make the index columns nullable with a migration. On most databases that is a unique key per association; on Oracle and on Db2 for Linux, UNIX and Windows, which compare the non-null columns of a partially null row in a unique key, it is one u nique key over the key columns of both associations and the element. A schema created by an earlier Grails 8 release has the single unique key Hibernate made for the first association: `dbCreate` of `update` adds the second one, and on Oracle and Db2 for Linux, UNIX and Windows a migration has to replace that key with the wider one. Each collection on a shared join table isolates its rows during reads, element removals, and bulk deletes: for lists and maps sharing the same foreign-key and element columns, queries and deletions are restricted by each list's distinct index column so neither collection interferes with the other. Review Comment: With a separate owner-key column per list, Hibernate's old primary key also made that owner column `NOT NULL`. Dropping the key and relaxing only the index columns leaves it, so an insert into the other list still fails because its owner column is null. Add the owner-key columns to the nullability change, as the binder does. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
