Graceful handling of broken interfaces and components in the ZODB.

Worst.package.name.ever… inentionally! :-) But seriously, read the warnings and heed them. If I have to tell you to read the warnings, you shouldn’t use this package.

We in Plone land have been long frustrated about how easily a poorly behaved add-on could break a Plone site. Simply installing the add-on and removing it can leave your site inaccessible, even the ZMI! Often times add-ons that provide only minimal additional object behavior can break the entire object when removed.

Now this isn’t actually the ZODB’s fault at all. The ZODB actually has quite robust handling of broken object and it works quite well. I’m afraid that fault here lies in zope.interface and zope.component. They’re simply both too central to almost all ZODB applications to fail to provide graceful handling of broken objects. So I’ve taken advantage of the sprints following the Plone Conference here in San Francisco to work on this.

The experimental.broken package provides patches for zope.interface and zope.component to make the services they provide more tolerant of broken objects in the ZODB and allows them to function as if the interfaces and components aren’t there when the add-on has been removed. Even better, if the add-on is restored, the full behavior of the interfaces and components is restored.

That said, this is all highly experimental so don’t use it. If you do use it, never use it in production and only use it on a copy of your ZODB. And if you do use it, definitely report your experience. If you do have a broken site I’d love to hear how it works for you. Just add experimental.broken to your instance eggs.

If this approach tests well and the core Zope developers think it’s the right approach I’ll be merging this into zope.interface and zope.component.

Updated on 06 November 2011

Imported from Plone on Mar 15, 2021. The date for this update is the last modified date in Plone.


comments powered by Disqus