Eclipse Community Forums: EclipseLink » double record in history

Home » Eclipse Projects » EclipseLink » double record in history

double record in history [message #653675]

Thu, 10 February 2011 11:16

Eclipse User

I have a N-M "article2storage" table holding the two keys of the relationship (article and storage). When in the article or storage management Swing window this relaltion is removed, the article2storage entity is removed from the collection AND the article or storage reference is cleared.

So, for example, in the article screen, when the article2storage relation needs to be deleted, article2storage.article is set to null.

Then the entity is merged and deleted when the save button is pressed.

This is what is written to the table:
oidnr articlenr storagenr lazylock dwhmodified dwhby hstvalidfrom hstvaliduntil
372266 82 37111 1 2011-02-10 17:02:49 69 2011-02-10 17:02:49 2011-02-10 17:02:59
372266 (null) 37111 2 2011-02-10 17:02:57 69 2011-02-10 17:02:59 2011-02-10 17:02:59

The relation was between article 82 and storage 37111. It was created 17:02:49 and deleted 17:02:59. Then a record is added where the articlenr is set to null. Any idea why?

I"m using EclipseLink 2.0.2

Tom

Re: double record in history [message #654195 is a reply to message #653675]

Mon, 14 February 2011 09:48

Eclipse User

Ca you include the mapping code and the SQL generated.

Are you using a ManyToManyMapping with a HistoryPolicy?

The result seems correct though? You set the reference to null and removed it, and it nulled the reference and then recorded it as no long active?

Re: double record in history [message #654204 is a reply to message #654195]

Mon, 14 February 2011 10:06

Eclipse User

No, the N-M is mappend as a separate entity using 2x 1-N. The end result is correct, only one record too many.

It may have to do with my other post: double insert.

Tom

On 14-2-2011 15:48, James wrote:
> Ca you include the mapping code and the SQL generated.
>
> Are you using a ManyToManyMapping with a HistoryPolicy?
>
> The result seems correct though? You set the reference to null and removed it, and it nulled the reference and then recorded it as no long active?
>

Re: double record in history [message #654259 is a reply to message #654204]

Mon, 14 February 2011 14:23

Eclipse User

Hello Tom,

What are you using as the primary key on article2storage? This could occur if you marked the relationships as well as the sequence field to be a composite primary key - it cannot be changed or it will think its a different entity.

Best Regards,
Chris

Re: double record in history [message #654289 is a reply to message #654259]

Mon, 14 February 2011 17:36

Eclipse User

On 14-2-2011 20:23, Chris Delahunt wrote:
> Hello Tom,
>
> What are you using as the primary key on article2storage? This could occur if you marked the relationships as well as the sequence field to be a composite primary key - it cannot be changed or it will think its a different entity.
> Best Regards,
> Chris

There is a separate primary key "oid", the articlenr, storagenr combination is a unique constraint.

Re: double record in history [message #654405 is a reply to message #654289]

Tue, 15 February 2011 10:43

Eclipse User

Are you using field access or property access? If you are using property access for JPA, that means that the provider must use your set/get methods as well - be sure you do not have any business logic or relationship management in these methods. If that is not the case, you will need tp provide additional information such as the logs and the entities, as there is not enough to go on.

Best Regards,
Chris

Re: double record in history [message #654409 is a reply to message #654405]

Tue, 15 February 2011 10:46

Eclipse User

Nope, field access. Properties are the "API" for the higher levels of the application, field access is downward to EclipseLink and the database. I will look into this problem more on thursday.

On 15-2-2011 16:43, Chris Delahunt wrote:
> Are you using field access or property access? If you are using property access for JPA, that means that the provider must use your set/get methods as well - be sure you do not have any business logic or relationship management in these methods. If that is not the case, you will need tp provide additional information such as the logs and the entities, as there is not enough to go on.
>
> Best Regards,
> Chris

Re: double record in history [message #654874 is a reply to message #654409]

Thu, 17 February 2011 08:34

Eclipse User

Ok. The double insert is resolved, so back to this problem. It indeed is the set-articlenr-to-null that causes the additional record.

lArticle2Storage.setArticle(null);
lEntityManager.clear();
lEntityManager.getTransaction().begin();
lEntityManager.merge(lArticle);
lEntityManager.remove(lEntityManager.merge(lArticle2Storage) );
lEntityManager.getTransaction().commit();

This results in the following records in HST:

oidnr articlenr storagenr lazylock dwhmodified dwhby hstvalidfrom hstvaliduntil
372301 82 37111 1 2011-02-17 14:17:45 1 2011-02-17 14:17:45 2011-02-17 14:22:18
372301 (null) 37111 2 2011-02-17 14:22:18 1 2011-02-17 14:22:18 2011-02-17 14:22:18

The existing record is closed, a new record is created and closed immediately.
Incorrect? No. In the end the record is deleted.
Expected? No.

Naturally the reason why articlenr is set to null, is to take it out of the two-sided 1-N relation with article in memory, so it is not shown on screen any more.
This two-sided relationship is managed by the BM; if I remove article2storage from the collection in article, its counterpart (the pointer to article) is set to null. This is to keep stuff consistent in memory.

So. There is an update executed on the actual record prior to the delete. Is it possible to skip recording the update and just record the end result, the delete? Or even better; skip the update entirely?

Tom

Re: double record in history [message #654927 is a reply to message #654874]

Thu, 17 February 2011 11:16

Eclipse User

In general EclipseLink updates objects that will be deleted if they are changed, as the update may be desired by the user and required to resolve constraints.

If you don't want the update, the best solution is to not update your object.

EclipseLink does have an option to performDeletesFirst which you could enable, this will avoid the update, but could lead to deletion constraint issues.

You could also refresh or revert the object before removing it.

In general the update should not cause any issues, so you could just ignore it as well.

Previous Topic:	Incorrect PostgreSQL's BLOB support in EclipseLink JPA
Next Topic:	@OneToMany MappedBy behaviour - list not initialized

Goto Forum:

-=] Back to Top [=-

Current Time: Fri Jul 04 22:17:07 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter