Re: [Zope-dev] Bulletproof ZCatalog proposal
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
At 04:58 PM 6/8/01 -0400, Shane Hathaway wrote:
On Thursday 07 June 2001 21:28, Phillip J. Eby wrote:
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?
Before. I'm saying this would take place immediately at the start of the existing Transaction.commit() method.
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.
I think I'll wait until ZPatterns works with Zope 2.4, unless it becomes necessary otherwise. Replacing what I've got now is a pretty significant undertaking, and risk-prone to boot, so I don't want to delay the finishing of ZPatterns' support for Zope 2.3.x. Basically, the runtime patch would be to replace ZODB.Transaction.Transaction with a subclass that implemented the notification queues in the commit() method. There'd be a few other little extensions needed, like clearing the queues on any abort operation, and adding registerIndex() and registerRule() or some such methods.
Please remove the del statement in the ZODB __init__.py file to make this possible. I am simply trying to create my own Transaction objects and can't without patching the StandaloneZODB release to do this. Thanks, John On Friday 08 June 2001 16:21, Phillip J. Eby wrote:
At 04:58 PM 6/8/01 -0400, Shane Hathaway wrote:
On Thursday 07 June 2001 21:28, Phillip J. Eby wrote:
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?
Before. I'm saying this would take place immediately at the start of the existing Transaction.commit() method.
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.
I think I'll wait until ZPatterns works with Zope 2.4, unless it becomes necessary otherwise. Replacing what I've got now is a pretty significant undertaking, and risk-prone to boot, so I don't want to delay the finishing of ZPatterns' support for Zope 2.3.x.
Basically, the runtime patch would be to replace ZODB.Transaction.Transaction with a subclass that implemented the notification queues in the commit() method. There'd be a few other little extensions needed, like clearing the queues on any abort operation, and adding registerIndex() and registerRule() or some such methods.
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
-- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | jheintz@isogen.com w w w . d a t a c h a n n e l . c o m
participants (3)
-
John D. Heintz -
Phillip J. Eby -
Shane Hathaway