Eclipse Community Forums: EclipseLink » Are UnitOfWork#hasChanges side effects a bug?

Help

Home

Home » Eclipse Projects » EclipseLink » Are UnitOfWork#hasChanges side effects a bug?

Show: Today's Messages :: Show Polls :: Message Navigator

Are UnitOfWork#hasChanges side effects a bug? [message #559066]

Wed, 15 September 2010 13:46

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.

Report message to a moderator

Re: Are UnitOfWork#hasChanges side effects a bug? [message #559150 is a reply to message #559066]

Wed, 15 September 2010 19:00

Chris Delahunt

Messages: 1389
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

Report message to a moderator

Previous Topic:	MOXy example missing?
Next Topic:	Embeddables don't inherit their 'isolation' status

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 20:08:33 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter