ERP5Type: compatibility for document classes
TODO: update message. old message below (scope and implementation changed since we cover original Products.*.Document and don't do newTempX ) --- make Products.ERP5Type.Document a dynamic module Historically all document classes from Products/*/Document/*.py and from $INSTANCE_HOME/Document/*.py were dynamically loaded in Products.ERP5Type.Document namespace and objects in ZODB were instances of Products.ERP5Type.Document.*.* classes. This allowed moving the python code from one product to another without having to wory about persistent references in ZODB. This was done in Products.ERP5Type.Utils.importLocalDocument which was used for Products/*/Document/*py and $INSTANCE_HOME/Document/*.py but that was never the case for document components - they are loaded on demand. When "portal types as classes" have been introduced, we used a new indirect erp5.portal_type namespace, for similar reasons as the Products.ERP5Type.Document namespace. The approach to migrate existing documents was to hook the loading from ZODB ( Base.__setstate__ , monkey patched from Products/ERP5Type/dynamic/persistent_migration.py ) to replace the class from the old Products.ERP5Type.Document.* by its corresponding erp5.portal_type.* class. This was working fine to migrate documents whose classes were defined in Products/*/Document/*.py, but now that these classes have been moved to document components, this does not work anymore, because unlike when loading a document class from Products/*/Document/X.py we don't create the corresponding Products.ERP5Type.Document.X module when loading from X component. As a result, existing documents of class Products.ERP5Type.Document.X.X which did not get a chance to be migrated before X was moved to component were now broken. In the observed case, there was several Address, Telephone or Email created ~10 years ago. These changes address this issue by making Products.ERP5Type.Document a dynamic module, ie. changing the previous beaviour of copying all document classes to Products.ERP5Type.Document by introducing a module that will dynamically lookup the document classes on demand, first from erp5.component.document modules, then falling back to the legacy document classes registry (populated at startup from Products/*/Document/*.py and $INSTANCE_HOME/Document/*.py) A side effect of this is that newTempX constructors are now created from document components as well (but they are still deprecated because their behavior is really strange: when you call newTempX - X is the name of a document class, which has a portal_type attribute and newTempX create an instance of the portal type defined on that class, but the portal type might be referencing anothing class)
Showing
Please register or sign in to comment