Hi again,
this morning I found a way around this behavior: I removed the embeddable from our database mapping and instead directly mapped the OneToMany to the owner of the embeddable.
By now I'm quite sure that this is a major bug in EclipseLink which already led to data loss at one of our customers. I am willing to track this bug down and write a fix, but since my last bugfix pull request is still open since quite some time (3 months), I would first like to know: Does it make sense to put any work into this or will my efforts to fix this bug also be ignored?
If the latter is the case: Is EclipseLink even supposed to be used in production, if such bugs go unnoticed and nobody cares to fix them (or even just review pull requests that fix them)?
The result of my bug analysis at this moment is as follows:
* The AggregateObjectMapping of the embeddable creates a new instance of the embeddable object if the embeddable instance that is merged into the persistence context is the same instance as already present in the persistence context
* Thereafter the AggregateObjectMapping wants to merge all data into the newly created object
* all Downstream CollectionMappings bail out of the merge, since the merge-source objects are uninitialized indirect collections. The parameter 'isTargetUnInitialized' is ignored.
What I do not know at this moment:
* Why does the AggregateObjectMapping create a new object of the embeddable in the first place?
Any help on this would be appreciated. Thanks in advance.
Best regards
Alexander Lehmann
Am Do., 11. Juli 2019 um 18:43 Uhr schrieb Alexander Lehmann <
a.lehm@xxxxxx>:
Hi all,
today I
came across a weird behavior in EclipseLink 2.7.4 which I do not understand:
We load an
entity from the database that contains a lazy OneToMany mapping to another
entity (inside an embeddable) with cascade ALL. This entity is manipulated without touching the
indirect collection, so the collection stays uninitialized.
When we
then merge this manipulated entity back into an EntityManager, the unitialized
indirect collection is set to ‘null’ on the EntityManagers clone of the entity.
When we then commit the transaction. The CollectionMapping#compareForChange()
method uses getAttributeValueFromObject(clone) which replaces the ‘null’ with
an IndirectList containing an empty value holder. This leads to all elements
being removed from the mapping which I expected not to happen.
Is this a
bug in EclipseLink or did we do something wrong? Thanks in advance for any feedback
on this.
Best
Regards
Alexander
Lehmann
