Changes between Version 8 and Version 9 of WikiRename

Timestamp:

Mar 19, 2010, 9:14:00 AM (14 years ago)

Author:

Remy Blank

Comment:

Added comment about FS / DB synchroniztaion.

WikiRename

@@ -64 +64 @@
 
  * 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.
 
 ----