Archetypes-based content-types are traditonally tied to the ZODB as backend storage. It has always been hard making the content available through a RDBMS - the only solution for a long time has been SQLStorage. However the implementation and the behavior was more than flaky. Lately projects like collective.tin (Laurence Rowe) and Contentmirroring by Kapil appeared on the scene.
A small hint when doing migrations
A common usecase when working with migration related issues in Zope world is:
- writing migration code
- testing the migration code until it work
Usually you test the migration code against a copy of some production ZODB storage. However migration code usually modifies your storage. Here comes demo storage into the game. Any ZODB storage can be wrapped through a demo storage proxy. All changes to the storage will be persistent in memory only and the wrapped storage remains untouched. By doing this you can test you migration code against the copy of the production over and over again without replacing it all the time with a fresh copy. The only thing you have to configure is to modify your ZODB storage configuration and insert <demostorage> around the configuration of your storage to be wrapped.
ProducePublishCloudEdition.pdf — PDF document, 151 kB (154,844 bytes)