[ZODB-Dev] Pluggable transactions logic

[Steve Alexander]

Chris Withers wrote:
 >> * The ZODB gets an API to support plugging in arbitrary processing
 >>  at various points in transaction processing.
 >>
 >> The latter approach is best if you want to keep ZODB simple, but
 >> allow arbitrary other more complex transaction processing to
 >> happen, in arbitrary combinations.
 >>
 >
 > This sounds like the way forward to me...
 >
 > Just so it's recorded somewhere, my API use case would be something
 > like:
 >
 > from ZODB import registerAgent, COMMIT
 >
 > class MyObj(PortalContent): # My content storage class pass
 >
 > def myMethod(obj) obj.portal_catalog.catalog_object(obj)
 >
 > registerAgent(myMethod,[MyObj],COMMIT,100)
 >
 > The first argument is the method to be called.
 >
 > The second argument is a list of classes. This indicates that this
 > method should be called when objects of that class are committed.
 > Maybe that could be interfaces as well/instead? If this list is
 > empty, the method gets called for all types of object.
 >
 > COMMIT is an integer constant indicating at what point in the
 > transaction myMethod gets called.
 >
 > 100 is the priority. Methods are called in order of their priority.

Do you really need a number to represent the priority? I thought about 
that, but I can't think of a case that's not handled by having just two 
queues: Rule Agents and Indexing Agents.

Also, have you considered what should happen with the priorities on a 
subtransaction commit?


Take a look in the tests that are with TransactionAgents, and what 
happens when, while an agent is running, it adds another agent, and 
commits a subtransaction.

It could be that you only want your agents to run on a complete outer 
transaction (that is, not a subtransaction). However, I need to be able 
to commit subtransactions from my agents.


And are you sure you mean what you say with those classes... how will 
the method know what has happened to instances of the classes in 
question? That is, I think you'll only have access to the new state of 
the instances, so you won't have a baseline against which to tell how 
they've changed. This is what the DataSkin class does in ZPatterns. It 
keeps tracks of how things have changed during a transaction.

I think you're thinking of a much higher-level interface than John or I 
are working with. That's not a bad thing... but I think we need to think 
about the API you'd need to support the interface that your users would 
use to register classes for processing. If I understand correctly what 
you have in mind, you'd need a low-level API to inspect what the objects 
that are being committed during a transaction, and make decisions based 
on that. You'd probably also want to do certain things depending on an 
object's physical path... but that's a Zope thing, not a ZODB thing.
Hmm... perhaps you can throw together a prototype for what you want?

---

Then again, if we're working on a pluggable API for this, I can stick 
with my two queues + subtransaction support, and plug that in. You can 
also plug in your register agents to happen at various points for 
various classes with various priorities stuff.

We probably need to consider what happens when there is a name 
collision. Should the names all be added to the Transaction class, so 
you'd do get_transaction().your_method_here().

Perhaps it would be better to have something like:

get_transaction().agents.register(...)

Then, different plug-ins just need to agree on dividing up the agents 
namespace :-)

Of course, there's also something like:

get_transaction().agents.chrisw.register(...)
get_transaction().agents.TransactionAgents.register(....)

--
Steve Alexander
Software Engineer
Cat-Box limited