Re: Plone 4.2->4.3.4 PicklingError saving Dexterity content with relationship

Gil

Apologies for the delay in responding... issue is now fixed - thanks for 
the hints and support:

1. KSS issue resolved by including 'plone.app.kss';
2. Schema incompatibility resolved by first updating my source and 
removed all references to plone.directives.form and replacing with 
supermodel's Schema
e.g. Interface signature changed from ILocation(form.Schema) to 
ILocation(model.Schema, IImageScaleTraversable)

3. Then reindexing all objects in the catalog.  I used the following 
script to accomplish this and ran it using ./bin/instance -O Plone run 
update_references.py
[ thanks also to: 
https://github.com/simplesconsultoria/s17.employee/blob/master/src/s17/employee/upgrades/to1001.py 
]

import transaction
import logging
from zc.relation.interfaces import ICatalog
from zope.component import getUtility
from z3c.relationfield.event import updateRelations
from z3c.relationfield.interfaces import IHasRelations
from Products.CMFCore.utils import getToolByName

logger = logging.getLogger()
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler(sys.stdout)
formatter = logging.Formatter("%(asctime)s - %(name)s - %(levelname)s - 
%(message)s")
handler.setFormatter(formatter)
logger.addHandler(handler)

''' Upgrade to version 1001
     reindex zc.relations catalog
'''
rcatalog = getUtility(ICatalog)
# Clear the relation catalog to fix issues with interfaces that don't 
exist anymore.
# This actually fixes the bug editing employees than reports a:
#   KeyError: <class 'plone.directives.form.schema.Schema'>

transaction.begin()
rcatalog.clear()

site = app.get('Plone')
catalog = getToolByName(site, 'portal_catalog')
brains = catalog.searchResults(object_provides=IHasRelations.__identifier__)

for brain in brains:
     obj = brain.getObject()
     logger.info(obj)
     updateRelations(obj, None)
transaction.commit()





On 27/01/2015 18:27, Gil Forcada wrote:
> Hi Simon,
>
> as the one that asked the question on stackoverflow, you can see that my
> own answer has the solution I took to fix it.
>
> So basically is about reindexing the brains that have that interface (as
> shown on stackoverflow) and then reindex all objects in the catalog to
> get rid of the interface also on the catalog.
>
> Cheers,
> Gil
>
> El dg 25 de 01 de 2015 a les 13:10 +0000, en/na Simon Richardson va
> escriure:
>> Dieter
>>
>> Thanks for the suggestions.  I decided to go down the monkey patching
>> route and have a different error message - which shows my experience as
>> a developer.  Do you have any suggestions on how to proceed?
>>
>> 2015-01-25 13:57:19 ERROR Zope.SiteErrorLog 1422194239.010.173685501916
>> http://192.168.146.129:8080/Plone/myswimming-club/++add++myswimmingclub.content.swimmer
>> Traceback (innermost last):
>>     Module ZPublisher.Publish, line 146, in publish
>>     Module Zope2.App.startup, line 301, in commit
>>     Module transaction._manager, line 89, in commit
>>     Module transaction._transaction, line 329, in commit
>>     Module transaction._transaction, line 443, in _commitResources
>>     Module ZODB.Connection, line 567, in commit
>>     Module ZODB.Connection, line 623, in _commit
>>     Module ZODB.Connection, line 658, in _store_objects
>>     Module ZODB.serialize, line 422, in serialize
>>     Module ZODB.serialize, line 431, in _dump
>> PicklingError: Can't pickle <SchemaClass plone.supermodel.model.Schema>:
>> it's not the same object as plone.supermodel.model.Schema
>>
>>
>> I added 2 files to my source to monkey patch the Schema.  The source is
>> below:
>>
>>
>>
>> =====================
>> overrides.zcml
>> =====================
>>
>> <configure
>>       xmlns="http://namespaces.zope.org/zope"
>>       xmlns:browser="http://namespaces.zope.org/browser"
>>       xmlns:zcml="http://namespaces.zope.org/zcml"
>>       xmlns:monkey="http://namespaces.plone.org/monkey">
>>
>>       <include package="collective.monkeypatcher" />
>>
>>       <configure
>>           package="myswimmingclub.content"
>>           zcml:condition="not-installed plone.directives.form.schema.Schema">
>>
>>           <include package="collective.monkeypatcher" />
>>
>>           <monkey:patch
>>               module="plone.directives.form.schema"
>>               original="Schema"
>>               replacement=".overrides.Schema"
>>               ignoreOriginal="True"
>>               />
>>
>>       </configure>
>>
>> </configure>
>>
>> =====================
>> overrides.py
>> =====================
>>
>> from zope.interface import Interface
>> from plone.supermodel.model import SchemaClass
>>
>> Schema = SchemaClass("Schema", (Interface,),
>> __module__='plone.supermodel.model'           )
>>
>>
>>
>> On 24/01/2015 07:07, dieter wrote:
>>> Simon Richardson <[email protected]> writes:
>>>
>>>> I've been doing some digging and I think the problem may be down to
>>>> the version of plone.directives.form in my existing 4.2 Plone site -
>>>> see:
>>>>
>>>> http://stackoverflow.com/questions/20290361/how-to-clean-up-old-interfaces-on-zc-relation-catalog
>>>>
>>>> If anyone can offer any further insight or suggest a correct path to
>>>> resolve my problem then I'd welcome your input.
>>> David Glick is (partially) wrong in his answer above:
>>> interfaces were explicitely designed to be picklable.
>>>
>>> Thus, the reason for your problem might be the move of the "Schema" class
>>> from "plone.form.schema" to "plone.supermodel.model" (suggested by
>>> "David Glick" in his answer above).
>>>
>>>
>>> Moving persistent classes across packages/modules unfortunately does not play
>>> well with the ZODB. It should be avoided.
>>>
>>> If it cannot be avoided, then some workarounds can be considered:
>>>
>>>      *  import the moved class at its old location from its new location
>>>         (such that the class can be found both via the old as well
>>>         via the new location)
>>>
>>>      *  if the old location has disappeared altogether, establishing
>>>         a module alias ("sys.module[<missing>] = sys.module[<existing>]")
>>>         may work around this
>>>
>>>      *  use a "monkey patch" (modification at startup time)
>>>         to make the moved class available at its old location
>>>
>>> All these things are workarounds only -- they do not clean up
>>> the objects states in the ZODB. However, they might be a
>>> necessary prerequesite to a real cleanup (they ensure, that
>>> the affected objects become loadable): once an affected object ("o")
>>> is loaded from the ZODB and written again ("o._p_changed = True";
>>> followed eventually be a "commit"), the object references the class
>>> at its new location.
>>>
>>> Unfortunately, it is difficult to locate all affected objects:
>>> there is no general approach. I cannot help you with finding
>>> the affected objects in your specific case.
>>>
>>>


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk