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

Gil Forcada <[email protected]> Tue, 27 Jan 2015 19:27:55 +0100
Newsgroups	gmane.comp.web.zope.plone.user
Message-ID	<[email protected]>
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.
> >
> >
-- 
Gil Forcada

[ca] guifi.net - una xarxa lliure que no para de créixer
[en] guifi.net - a non-stopping free network
bloc: http://gil.badall.net
planet: http://planet.guifi.net

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

_______________________________________________
Plone-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plone-users
signature.asc (application/pgp-signature, 819 B)