Bug #557
Record.Save() should utilize a single transaction
Description
Currently, saving a Record and its foreign keys happens in separate methods. This means that a tree of items could be only partially saved, leading at the very least to wrong expectations, and at worst actual data corruption.
Save() should happen in a single transactions, and all of it should be successful or a failure.
Associated revisions
History
#1 Updated by Elmer de Looff about 13 years ago
- Status changed from In Progress to Closed
- % Done changed from 30 to 100
This has been fixed and verified as of r3221.
Record.Save() now opens a transaction and within this, performs the saving of all foreign-related records and itself. If any of these fail, the transaction will automatically roll back.
Also with this bugfix, are a number of small fixes to the Save process. Creating an sql-safe representation from the Record used to trigger a comprehensive deep-load of the record to be saved. This no longer occurs, since we iterate using the superclass instead.
Added single-transaction Save() as major feature. This resolves #557. A Save() where child elements are saved, will now be processed atomically. Also fixed a bug where creating the SQL-record for a Record object would trigger a full deep-load. VersionedRecord now has a Create method that is safe from race conditions (via single-transaction Save that acquires the next-in-line recordKey.