Hello, Pinaki.
> Nope. Unique constraints can be placed by annotations/xml descriptors. But
> the topological sorting algorithm that imposes an order on sql
statements to
> satisfy both database constraints and object-level operations do not
> consider unique constraints.
You are right, but i think that OperationOrderUpdateManager satisfy most
of possible scenarios to not violate particular unique constraint.
Scenario 1
update old (1-> x)
insert new (1)
Scenario 2
delete old (1)
insert new (1)
Scenario 3
update old (1 -> x)
update old (y -> 1)
In case i understand the logic of
OperationOrderUpdateManager.flush(RowManager rowMgr,
PreparedStatementManager psMgr, Collection exceps)
method correctly, it executes :
1. delete statements
2. updated rows with changed primary or foreign key
3. rest of operations which are in the order of application logic.
The only possible scenario to violate unique constraint is Scenario 3,
when second row changes its foreign key and its update be executed first.
BTW: Why there are so complex implementations of UpdateManager rather
single, simple ApplicationOrderUpdateManager ?
Best regards
Georgi
Pinaki Poddar wrote:
> Hi,
>> That's great news; I did not think unique constraints had been fixed.
>
> Nope. Unique constraints can be placed by annotations/xml descriptors. But
> the topological sorting algorithm that imposes an order on sql statements to
> satisfy both database constraints and object-level operations do not
> consider unique constraints.
>
> So if a transaction removes x1 and inserts x2 while x1 and x2 has the same
> value for a unique non-primary column then OpenJPA *does not* ensure that
> DELETE x1 will be issued before INSERT x2.
>
