[Zope-dev] Two glaring omissions
Toby Dickenson
tdickenson@geminidataloggers.com
Mon, 20 Nov 2000 10:07:31 +0000
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?
Toby Dickenson
tdickenson@geminidataloggers.com