openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reece Garrett" <>
Subject SQL ordering and unique constraints
Date Tue, 22 May 2007 20:26:38 GMT

I previously submitted a patch which reorders the SQL statmements generated by OpenJPA to
avoid violating foreign key constraints. In addition to making improvements on that patch
( more efficient and I caught a few edge cases that I did not initially think of ) I am trying
to deal with unique key constraint violations. 

This quote from the docs illustrates what I am talking about: "...suppose there is a unique
constraint on the columns of field F. In the same transaction, you remove an object A and
persist a new object B, both with the same F value. The JPA runtime must ensure that the SQL
deleting A is sent to the database before the SQL inserting B to avoid a unique constraint
violation." Unfortunately, OpenJPA does not ensure the SQL is executed in such a manner that
the unique key is not violated. The insert of object B is depends on the removal of object
A but in order to calculated that dependency I need to know what the initial values of the
columns of field F were at the beginning of the transaction. 

I am aware that some initial values are stored in the statemanagers to facilitate rollback,
however, not all fields are saved (in the case of deletes none are saved) and I have no way
to efficiently map from columns (the columns involved in a unique constraint) back to the
saved fields. Also, deferred constraints are not an option due to the DBMS I am forced to

In a nutshell, for updates and deletes I need to have access to the initial values (at the
beginning of the transaction) of any columns involved in a unique constraint in order to calculated
SQL statement dependencies. Before I go any further I would like suggestions as to how to

  • Unnamed multipart/alternative (inline, None, 0 bytes)
    • Unnamed multipart/related (inline, None, 0 bytes)
View raw message