Re: [eclipselink-users] Order of operations in EclipseLink

[patric@xxxxxxxxxxx]

Hi Tom,

I understand that any O/R mapper needs to track  
relationships/integrity of the entities that the
foreign key relations/constraints would not be broken or violated.

In my project we're only using disabled foreign key constraints in the  
oracle database to map the parent-child structure only but not to  
enforce the integrity.
So when looking at my code snippet below EclipseLink could do all  
operations in the correct order without any problems.

Are there other arguments beside enabled foreign key constraints which  
would prevent the use of the real operation order?

Although the use of a flush() would help me out, it's a little bit  
more difficult than my code example below.
Imagine that the first persist, the removal and the re-insertation are  
located in different code parts and some code outside their  
implementation control which parts are invoked.
To be safe, we have to add a flush() after each part. This would cause  
a significantly performance degrade because flush() is costly  
operation, especially in my project (we're using client session  
customizers to intercept changeset calculations to track and archive  
all changes in some database tables).

Thank you and best regards,
Patric



Zitat von Tom Ware <tom.ware@xxxxxxxxxx>:

> As mentioned in the article listed below.  EclipseLink (and many  
> other Object-Relational providers) orders the deletes last because  
> it facilitates maintenance of referential integrity.  An O-R tool  
> must do more than just send SQL to a database.  It has to maintain  
> the identity and the integrity of the relationships among the  
> objects it is managing.  (e.g. Imagine you delete an object that is  
> part of a relationship.  EclipseLink must be able to update any  
> foreign keys that form the relationship before doing the delete, or  
> you will get exceptions related to Foreign Key constraints)
>
> You can control when different parts of you transaction are executed  
> using the em.flush() API.
>
> If you need to get at the performDeletesFirst API, you can use  
> org.eclipse.persistence.jpa.JpaHelper.getEntityManager(entityManager) and  
> call getUnitOfWork() on the returned JpaEntityManager.
>
> -Tom
>
> Rohit Banga wrote:
> >  Hi Patric
> > See the following link
> > http://goo.gl/2oH4P  
> > <http://wiki.eclipse.org/Using_Advanced_Unit_of_Work_API_%28ELUG%29#How_to_Use_the_setShouldPerformDeletesFirst_Method_of_the_Unit_of_Work>
> >
> > Michael
> > The above link shows how to configure it using UnitOfWork. Is there  
> > a way to do it using the EntityManager?
> >
> > Thanks
> > Rohit
> >
> > On 12/30/2010 4:56 PM, Michael Simons wrote:
> > > Hi Patric,
> > >
> > > AFAIK it is an intentional behaviour, EL just like any other  
> > > JPA/JDO implementation that we've used (EL, OpenJPA, etc) do  
> > > inserts before deletes.
> > > I don't remember the reason. I just remember there was one. Maybe  
> > > someone else can explain that to us.
> > > To keep the AK you can either flush right after the delete or  
> > > replace the delete/insert by an update.
> > >
> > > -Michael
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: eclipselink-users-bounces@xxxxxxxxxxx  
> > > [mailto:eclipselink-users-bounces@xxxxxxxxxxx] Im Auftrag von  
> > > patric@xxxxxxxxxxx
> > > Gesendet: Mittwoch, 29. Dezember 2010 14:27
> > > An: EclipseLink-users@xxxxxxxxxxx
> > > Betreff: [eclipselink-users] Order of operations in EclipseLink
> > >
> > > Hi,
> > >
> > > imagine a simple table/entity TestTable with an AK on column status.
> > >
> > > The following operations will fail using EclipseLink:
> > >
> > > TestTable tt = new TestTable();
> > > tt.setStatus("BLA");
> > > em.persist(tt);
> > > em.flush();
> > >
> > > em.remove(tt);
> > >
> > > TestTable tt2 = new TestTable();
> > > tt2.setStatus("BLA");
> > > em.persist(tt2);
> > > em.flush(); //this will throw an exception due to AK violation
> > >
> > >
> > > However, I would expect a successfull run because I previously  
> > > removed  the record which has the same AK.
> > >
> > > It seems that the operation order is modified by EclipseLink -
> > > inserts seems to be executed first which might change the outcome  
> > > of a  set of operations.
> > > Is this an intentional behaviour?
> > > If it is, is there a possibility to preserve the operation order?
> > >
> > > Thank you and best regards,
> > > Patric
> > >
> > >
> > > _______________________________________________
> > > eclipselink-users mailing list
> > > eclipselink-users@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> > > _______________________________________________
> > > eclipselink-users mailing list
> > > eclipselink-users@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> >
> > --
> > Thanks and Regards
> > Rohit Banga
> > Member Technical Staff
> > Oracle Server Technologies
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > eclipselink-users mailing list
> > eclipselink-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipselink-users