Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » Are UnitOfWork#hasChanges side effects a bug?
Are UnitOfWork#hasChanges side effects a bug? [message #559066] Wed, 15 September 2010 13:46 Go to next message
Dominik Maehl is currently offline Dominik Maehl
Messages: 6
Registered: July 2009
Junior Member
Hi everyone,

We're building a RCP app which uses EclipseLink as its ORM.

Yesterday we've discovered a behaviour which in our opinion is a bug. But as we're very new to JPA and EclipseLink I want this groups opinion on the behaviour we spotted:

We have a class named Document and a child entity named Reminder. The child entity is mapped via OneToMany in the document with cascade=ALL and @PrivateOwned.

We also use UnitOfWork to detect changes with the Method "hasChanges". And here comes the problem: When we add a Reminder to a document and call "hasChanges", then remove the reminder from the collection it saves the Reminder without a reference to the Document. If I don't call hasChanges it simply does nothing (which is correct as we didn't change anything).

The log produces the following when calling hasChanges:
2010-09-15 15:45:14 transaction [TRACE] PERSIST operation called on: [Reminder:NEW(-44)]

The annotations on document are as follows:
@PrivateOwned
@OneToMany(cascade=CascadeType.ALL, fetch = FetchType.EAGER)
@JoinColumn(name = "PT_PD_REC")
private List<Reminder> reminders = new ArrayList<Reminder>();


There is no mapping in Reminder to Document.

In my opinion hasChanges should be side effect free but is not which shows in the "PERSIST operation". Is there anything we can do?

Thanks for your time.
Re: Are UnitOfWork#hasChanges side effects a bug? [message #559150 is a reply to message #559066] Wed, 15 September 2010 19:00 Go to previous message
Chris Delahunt is currently offline Chris Delahunt
Messages: 1034
Registered: July 2009
Senior Member
Please file a bug to have this behavior changed, and vote for it. This is occuring because the relationship is traversed when hasChanges is called, forcing the Reminder object to be registered so that it can be included in the calculated changes. Unfortunately, it is unable to unregister objects found this way. And because it is not incremental like flush (changes are just thrown away) it has no way of keeping track that a Reminder was added through the privately owned 1:M relationship - when commit eventually occurs, EclipseLink will not see any changes in the collection from when the object was registered, so it can't determine that the Reminder object should be unregistered/deleted.

After you call hasChanges, you will need to treat all transitional (not yet persistent) relationships as if the objects referenced were registered independently. In this case, it means calling unregister or remove on the Reminder instead of just dereferencing it. Or, you can using the JPA flush mechanism which better allows getting incremental changesets.

Best Regards,
Chris
Previous Topic:MOXy example missing?
Next Topic:Embeddables don't inherit their 'isolation' status
Goto Forum:
  


Current Time: Thu Oct 23 12:42:15 GMT 2014

Powered by FUDForum. Page generated in 0.02159 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software