Hello; this is a strange one.
I have two classes that implement Organization. One is for
our green-field system, and one is a snarling beast that maps
our legacy system tables and logic into the Organization
contract.
So:
Organization <--implements-- OrganizationEntity
Organization <--implements-- OldOrganizationEntity
I have two EntityManagers in flight. One (greenEm) is
hooked up to our green-field app, and the other (oldEm) is
hooked up to our legacy app.
OrganizationEntity is in greenEm's persistence unit.
OldOrganizationEntity is in oldEm's persistence unit.
I then have another entity (a PostalAddress implementation)
that refers to an Organization. It is in oldEm's persistence
unit.
At the time that I go to save a PostalAddress, for various
reasons it might be referring to an OrganizationEntity. That
turns out to be bad from the standpoint of oldEm, because even
though OrganizationEntity is by definition not a managed
object (as far as oldEm is concerned), EclipseLink will puke
if I try to persist my PostalAddress entity. This is even
though EclipseLink shouldn't? I don't think? be traversing
these relationships (I use CascadeType.NONE).
To work around *this* bug (or at least the
NullPointerException it fires off if it's not really a bug),
just before persist time, I save off the old Organization
reachable from the PostalAddress, and using black magic find
the appropriate OldOrganizationEntity that corresponds to it.
I then set THAT guy on the PostalAddress. Again, this
shouldn't affect anything, really, as I'm not asking for the
persist() operation to cascade, but I'm just trying to work
around the NullPointerException
The net effect is that I now have a PostalAddress that no
longer contains any entities that are unknown to oldEm. I
call persist(), which works fine, and then flush() (to
retrieve a generated identifier from the legacy database),
then detach() on my postal address, and then I set the
original Organization back on the PostalAddress. It's as
though nothing has changed.
But oldEm pukes on that final woven set call with the
following stack:
java.lang.NullPointerException
at
org.eclipse.persistence.mappings.ObjectReferenceMapping.setNewValueInChangeRecord(ObjectReferenceMapping.java:218)
at
org.eclipse.persistence.mappings.ObjectReferenceMapping.internalBuildChangeRecord(ObjectReferenceMapping.java:207)
at
org.eclipse.persistence.mappings.ObjectReferenceMapping.updateChangeRecord(ObjectReferenceMapping.java:1400)
at
org.eclipse.persistence.internal.descriptors.changetracking.AttributeChangeListener.internalPropertyChange(AttributeChangeListener.java:149)
at
org.eclipse.persistence.internal.descriptors.changetracking.AttributeChangeListener.propertyChange(AttributeChangeListener.java:111)
at
com.jenzabar.ngp.constituent.cx.jpa.AlternateAddressRecordEntity._persistence_propertyChange(AlternateAddressRecordEntity.java)
at
com.jenzabar.ngp.constituent.cx.jpa.AlternateAddressRecordEntity._persistence_set_constituent(AlternateAddressRecordEntity.java)
at
com.jenzabar.ngp.constituent.cx.jpa.AlternateAddressRecordEntity.setConstituent(AlternateAddressRecordEntity.java:1368)
// this is the line where I set the old organization back;
just a regular old setter call
So in trying to work around one NullPointerException I'm
encountering another.
Tall order, but does anyone have any idea how I can persist
just the parent without triggering the cascade here (even
though CascadeType.NONE is present)?
Thanks,
Best,
Laird
