Re: experimental.broken - Graceful handling of broken interfaces and components in the ZODB

On 7 Nov 2011, at 08:17, Ross Patterson <[email protected]> wrote:

> Please take a look at experimental.broken:
> 

Most optimistic package name ever :-)

Awesome work, Ross!

Martin

> https://github.com/rpatterson/experimental.broken
> http://pypi.python.org/pypi/experimental.broken
> 
> The handling of broken objects by the ZODB can make an application with
> add-ons that use zope.interface far too fragile.  If marker interfaces
> from an add-on are used on objects in the ZODB, removing that add-on can
> make any zope.interface operation on that object fail.  Even worse, if
> an add-on registers any components in a registry in the ZODB, that
> entire registry will become unusable for any ZCA operations which pretty
> much breaks everything, including admin interfaces.
> 
> Since the interfaces and the ZCA are often core parts of an application
> using the ZODB, it may be appropriate to add special handling for broken
> objects to those services.  The experimental.broken patches are my
> attempt to prototype such special handling.
> 
> For objects in the ZODB which directly provide a marker interface,
> these patches allow that object to behave as without the application
> of the marker interface if the interface is no longer available.  If
> the interface is made available again, the full behavior of that
> interface is restored.  Similarly, if a component whose class,
> provided interface, or required interfaces are missing, these patches
> allow the registry to perform lookups it would have been able to do
> without the broken component registration.  If the component
> class, provided interface, and required interfaces are restored,
> then the component registration is fully restored.
> 
> If an object or registry in the ZODB is committed to the ZODB with
> broken interfaces or components, the commit will succeed and it is still
> possible to fully restore previous behavior if the missing classes and
> interfaces are restored.  Unfortunately, because interfaces are pickled
> as globals, there's no good way to have the same pickle written on
> commit for the interface as was in the original pickle, but it should
> behave exactly the same.
> 
> The intention of this package is to see if the implementation of broken
> object handling is correct and robust enough to merge into
> zope.interface and zope.component themselves.  Is this the right
> approach?  If not why and what would be better?  How might this approach
> be improved?
> 
> Ross
> 
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Plone-developers mailing list
> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/plone-developers

------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1