[PEAK] Pickling Trellis objects?

[Phillip J. Eby]

At 12:55 AM 8/12/2007 -0500, David Eyk wrote:
>I noticed Trellis in the Cheeseshop yesterday, and have been poking
>around with it.  Very cool stuff, and made even better by the
>uncommonly helpful tutorial.  Thanks!
>
>I would like to integrate Trellis into my current project, but I'm
>fairly committed to using ZODB as a back-end for object persistence.
>I looked into the trellis code a little, but I don't understand it
>well enough to write __(get&set)states__ so that trellis objects will
>pickle.
>
>My question:  is there or will there be any simple way to pickle
>Component and Cell objects?

I haven't given it any thought, actually.

What you would need to do is *not* use getstate/setstate, but rather 
__reduce__ on your components, so that you can initialize cell states 
as if the object had just been created via keyword arguments.  That's 
about the only way to sanely unpickle a Component.

And that's not going to work with ZODB, really.  I suppose, though, 
that you could write a setstate that creates a new component, then 
just sets self.__cells__ = other.__cells__...  except that's really 
not going to work, either, because the methods won't be bound to self.  :(

I'll have to give this some thought.  I guess it'll probably require 
a smart __setstate__ that's a quasi- at modifier the way the Component() 
constructor is.


>   Is it in near-future plans, possibly what
>the TrellisDB will be for?

TrellisDB won't use pickling to store Components; it'll just use 
cells that get their values from simpler data structures - it's those 
simpler (relational-like) data structures that will be stored in 
back-ends.  This basically means that you'll be able to redefine your 
front-end objects all you like without affecting the back-end 
data.  Likewise, you can redefine your back-end data while leaving 
the front-end objects alone.