|Re: [eclipselink-users] Order of persist operations|
|Well, the order that EclipseLink chooses is RANDOM :)|
It is a fairly simple example, only 1 entity with only 1 column.
I'd really expect that the INSERT statements are executed in same order as the persist() calls.
My real-life use case is importing data from an XML file into the database.
There are relations and FKs in my database and when exported and re-imported the order of the XML entries, persist() calls and INSERT statements is critical.
EclipseLink basically inserts each XML entry randomly. Currently the only workaround is to flush after each persist call. It could work for few hundred calls,
but not for few thousand.
JPA says nothing about the order of the database operations. When writing the spec they probably have assumed that it would be logical to execute the database operations in the
same order as the persist() or merge() calls.
This is not the case of mixed remove(), persist() and merge() calls, in our case we have only persist() calls and the case is very simple.
On Jan 17, 2013, at 13:19 , Wim Bervoets <wbervoets@xxxxxxxxx> wrote:
If you want to know the order in which the rows were inserted I use @OrderColumn (eg. in combinantion with INDEX(..) function in a JPQL for example).
I think that EclipseLink can choose the order in which it commits the entities to the database... (I haven't read the JPA spec so this is an assumption)
On Thu, Jan 17, 2013 at 12:09 PM, Deyan Tsvetanov <deyan@xxxxxxxxxxxx> wrote:
eclipselink-users mailing list