[ZODB-Dev] Pluggable transactions logic

[Christian Robottom Reis]

On Fri, 31 Aug 2001, Chris Withers wrote:

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

And I don't know if it's such a good idea.

I've been pondering about the same thing too. I believe the ZODB is an
excellent choice at times _because_ you can unindex an object without
killing it. An object can still exist in the database without being
accesible from it's primary index, which means the legacy data doesn't
break.

Case in point: a product database, with sales containing references to
products. If a product is unindexed, no problems occur; no dangling
references from sales, and data integrity is kept in a simple fashion.

This might be something you're not considering, but IMHO it's better to
ask for a product to be removed from the ProductCatalog than to say
product.suicide(). There can be a standard hook in the product when it's
being uncataloged, so cleanup actions can be performed.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL