|
My apologies, this post in German was meant to be sent to Alexander only but I failed to use the correct keyboard shortcut.
However, maybe the public is also interested on its content, so I'm happy to provide it in English:
Hi Alex,
although I cannot contribute directly to your question, I find your concerns valid
regarding the current state of eclipselink development.
We use EclipseLink in production for many years and we use certain workarounds for unfixed bugs.
It's sad that development seems to be slowed down to a minimum with only a few commits this year and more than 2000 opened bugs.
We would love to hear that the EclipseLink project will be brought back to live again,
in this case, we would be willing to contribute bug reports/fixes/PR to the project.
I'd be happy if a member of the official development team would communicate the current state of the project
and its future - thanks!
Best regards,
Patric
On 12.07.2019 13:20, Patric Rufflar wrote:
Hi Alexander,
ich kann zwar nicht direkt etwas zu deinem Problem beitragen,
möchte dich aber wissen lassen, dass ich deine Kritik an dem EclipseLink-Projekt absolut berechtigt finde.
Auch wir setzen EclipseLink seit vielen Jahren in der Produktion ein und nutzen für bestimmte Bugs einige Workarounds,
die wir durch unit tests besichern.
Seit einiger Zeit scheint sich in Sachen Weiterentwicklung offenbar nicht mehr viel zu bewegen
- trotz teilweise schwerer Bugs sowie zahlreicher Pull Requests.
Laut GitHub gab es in diesem Jahr nur eine handvoll Commits, trotz mehr als 2000 offener bugs.
Das ist enttäuschend, aber wohl typisch für viele Eclipse-Projekte.
Man merkt auch, dass sich der große Sponsor für EclipseLink, Oracle, hier vor etwas fünf Jahren massiv Personal und Geld abgezogen hat.
Drücken wir uns die Daumen, dass sich hier etwas ändert, dann wären wir auch bereit, wieder Fixes bzw. PR
für das Projekt zur Verfügung zu stellen.
Viele Grüße
Patric
On 12.07.2019 11:46, Alexander Lehmann wrote:
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
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipselink-dev
|
