cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Mayweg <>
Subject Antwort: Re: possible bug with inherited cayenne objects and mandatory fields
Date Thu, 17 Feb 2011 08:29:44 GMT
Hi Aristedes,
in our Cayenne application, we have the use case where a row with a unique 
value ist first deleted and new row with different values in the other 
columns is created.
For that problem only putting the delete in front of the insert would 

Aristedes Maniatis <> 
17.02.2011 09:11
Bitte antworten an


Re: possible bug with inherited cayenne objects and mandatory fields

On 15/02/11 2:04 PM, Marcin Skladaniec wrote:
> java.sql.SQLIntegrityConstraintViolationException: The statement was 
aborted because it would have caused a duplicate key value in a unique or 
primary key constraint or unique index identified by 'TAGRELATION_UNIQUE' 
defined on 'TAGRELATION'.

Can I summarise, since I think you've highlighted a problem which is 
completely different to your email subject.

1. Table A has primary key which is user defined (in this case, it is the 
join between two other tables, so the PK is the compound of the two 
foreign keys)

2. Create record in table A. Commit.

3. Delete that record in table A.

4. Create another record in table A with the same PK as the one just 
deleted (since it joins the same other two tables).

5. Commit -> ERRROR

The create in step 4 is being committed to the db before the delete in 
step 3, failing the key constraint.

Use case
You may wonder why on earth this is happening. Well, in a rich client 
application a user might tick a checkbox to link two records and then 
untick it and tick it again while they make up their mind. All those 
changes result in changes to the context.


A. Dedupe the overlapping create/delete records in the context before 
B. Order the SQL better.

Any thoughts about how Cayenne could deal with this better? What do other 
ORMs do in this scenario?


Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

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