I've got an odd problem where data in a List that was once persisted gets nulled out on an 'update' operation.

For a trivial example, class T1 has a one-to-many relationship with T2, implemented thus:



...etc

here's how they are mapped:



My problem is that if I do this:



What I end up with are 5 new entries in the t2 table, with the first two (at idx 0 & 1) having NULL in the t1_id column. The last three rows (indices 2-4) are populated with the t1_id as they should be.

I've written a test cast which exposes this behavior, and have verified that after the 'save()' and before the 'update()', the t1_id exists for all the new t2 entries. It's only when updating the t1 object that its t2 references which existed prior have their t1_id field nulled out.

Is this a problem with my cascade setting? I've verified this behavior is database independent, as I can produce it in Oracle and PostgreSQL. I'm using Hibernate v. 3.2

I've got the mapping files, the classes, and the test case in an archive and can give it via email if anyone wants to try to reproduce this error. Any help is much appreciated!!!
--Kris

OK, so as soon as I posted this, I found a way to hack around the problem by doing the following before my session.update():



So the obvious problem is that my t1Id property in my T2 objects aren't being set during the initial call to session.save(), even though the foreign key itself is being written, so that when I call update(), hibernate finds that t1Id is null for those T2 objects which are already persisted, and nulls out the database field (blowing away my fkey) accordingly. Eff.

I found some solutions in the Hibernate docs telling me to add 'update' and 'not-null' attributes to the <key> declaration, but I kept throwing ExceptionInInitializerError...the Hibernate config wouldn't even load.

A coding error, wouldn't you know.

Here was the composition of my nextT2() method:



Since the id on my T1 objects is generated from a sequence, they have no id (the id property, type Long, is null) prior to my call to session.save(). So every T2 instantiated before session.save() is getting a null object passed to setT1Id().

So Hibernate's using the T1 list to create new entries in the t2 table (which is why the t1_id fkey gets initially written), but for updating existing t2 table entries, it's going to the associate T2 object and writing sql NULL into fields whose mapped property contains a null object.