You are misusing the software. It is fully expected that you manage both sides of a bi-directional association in your code. The fact that it happens to work in one isolated case, I think, led you to believe that is supported. But it is not.
On Fri, Oct 3, 2014 at 10:00 AM, Eric J. Van der Velden < ericjvandervel...@gmail.com> wrote: > Hello, > > I have to correct my code because I work with a second level cache in the > following case (1-N bidirectional). > > Suppose we have a Container class type, with a Set<Item>, and an Item class > type. In the Hibernate mapping we make the Set non-inverse. > > For persistence of the Item instances we only have to add them to the > Container instance's Set, and I do not have to set the Container reference > in the Item instance. > > When an Item is inserted in the database table, the > Item-persister.dehydrate method skips the Container reference in the Item > instance, and takes the Long which is there because of > the BackrefPropertyAccessor$BackrefGetter.getForInsert() method. This will > be the foreign key in the row. > > The Item-persister.getPropertyInsertability()=[true,true,false,true] for > example, and the method Item-persister.dehydrate knows about it: The false > means: skip the Container reference in the Item instance, and the llast > true means: take this number (instead). > > My question is: Why does the Item-persister.disassemble not take into > account the Hibernate mapping? Because it does not, I have to make a > correction in my code to set the Container reference in the Item instances, > only for the second level cache. > > Thanks. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
