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

Simon Richardson <[email protected]> writes:

> 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 have occationally seen errors like this - and I assume they
happen when a pickle consistency check fails. More precisely,
I assume a check in "pickle" of the form:

  class_ = obj.__class__
  if class_ is not getattr(import(class_.__module__), fromlist=[class_.__name__]), class_.__name__):
    raise PicklingError(...)


What strikes me in your message is the
"<SchemaClass plone.supermodel.model.schema>".
I read this as "the class of the unpicklable object is
not "plone.supermodel.model.Schema" itself but something different
(a "SchemaClass") derived from "plone.supermodel.model.schema" --
maybe something generated from this class and additional information
(like a Dexterity schema definition).


Maybe, I now understand David's remark (on "stackoverflow")
that interface persistency is not supported. I read this
as "zope interface" (and those interfaces are designed to be
persistable) but he might have used the term for "Dexterity schema
interface". If the classes representing "Dexterity" schemas are
dynamically generated, then they can not (easily) be persisted
and resulting problems could look like your current problem.

If this would indeed be the case, then it would be very difficult
to work around your problem. To find out, you likely
should consult David to learn what he meant with "interface persistency
is not supported".


------------------------------------------------------------------------------
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/