[ZODB-Dev] Pluggable transactions logic

[Chris Withers]

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

Almost, which is why I suggested moving a hook into the ZODB. As I see it, there
might be several Indexers *cough* cat out of bag *cough* ZCatalogs in a ZODB.
They'll each only be interested in certain types of object and maybe only
objects in certain locations, if you could register with some service such that
your indexing code was _only_ called when certain types of objects in certain
locations were added/modified/destroyed, would that solve some of the
reservations?

> 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.

I like this pattern :-) But... in more more general ZODB use cases would it
still work? eg: no acquisiton around a multiple references to the same object?
(this second one is important to me...)

Do be honest, if it weren't for persistence, surely implementing a __del__
method on your class would do what you're asking for?

BUT, this reminds me of something I don't like about this pattern. Objects have
to know that they want to play with indexing. At the very least, this would mean
a mix-in class (someone say CatalogAware ;-) which I don't like the idea of. A
common use case for me would be to have some third party class create objects
and me then decide I want objects of this class to be automatically indexed. How
would this pattern work here?

cheers,

Chris