Changes between Version 9 and Version 10 of WikiRename

Timestamp:

Mar 19, 2010, 11:20:04 AM (14 years ago)

Author:

Christian Boos

Comment:

some additional suggestions for improving DB/FS joint transactions

WikiRename

@@ -65 +65 @@
  * More robust error handling: what happens if a reparent fails mid-way (e.g. permission issue for one attachment)? The whole transaction is rolled back, but some attachment ''files'' could have been moved already. Should we try to move them back? Should we warn the user about what already got moved? After fixing the permission issue, a new rename should work, which might not be the case if the attachment table and the files are not in sync.
   - We have the same issue when deleting pages. Actually, any time a filesystem change must be atomic with a DB change. I thought about adding some kind of "post-commit task list" where e.g. the attachment reparenting method registers a callable with the transaction to be executed after a successful commit. So the transaction would complete, and only then would all the items in the list be called to execute FS operations.
+   * but what if that post-commit action fails, then? We'd have again a inconsistent state... Maybe we need a pre-commit ''and'' a post-commit callback, so a "safer" reparent could work that way:
+     1. pre-commit: copy all the attachments to the new location in the FS
+     2. only if 1. succeeds, perform the DB operation
+     3. always perform the post-commit, passing the status of the previous steps as arguments. If 1. has succeeded, we can try to remove the files at their old location. If this last step fails, bad luck but at least the DB and FS are consistent, the FS can eventually be cleaned manually afterwards.
+   In fact, rather than just the success status, we can pass some "state" object from one step to the next.
 
 ----