[Zope-dev] Two glaring omissions

[Shane Hathaway]

Toby Dickenson wrote:
> 
> On Thu, 16 Nov 2000 19:51:24 -0500, Tres Seaver <tseaver@digicool.com>
> wrote:
> 
> >Toby Dickenson <mbel44@dial.pipex.net> wrote:
> >
> >> On Tue, 14 Nov 2000 15:39:59 -0500, Shane Hathaway
> >> <shane@digicool.com> wrote:
> >>
> >> >> 2. The ability to rename properties after instances of the classes have
> >> >>    been created (and have the data in those fields preserved)
> >> >
> >> >This is also more difficult than it sounds.  You'd have to either scan
> >> >through the entire ZODB and modify class instances or associate
> >> >properties with a magical, unchanging ID.  The latter solution is dead
> >> >wrong, but the first is actually kind of interesting.  If there were a
> >> >separate index for each object type in the ZODB, it would be possible.
> >> >In fact, when ZODB is running from a relational database, there is
> >> >indeed a way to do that.  Hmmm...
> >>
> >> Or if your ZClass has a python base class, then a __setstate__ method
> >> could be added to do the same thing incrementally. Like all changes to
> >> a Python base class, this requires restarting the server.
> >
> >Correct in theory, but broken in practice:  if you make your ZClass
> >persistent (i.e., you leave checked the "Include standard Zope
> >persistent object base classes?" checkbox on the "Add ZClass form),
> >then Persistent will be the first base class in the list, and *your*
> >'__setstate__' will never be called!
> 
> Some more theory thats not backed up by any practical experience in
> this area: Would it be sufficent to create a base class that derives
> from Persistent and then uncheck the box? or does that checkbox get
> involved in some other magic?

Here's an idea... what we might look at is adding another method call to
ZODB.Connection.setstate().  In fact, we could cause it to call the new
method on behalf of every base class.  It would work well, I think, but
I still don't know how much merit this idea has.

Shane