[Zope3-dev] Persistent declarations, dead interfaces and a TypeError

Jim Fulton jim at zope.com
Fri Feb 23 08:23:25 EST 2007


On Feb 22, 2007, at 8:24 PM, Sidnei da Silva wrote:

> Hi there,
>
> I'm consistently having issues with 'directlyProvides' and interfaces
> that are moved or removed. The symptom is that when the persisted
> declaration is unghostified a TypeError happens.
>
> This is specially bad since in this case the 'directlyProvides' is
> being used on a PAS plugin, and the TypeError prevents the user from
> even going into the ZMI to delete the object!
>
> Here's a snippet of the traceback. In the list of interfaces below,
> the ones prefixed by Products.Five.bbb do not exist anymore:
>
>  Module ZODB.Connection, line 732, in setstate
>  Module ZODB.Connection, line 786, in _setstate
>  Module ZODB.serialize, line 604, in setGhostState
>  Module ZODB.serialize, line 597, in getState
>  Module zope.interface.declarations, line 766, in Provides
>  Module zope.interface.declarations, line 669, in __init__
>  Module zope.interface.declarations, line 47, in __init__
>  Module zope.interface.declarations, line 1363, in _normalizeargs
>  Module zope.interface.declarations, line 1362, in _normalizeargs
> TypeError: ('iteration over non-sequence', <function Provides at
> 0x009A6F70>, (<class
> 'Products.PluggableAuthService.plugins.ScriptablePlugin.ScriptablePlug 
> in'>,
> <InterfaceClass persistent.interfaces.IPersistent>, <class
> 'Products.Five.bbb.OFS_interfaces.IFolder'>, <class
> 'Products.Five.bbb.OFS_interfaces.IObjectManager'>, <InterfaceClass
> zope.app.container.interfaces.IContainer>, <class
> 'Products.Five.bbb.OFS_interfaces.ICopyContainer'>, <class
> 'Products.Five.bbb.App_interfaces.INavigation'>, <class
> 'Products.Five.bbb.Acquisition_interfaces.IAcquirer'>, <class
> 'Products.Five.bbb.webdav_interfaces.IDAVCollection'>, <class
> 'Products.Five.bbb.webdav_interfaces.IDAVResource'>, <class
> 'Products.Five.bbb.webdav_interfaces.IWriteLock'>, <class
> 'Products.Five.bbb.OFS_interfaces.ITraversable'>, <class
> 'Products.Five.bbb.OFS_interfaces.IPropertyManager'>, <class
> 'Products.Five.bbb.AccessControl_interfaces.IRoleManager'>, <class
> 'Products.Five.bbb.AccessControl_interfaces.IPermissionMappingSupport' 
> >,
> <class 'Products.Five.bbb.OFS_interfaces.IItem'>, <class
> 'Products.Five.bbb.OFS_interfaces.ICopySource'>, <class
> 'Products.Five.bbb.AccessControl_interfaces.IOwned'>, <class
> 'Products.Five.bbb.App_interfaces.IUndoSupport'>, <class
> 'Products.Five.bbb.OFS_interfaces.IFindSupport'>, <class
> 'Products.Five.bbb.OFS_interfaces.ISimpleItem'>, <InterfaceClass
> Products.PluggableAuthService.interfaces.plugins.IAuthenticationPlugin 
> >,
> <InterfaceClass
> Products.PluggableAuthService.interfaces.plugins.IExtractionPlugin>))
>
> I believe that _normalizeargs in zope.interface.declarations should be
> changed to cope with this, by ignoring those 'broken' references.
>
> Thoughts?

I think this should be handled in the declaration serialization code.
We should arrange that when a declaration is unpickled we:

- catch interfaces that can't be loaded,

- issue a warning

- replace the wayward interface with some kind of placeholder.

This may require checking for broken objects rather than catching  
errors.

This is largely hand waving, but I think the overall approach is  
sound. :)

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org





More information about the Zope3-dev mailing list