UpdateGenerator forms update statement with "where" clause like this - iterate over all PKs and include them in "where" clause. Then iterate over all changed fields and include them in "where" clause with values set to old values from change summary. In case the PK itself is being changed, this results in something like below -
update tableX set idX=? where idX=? and idX=oldValueOfidX Later in ChangeOperation.execute(), when the changed fields in DObj are scanned referring to propertyNames,for idX, the new value is found and set for both idX params above with "?", this is because the first "where" clause idX is not marked as Collision param. This results in - update tableX set idX=newValueOfIdx where idX=newValueOfIdx and idX=oldValueOfidX This results in 0 rows update in DB and seen by DAS as OCC Exception. A simple fix will be - when changedFields includes a PK, avoid first inclusion in where clause in UpdateGenerator. For other cases (i.e. changedFields do not include PK), keep the logic as is. There can be cases where the PK needs to be modified in the tables - like data migration, system upgrades etc. So the above simple fix will be useful in supporting update of PK. Old discussion ref - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16310.html Minor change on the top of the above discussion is making update efficient by avoiding duplicate inclusion of same column in "where" clause. New test case - AliasTests.testModifyPK() Submitting patch soon for this. Regards, Amita On Dec 31, 2007 8:48 AM, <[EMAIL PROTECTED]> wrote: > Hi All , > > I write a sample to test the DAS work with the DB , when execute a > update operation on primary key , > > an update collision occurred , how to deal with it if I need update the > primary key value ? > > > Best Regards > > Leo > >