my.packages is a custom archetypes package in the src directory. Thousands of items in the Plone instance are added with its types. I want to rename the package as my.package. By simply uninstalling my.packages and installing my.package, I find http://localhost:8080/mysite/myfolder/my-item showing <persistent broken my.packages.content.mytype.MyType instance '\x00\x00\x00\x00\x00Un^'>
. Should I have to do migration? Or is there a simple way to fix this issue?
相关问题
- Plone- How can I create a control panel for a reco
- How light weighted Dexterity-base contenttype can
- zc.buildout 2.0.0 release somehow ends up breaking
- How do you scale an animated GIF image in PIL and
- How do I add keywords to SearchableText for a Dext
相关文章
- TinyMCE Toolbar Missing After Plone 4.3 Upgrade
- Invalidate/prevent memoize with plone.memoize.ram
- Extending table columns in collection view in Plon
- What's the modern way to solve Plone deadlock
- Unable to use Diazo (plone.app.theming) on Centos
- How to do proper memory management with ZODB?
- How can I remove portlets in edit mode with Plone
- Is there an easy way in Plone to get email notific
You can create an alias for backward compatibility, by fudzing with
sys.modules
. Do this in your package__init__.py
:This way the persistence machinery can find your classes still.
What happens is that when your Archetypes instances are persisted in the ZODB, the persistence machinery stores a module path for the class (a dotted python path such as
my.packages.types.foobar.FooBar
) in the stored data. When restoring an object from the ZODB, that same path is then used to re-create your instances. When you rename your package, all these references are broken.With the above trick, the nice thing is that if your object were changed and written to the ZODB again in a transaction, the new module path will be stored. You could thus conceivable cause a write to all your Archetypes instances from this package to make the migration permanent so you can remove the above work-around again.