[Persistence-sig] A simple Observation API

[Phillip J. Eby]

At 08:23 PM 7/29/02 -0400, Jeremy Hylton wrote:
> >>>>> "PJE" == Phillip J Eby <pje@telecommunity.com> writes:
>
>I remain convinced that the current mechanism ought to work.  Perhaps
>I just needed to be convinced otherwise, but I don't think these cases
>are worked out in enough detail to be convincing.

[shrug].  As I said, I was attempting to propose something that fit things 
brought up by others, and supply a generally-useful Observation framework, 
usable for things besides the context of persistence and 
transactions.  (Per Jim's suggestion that such an Observation framework 
would have greater motivation for a user to take advantage of it.)

For me, in the persistence/transaction context, the post-change flag is 
sufficient.


>I also think the semantics of the proposed alternative makes it harder
>on the users, presumably in order to make the infrastructure's job
>easier.  I'm thinking about a complex data structure implemented using
>many helper methods.  If the data structure is modified inside a
>helper message, it can't mark the object changed; it needs to wait for
>the top-level operation to finish.  As a result, the data structure
>would need to keep a separate flag to indicate whether it should be
>marked as changed later.  Then the methods that are "top-level" needed
>to be edited to check that flag and set _p_changed.  It's worse,
>though, because you might want to implement one "top-level" operation
>by calling another top-level operation.  That would require the
>introduction of extra wrappers around the public versions of methods
>that just do bookkeeping, so that the internal routines could call
>other internal routines.

Well, the example implementation I wrote took care of all of that, quite 
elegantly I thought.  But for my purposes, it's sufficient as long as 
_p_changed is set after the last modification that occurs.  It's okay if 
it's also set after previous modifications.  It just must be set after the 
last modification, regardless of how many other times it's set.

This requirement on my part has strictly to do with data managers that 
write to other data managers, in the context of the transaction API I proposed.