[ZODB-Dev] How to predict George Bailey?

Magnus Lycka magnus@thinkware.se
Sat, 02 Nov 2002 02:13:48 +0100


At 17:15 2002-11-01 +0000, a confused Toby Dickenson wrote:
>Why is an undo transaction that creates a George Bailey any different from 
>any
>other transaction that changes an object? You still need to resync the window
>- possibly by changing the data, possibly by closing the window.

Considering the behaviour that I got on attribute access from
G.B'd objects, I'm a bit suspicious that I'll get exceptions
in unexpected places from them. (As far as I see, only G.B'd
objects will cause closed windows.)

But maybe doing an attribute access in a try block and close
the window in the except clause (except KeyError if this is fixed)
would be enough?

Since I won't get my normal triggers at undo (see below) I suppose
I'll cycle through the open windows and just refresh them. I'm just
suspicious about the windows for G.B'd objects.

>what triggers the event to which the observers subscribe? why can it handle
>some types of changes but not others?

__setattr__ in persistent objects, and methods such as remove and
__delattr__ etc in a subclass of PersistentList.

In the case of an undo, there is as far as I understand no method
in my python code that will detect a change. The objects just jump
from one state to another, all in a sudden. Surely __setattr__ won't
be called when I back to a previous version?

Perhaps it is this simple:

for w in all windows:
     try:
         w.refresh() # or whatever...
     except KeyError:
         w.Destroy()


-- 
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/  mailto:magnus@thinkware.se