Peter, I saw this also, and thought this was a bug (in 0.9.3.9). I fixed it locally by changing the order that the TransactionContext.prepare() processed the updates, moving deletes from being the last thing done to being the first.
hth - mm -----Original Message----- From: Peter Jeszenszky [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 2:45 PM To: [EMAIL PROTECTED] Subject: [castor-dev] 1:N update problem Hello, I have a master object with N dependent objects. In the database table of the dependent objects there is a UNIQUE constraint: CREATE TABLE dependent( id SERIAL PRIMARY KEY, master_id INTEGER NOT NULL REFERENCES master ON DELETE CASCADE, value VARCHAR(40), UNIQUE(master_id, value) ); Lets load a master object Database db; Master m = (Master) db.load(Master.class, new Integer(1)); then remove all of its dependents with master.getDependents().removeAllElements(); then add a new dependent object with a value that just has been removed: master.addDependent(" A VALUE THAT JUST HAS BEEN REMOVED "); The method invocation db.update(master); results an exception java.sql.SQLException: ERROR: Cannot insert a duplicate key since Castor handles the dependent objects in the following order: 1. First creates the dependent objects that are assigned to the master. (The UNIQUE constraint is violated!) 2, Then removes the dependent objects that have been disassociated from the master. I thinks so these operations should be performed in the opposite order. Is it a bug? Any idea to handle the situation? Yours sincerely, Peter ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
