I'm seeing something odd with cascading a persist() operation from a parent to a child object, where the parent's primary key is defined with GenerationType.IDENTITY.
In my local H2 database, this kind of thing works fine. Given an unmanaged parent linked to an unmanaged child with CascadeType.PERSIST, I persist the parent. I can see from debugging and various lifecycle listeners that this all works fine: even though the parent doesn't have a valid primary key until INSERT time, somehow EclipseLink correctly figures out what's going on, sticks the parent in, grabs his generated key, updates the child, and persists the child as well. Both objects end up being managed and both have the correct values in their primary and foreign key fields.
In our corporate Informix database, however, this same operation blows up with a foreign key violation error before the transaction is committed.
I suspect we're hitting an issue with the fact that Informix, by default, requires that all foreign keys be ALWAYS valid, not just valid at transaction commit time. I'm further speculating that at some point in the cascading-persist support, EclipseLink is setting an invalid foreign key reference on the child--deliberately--and then correcting it before transaction commit time.
Does that accurately represent how EclipseLink handles cascade persist relationships when the parent uses a generated key?
Best,
