[Erp5-report] r36367 rafael - /erp5/trunk/products/ERP5Type/Core/Folder.py

[nobody at svn.erp5.org]

Author: rafael
Date: Tue Jun 15 19:24:29 2010
New Revision: 36367

URL: http://svn.erp5.org?rev=36367&view=rev
Log:
Added some important warnnings from Seb. 

Modified:
    erp5/trunk/products/ERP5Type/Core/Folder.py

Modified: erp5/trunk/products/ERP5Type/Core/Folder.py
URL: http://svn.erp5.org/erp5/trunk/products/ERP5Type/Core/Folder.py?rev=36367&r1=36366&r2=36367&view=diff
==============================================================================
--- erp5/trunk/products/ERP5Type/Core/Folder.py [utf8] (original)
+++ erp5/trunk/products/ERP5Type/Core/Folder.py [utf8] Tue Jun 15 19:24:29 2010
@@ -1090,7 +1090,22 @@ class Folder(CopyContainer, CMFBTreeFold
 
       from_class and to_class can be classes (o.__class___) or strings like:
         'Products.ERP5Type.Document.Folder.Folder'
-     
+    
+    XXX Some comments by Seb:
+    - it is not designed to work for modules with thousands of objects,
+      so it totally unusable when you have millions of objects
+    - it is totally unsafe. There is even such code inside :
+        self.manage_delObjects(id of original object)
+        commit()
+        self._setObject(new object instance)
+      So it is possible to definitely loose data.
+    - There is no proof that upgrade is really working. With such a
+      dangerous operation, it would be much more safer to have a proof,
+      something like the "fix point" after doing a synchronization. Such
+      checking should even be done before doing commit (like it might
+      be possible to export objects in the xml format used for exports
+      before and after, and run a diff). 
+
     """
     #LOG("upgradeObjectClass: folder ", 0, self.id)
     test_list = []