[Persistence-sig] A simple Observation API

[Phillip J. Eby]

At 05:56 PM 7/29/02 -0400, Guido van Rossum wrote:
>
>Hacking bytecode is inexcusable mixing of abstraction levels.

Huh?


>Isn't there a way to do this in a less obtrusive way, e.g. by
>buffering?  I don't know much of this application area, but the
>mechanism you are proposing looks very heavy-handed.  I would expect
>that in a realistic system, most methods would grow wrappers.  

Yep.  The problem with buffering is, if you're trying to allow for cascaded
storage, e.g. persisting to an XML document which is persisted in a
database...  You then end up having to have some kind of explicit ordering
that occurs between transaction participants.

Unfortunately, this application area in general is one where the total
amount of complexity can only be moved from one place to another, and not
actually reduced by much, at least if you're trying to maintain generality.
 :(  I was trying to keep a more or less even balance of complexity between
the persistent objects, the data managers, and the transaction object.


>And
>this *still* doesn't prevent bugs like updating a list attribute by
>calling its append() method without somehow flagging this operation.

Right.  If we could catch *that*, then there wouldn't be any need for a
special API in the first place!  :)

Of course, it could be done by having the setattr trap assignments of
mutables to attributes in the first place, and having the observer
subscribe to notifications from the mutable, with an annotation that it's
actually a modification to the "owner".  But this leads to a new set of
questions like "what's mutable?", and what kind of performance degradation
ensues if your normal practice is to keep re-assigning new values to a an
attribute of type "list".  :)

Oh, and let's not forget the overhead of un-tracking observer subscriptions
when the attribute is overwritten or deleted...  Ugh.

It seems that the only really *simple* way to address this issue "once and
for all" would be to disallow assignment of non-persistent objects to the
attributes of persistent objects, except for a small set of known immutable
types, such as numbers, strings, and tuples.  This could be trivially
trapped with an isinstance() check in setattr against say,
(int,str,unicode,float,complex,tuple,Persistent).  It would then be
impossible to make this kind of mistake...  unless of course you use a
single-element tuple containing a mutable...  

Argh!!!!



>Maybe it's just too early to start proposing code?  

I was actually trying to propose an API, not an implementation.  I
originally started trying to write text to explain the API, as I did with
my Transaction API proposal, but found it more difficult in this instance
than writing code. 

The ideas being proposed in the API were really just the event mechanism,
the getattr hook, metadata declaration, and event compression.


>Or has the discussion already moved to IRC?  

Eh?


>I'm curious about why the message flow just stopped.

I really did think it was OSCON.  A lot of the other posters (e.g. you,
Jim, and Jeremy) were gone this last week, yes?