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

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.
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Plone-Users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/plone-users


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet