Hey Markus, 1) Yes, OpenJPA pulls all the original data for the rows and uses it to fully populate the PersistenceCapable objects (actual java objects being persisted) held by every state manager. The problem is that only some of that data gets stored on generated rows to use for rollback. If ALL the original data was stored just like OpenJPA stores the values to be set in an update (stored in an array called _vals on RowImpl) then unique key constraints could be done properly. It is important to store it this way because sometimes (Enumerations) the values on the PersistenceCapable object is not the same what's actually stored in the database. And the array which stores the original values should be indexed such that the index of the column in the table corresponds to the index of the field on the statemanager which in turn corresponds to the index of the original value (just like is done for _vals). This lets you make an accessor method that takes a column and will give back the original value for that column. The method would work just like RowImpl.getSet(Column col).
2) Not entirely sure on that one. I haven't went through the code with a fine-tooth comb but I can say that the test cases I made for foreign key constraints pass. I'm sure Patrick can help you out more with that. 3) Yes, see RowImpl.whereForeignKey(ForeignKey fk, OpenJPAStateManager sm) in the API. >>> [EMAIL PROTECTED] 6/7/2007 4:52:34 PM >>> Hi all, could somebody please answer these questions? 1) Does OpenJPA create before images for rollback? Or is the transaction rollback functionality just implemented in the JDO closed source? As Reece mentions, we'd need before image values on relationships for dependency calculation in case of unique keys. 2) Why are updates ignored (not re-ordered) in ConstraintUpdateManager, if there are *no* delete-then-insert-same-pk? 3) Can foreign keys be used in the WHERE clause for updates/deletes? Thanks so much! -- markus.
