[ZODB-Dev] List of modified objects

[Kapil Thangavelu]

On Mon, 2004-12-06 at 15:30 -0500, Tim Peters wrote:
> [Kapil Thangavelu]

> > for zodb3.3, it would be nice if an optional observable or introspectable
> > interface could be on connections, for this sort of functionality to be
> > duplicated.
> 
> ZODB 3.3 is history.  If people want something new in ZODB 3.4, it needs
> careful definition first.  "An optional observable or introspectable
> interface" is too vague.  If I have time (which is unlikely), I'd like to
> build something on Zope3's event system.  Objects can publish events, and
> objects can subscribe to events.  I'm sure someone would have a snit if I
> said that was another way to spell "observable", so I won't.  Luckily, the
> description at this level is also too vague to argue about <wink>.
>
> 
> The kind of monkey-patching you did for ZODB < 3.3 looks harder in 3.3, for
> several reasons (for starters, transactions in 3.3 don't deal with
> Connections, they deal with "resource managers", resource managers may or
> may not keep track of their own modified objects (Connections do; for those
> that don't, there are adapter layers that do it for them), and nothing is
> defined exposing resource manager internals).
> 

right this technique won't work for 3.3. 

i was thinking that an optional interface onto resource managers for
iterating over modified objects, and an api for transaction lifecycle
events, with a minimum of some events that get before resource manager
recieve transaction completion messages and start the tpc dance, so that
observers can perform work that might entail new objects being
registered with resource managers, and new resource managers
participating in the transaction. having the flexibility to register for
txn events globally (all transactions) and locally (to a single
instance) would be nice (the monkey patch stuff does this).


> If forensic.py is the only actual use case, then an API to iterate over the
> modified objects again looks sufficient, in conjunction with 3.3's
> beforeCompletion() hooks.  Nothing uses beforeCompletion() now.  I note that
> it doesn't distinguish between commit() and abort(); it probably should.
> 

regarding use cases.

the code was originally written for occams, a versioning and staging
project, which was doing transaction gymnastics to coalesce versioning
events/messages that were automatically generated within a transaction
scope and sent to the observer, to do work before the transaction
committed (and hence it still being safe to add additional objects and
data/resource mangers to the tranasation). if your curious...

http://svn.objectrealms.net/view/occams/versioning/trunk/observer.py?rev=171&view=auto

forensic.py was the cause for the code being separated, it sole purpose
was to discover hotspots in an application.

/me wanders off to take a look at beforeCompletion interface

cheers,

-kapil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.zope.org/pipermail/zodb-dev/attachments/20041206/274a0902/attachment.bin