[ZODB-Dev] Pluggable transactions logic

[Steve Alexander]

John D.Heintz wrote:

> 
> If I remember the discussion well enough, the problem was related to using 
> Transaction mechanisms to automagically unindex objects.  This particular use 
> case is something that _could_ be moved into the core functionality of ZODB.  
> 
> There are other types of functionality that could rely on when objects are 
> removed from the DB that couldn't/shouldn't be coded directly into ZODB 
> though.  


I think supporting indexing any object at the ZODB level by putting this 
into the persistence/transaction machinery is overkill.

For a given application, it is only certain kinds of object that I'm 
interested in indexing. The way Zope+ZPatterns handles this is by having 
two patterns of interesting object:

1: objects that derive from Item and are stored in ObjectManagers

2: objects that are mounted in a Rack (which, for the ZODB, is basically 
a BTree)

In the first case, objects know they have been deleted because their 
ObjectManager tells them so. There are some complications if you want to 
support renaming and moving objects, but it all works out when you look 
at things at the end of a transaction.

In the second case, objects mounted in a rack are responsible for 
deleting themselves.

In both cases, the object itself knows when it has been deleted, and 
thus can be responsible for unindexing itself.


I'd quite like to get rid of the first case, where an object relies on 
its parent to tell it that it has been deleted, and instead make the 
convention that you ask an object to remove itself from its parent.

This would work well with acquisition, where an object generally knows 
what its parent is.

This wouldn't work well with databases where an object can be contained 
in more than one place (that is, hard links).


My apologies to ZODB folk for talking so Zope-centrically :-)

--
Steve Alexander
Software Engineer
Cat-Box limited