Re: Re: Objects with varying classes

Conceivably, this is a use case we could support by swapping classes of
ghost objects when we detect a class mismatch.

I'm not sure this is a use case we want to support though.  Feels like a
foot gun. (I'd be open to hearing about problems it solves.)

(Early on, I thought writing custom __getstate__/__setstate__ methods would
be cool, but I literally never do this any more, at least for
application-level classes.)

Jim

On Wed, Sep 26, 2018 at 8:42 AM, Jason Madden <[email protected]>
wrote:

> In general, the only way to change the `__class__` of a Persistent object
> is to update *all* references to it. For references in a BTree, that may
> mean updating the tree itself (if small) or the individual bucket. There's
> further discussion of this here: https://github.com/
> zopefoundation/BTrees/issues/72
>
> Because finding and changing all references is usually difficult (even one
> missed reference can break everything), this is not usually recommended for
> applications (migration tools can be written to do this by crawling through
> the entire database object-by-object, but that's rarely practical for an
> application). This is one way that interfaces can be more useful than
> classes: dynamically changing the interfaces an object provides with
> `interface.alsoProvides(object, IFoo)` or `interface.noLongerProvides(object,
> IFoo)` propagates automatically to all references to the object.
>
> HTH,
> Jason
>
> --
> You received this message because you are subscribed to the Google Groups
> "zodb" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Jim Fulton
http://jimfulton.info

-- 
You received this message because you are subscribed to the Google Groups "zodb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.