[hibernate-dev] dehydrate knows acout the Hibernate mapping, disassemble does not.

[Steve Ebersole]

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 <
ericjvandervelden at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>