[Zope-dev] Bulletproof ZCatalog proposal

[Shane Hathaway]

On Thursday 07 June 2001 21:28, Phillip J. Eby wrote:
> Yep.  One of the last two times I spoke with Jim in person (either
> the January DC visit or IPC 8, I forget which), he said something
> about it maybe being a good idea to have some kind of priority system
> like that. I'd love to see something like it exist, if it would make
> some of ZPatterns' hackery unnecessary.

Yes, I would too.  I'm happy to see we're in complete agreement.

> The implementation could consist of two subscription queues:
> ruleAgents and indexingAgents.  ZCatalog would register in
> indexingAgents, and ZPatterns objects would register in one or the
> other, usually ruleAgents.  (I can think of some circumstances where
> it would be nice to use the indexingAgents queue, but right now
> ZPatterns apps have to work around this by defining their rules in
> execution priority order.)

Ah-ha, this is sounding familiar.  You talked about rule agents and 
indexing agents in the ZPatterns wiki. 

> Upon being told to perform a transaction or subtransaction commit,
> the transaction would notify all the ruleAgents, and then all the
> indexingAgents.  Objects could still subscribe to either queue while
> this notifying is taking place.  (So that triggered actions could
> cause indexish objects to register as indexingAgents, not to mention
> causing updated objects to fire additional triggers.)
>
> Once all agents in a queue are notified, that queue should be cleared
> so that notifications are on a per-subtransaction basis.  Once both
> queues are cleared, normal transaction behavior goes forward.

Would you say this would occur before tpc_begin() messages or just 
after?

> Hm.  That's simpler than I thought it was going to be.  Shoot, I can
> even see how to implement it as a runtime patch, that would've been
> simpler than all the shenanigans ZPatterns goes through to fake out
> the transaction machinery...  and it's a better
> implementation.  Ah well.  At the time I wanted to avoid trying to
> convince Jim to add machinery to transactions "just" for ZPatterns,
> given that ZPatterns wasn't a particularly established product at the
> time.
>
> Let me know if you guys put something like this in, though, and I'll
> definitely look at reworking ZPatterns to use the mechanism.  It
> could potentially cut a lot of code out and improve the robustness at
> the same time.

I don't foresee us adding this capability right away since we need to 
understand it better and it only applies to one working product and a 
hypothetical product.  I'd suggest you go ahead with the runtime patch.

Shane