[hibernate-issues] [Hibernate-JIRA] Updated: (HHH-2763) (lazy) m:n relation + EventListener = AssertionFailure: collection [n-side] was not processed by flush()

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] C. Delaloye updated HHH-2763: ----------------------------- Attachment: one-to-many_with_many_side_having_collections.gif bidirectional_many-to-many.gif HHH-2763_standalone_testcases.zip In order to help the understanding of my previous comments, and I hope of the overall problem, I've prepared two testCases which reproduce / illustrate the problem. The attached HHH-2763_standalone_testcases.zip contains a "standalone" (no need of an app. server) Eclipse Project with a JUnit TestCase that reproduces the problem for these two mapping patterns: - testHibernateBugHHH2763Case1 (bidirectional many-to-many) this is the case initially described by the reporter - testHibernateBugHHH2763Case2 (one-to-many with many side having collections): this is a concrete case which is perhaps what Geoffrey De Smet has met but (to my mind) confusingly reported in it's comment of August 16th Please have a look at the attached files bidirectional_many-to-many.gif and one-to-many_with_many_side_having_collections.gif which give a graphical overview of the objects and relations. These two cases uses a pre-update Listener which causes a Collection to be loaded during the flush phase and then lead to the "was no processed by flush()" exception. Entry point is Class: ch.rtc.infra.protok.client.InPro_ProtokHibernateEventListenerHibernateBugs_tc Required to compile and run: - hibernate jars - junit.jar - commons-collections.jar, commons-lang.jar - hsqldb.jar Another formulation of the bug would be: the bug occurs when elements of a lazy collection (1) are loaded during a flush phase by a custom pre- or post- Event. When these loaded elements (2) have mapped Collections (3), hibernate creates a CollectionEntry for each of them (them = mapped Collections). The problem is that these created CollectionEntries are instantiated with flag processed=false and they have no chance to have their "processed" flag set to true, as this only occurs in pre-flush phase and as this pre-flush phase is already done. Consequently, the CollectionEntry.postflush() method which checks this "processed" flag will raise the "was no processed by flush()" exception. illustrated with Case2 (one-to-many with many side having collections): (1) elements of a lazy collection: InPro_ParentWithLazyCollectionOfChildren.childrenWithCollections (many side) (2) these loaded elements: instances of InPro_ChildWithCollections (many side) (3) mapped Collections: collections defined on the many side: InPro_ChildWithCollections.collectionOfSimpleObjects and InPro_ChildWithCollections.collectionOfValues Note that: - the problem is not dependent of the fact that the collection on the many side is lazy or not. - the problem also occurs if the many side has collections of values -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira