SystemSpecifyer, was Re: [ZODB-Dev] How to predict George Bailey?

[Christian Reis]

On Sun, Nov 03, 2002 at 07:36:33PM +0100, Magnus Lycka wrote:
> I guess I could remember my application OID instead of
> keeping an object reference in the GUI code, but then I'd
> have to search and retrieve hundreds objects all the time.

Eeeevil. :-)

> >Is it because you are editing the same object as is displayed in
> >other parts of the interface?
> 
> Yes, at least partly. But even if I only have one object in
> one window, I might want to go on displaying and working with
> it across transactions and undos.

Yes, but you make be sure it wouldn't be uncreated in that window,
couldn't you?

Of course, that doesn't save you from uncreating an object that is being
held somewhere else just because it changed in the same transaction as
this one.

> As you see (if you managed to get through all this) names and type
> code can be changed in two places, relations between elements might
> change in all sorts of windows, and obviously we want these changes to
> be reflected in all relevant parts of the system.

I see where your problem is now. You can change and Undo things in
multiple places, and your transaction boundaries are not clearly
associated to dialog openings. This means that multiple things might
have changed since the last transaction when you actually Undo,
including an object uncreation. And if you do multiple Undos, eventually
you will end up uncreating an object in some part of the interface.

I guess this is related to how complex the editing flow is in your app
(and I don't envy your problems). In our app, we can more or less be
sure that a window is tied to a single transaction, so we can use
abort() and undo rather safely. However, if we *do* end up having two
windows running in the same transaction, we can definitely run into an
Undo problem.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL