Lazy load failure on items using <join> if FK for bag is in the secondary table
Description
Environment
Attachments
Activity
Closed after final release of NH3.2.0GA
Applied the whole fix... we have to add an early check for column-name used to represent different relations (comments added to the code for possibly future issues)
Solution found but it break some cases (just one of our +3K tests).
The case broke is when a same column name is used to represent another relation in the hierarchy.
The test NHibernate.Test.Legacy.MultiTableTest.MultiTableCollections show one of this cases.
The column named "parent" is used to as key of Lower.Set (unidirectional relation) and as FK of SubMulti.Parent (self bidirectional relation).
I can't apply the fix, I'll commit the fix commented and then we have to talk about this and other matters related to columns-naming in our dev-list.
Inside an hierarchy a column-name should follow similar rules of properties-name (you can't have tow properties with the same name).... well... the case is something long to explain here and we have to check viability.
Tests added to trunk on rev4335
It might also be worth noting that I ran across this when using a less-usual subclassing strategy, "Mixing table per class hierarchy with table per subclass" http://www.nhforge.org/doc/nh/en/#inheritance-mixing-tableperclass-tablepersubclass.
Details
Details
Assignee
Reporter
Components
Fix versions
Affects versions
Priority
Minor
When an element is mapped using <join> that contains a many-to-one that has that many-to-one key in the secondary table, and that element is put in a bag and lazy-loaded, the lazy load fails because the resulting SQL looks for the key in the element's primary table, not the secondary table.
I'm attaching a test-when I run this on a preexisting db, it gives a SQL error for a nonexisting column. When a schema is generated from the mapping, it (incorrectly) has the many-to-one FK in both the primary and secondary element tables-it uses the correct one when traversing from the element, but uses the wrong one when traversing from bag to child elements.
The core issue seems to be that NHibernate doesn't know (and there doesn't seem to be a way) to tell a bag that the key column is in a secondary table of a join, not the primary one.