[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipselink-users] Order of operations in EclipseLink
|
Hi Patric,
While it's true that in simple projects without foreign key constraints, it
would be possible to simply execute operations in the order they were called,
solving that problem would require more complex way of detecting the changes you
have made. As you changed things, we would have to build an ordered list of
all the changes (including minor updates to fields).
EclipseLink's change detection is optimized to allow SQL to execute correctly
in the general case. We do one of two things:
1. Accumulate an unordered list of changes as you make changes
2. Calculate a list of changes at flush time based on comparisons to clones
When we have the list of changes, we execute it against a pre-calculated
commit order so as to avoid any issues with foreign keys or relationships.
Our goal is to write changes in the most efficient way possible while still
ordering things correctly for the general case and avoiding foreign key issues.
Maintaining an ordered list of changes would be inefficient and likely to
cause issues in all but cases with very simple mappings.
We provide the perform deletes flag to cover some additional cases.
-Tom
patric@xxxxxxxxxxx wrote:
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