Lazy load failure on items using <join> if FK for bag is in the secondary table
Description
Environment
Attachments
Activity
Fabio Maulo July 30, 2011 at 2:11 PM
Closed after final release of NH3.2.0GA
Fabio Maulo April 23, 2011 at 1:07 PM
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)
Fabio Maulo March 27, 2011 at 11:41 AM
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.
Tuna Toksoz May 17, 2009 at 2:31 PM
Tests added to trunk on rev4335
Anne Epstein April 17, 2009 at 1:04 PM
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
Anne EpsteinComponents
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.