RE: [ZODB-Dev] before commit hook

[Tim Peters]

[Tim Peters, on adding getBeforeCommitHooks()]
>> Note that Zope 2.8b1 was already released (yesterday) with a ZODB 3.4
>> alpha, so strictly speaking no new features should be added to ZODB 3.4.
>> But if you can slam code and tests for this in quickly, I'll look the
>> other way (I think adding a straightforward new method is about as
>> harmless as can be). Just don't let Jim notice you're doing it .

[Florent Guillaume]
> Ok done, thanks.

Thank you!  It all looked great to me.  Jim hasn't noticed it yet, so I
think it will stay in.

>> Primarily I think that building 90% of an app's logic on
>> beforeCommitHook() may be a mistake .

> Why do you say that?

I was pulling your leg.  That's an American way of showing appreciation.
"" meant it was wholly joking.  "<0.9 wink>" would have meant it was
one-tenth serious.

> I'm not building 90% of my app logic on that, it's really just an
> optimization to delay some things until the end of the transaction.

Ya, like building only 85% of your app's logic on it is better .

BTW, I expect the next ZODB 3.4 release will be beta 1, and new features
will need to go into 3.5 (ZODB trunk alone) then.  I'm very happy that some
people contributed code to make ZODB 3.4 better, with special thanks to you,
Christian Theune, Chris McDonough, Dmitry Vasiliev and Jim Fulton.

___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev

Re: [ZODB-Dev] before commit hook

[Florent Guillaume]

Tim Peters wrote:
> def getBeforeCommitHooks(self):
> 
> Note that Zope 2.8b1 was already released (yesterday) with a ZODB 3.4 alpha,
> so strictly speaking no new features should be added to ZODB 3.4.  But if
> you can slam code and tests for this in quickly, I'll look the other way (I
> think adding a straightforward new method is about as harmless as can be).
> Just don't let Jim notice you're doing it . 

Ok done, thanks.

> Primarily I think that building 90% of an app's logic on beforeCommitHook()
> may be a mistake .

Why do you say that? I'm not building 90% of my app logic on that, it's
really just an optimization to delay some things until the end of the
transaction.

Florent


-- 
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev

RE: [ZODB-Dev] before commit hook

[Tim Peters]

[Florent Guillaume]
> FYI in CPS we use a simple backport of the before commit hook to ZODB
> 3.2:
>

>
> For now we use it to delay indexing of some objects to the end of the
> transaction (to avoid indexing twice the same object for instance):
>

>
> To index something, code just has to do:
> get_indexation_manager().push(ob)
>
>
> In get_indexation_manager() I have to check if there is already a
> registered IndexationManager hook with the transaction. I currently use a
> hack, but what I'd need is a way to query the registered hooks. What do
> people think of adding something like:
>
> def getBeforeCommitHooksImplementing(self, class_):
> """Get the registered beforeCommit hooks subclassing class_."""
> return [(hook, args, kws) for hook, args, kws in self._before_commit
> if isintance(hook, class_)]
>
> (Interfaces could probably be a better choice than classes.) Or is it
> overengineering ? Maybe just a getBeforeCommitHooks that returns
> self._before_commit ?

Primarily I think that building 90% of an app's logic on beforeCommitHook()
may be a mistake .

That said, in general I never object to methods that reveal info other
methods set.  Building a filter into it too is indeed overkill, and actually
gets in the way for some use cases; a caller can surely filter on class, or
interface, or whatever else they like, with ease.  If your specific app
always filters on class, fine, write a tiny three-line function on top of
getBeforeCommitHooks() to do so.

Returning a list is dangerous, because it leaves transactions vulnerable to
unintended mutation, and constrains implementations forever (note that
there's _already_ a TODO in this code to switch ._before_commit to
collections.deque when Python 2.4 can be assumed).  While I don't know of an
official-ish Zope interface for this, Python's concept of "iterable object"
seems a perfect fit here to me.  Like so:

def getBeforeCommitHooks(self):
"""Return iterable producing the registered beforeCommit hooks.

A triple (hook, args, kws) is produced for each registered hook.
The hooks are produced in the order in which they were registered.
"""
 
return iter(self._before_commit)

Since the existing interface already promises ordering guarantees on these
hooks, I think it's a good idea to reveal that order via this method too.

Note that Zope 2.8b1 was already released (yesterday) with a ZODB 3.4 alpha,
so strictly speaking no new features should be added to ZODB 3.4.  But if
you can slam code and tests for this in quickly, I'll look the other way (I
think adding a straightforward new method is about as harmless as can be).
Just don't let Jim notice you're doing it . 

___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev

[ZODB-Dev] before commit hook

[Florent Guillaume]

FYI in CPS we use a simple backport of the before commit hook to ZODB 3.2:
http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/CPS3/CPSCompat/PatchZODBTransaction.py?rev=1&view=markup

For now we use it to delay indexing of some objects to the end of the
transaction (to avoid indexing twice the same object for instance):
http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/CPS3/CPSCore/IndexationManager.py?rev=1&view=markup

To index something, code just has to do:
get_indexation_manager().push(ob)


In get_indexation_manager() I have to check if there is already a
registered IndexationManager hook with the transaction. I currently use
a hack, but what I'd need is a way to query the registered hooks. What
do people think of adding something like:

def getBeforeCommitHooksImplementing(self, class_):
"""Get the registered beforeCommit hooks subclassing class_."""
return [(hook, args, kws) for hook, args, kws in self._before_commit
if isintance(hook, class_)]

(Interfaces could probably be a better choice than classes.)
Or is it overengineering ? Maybe just a getBeforeCommitHooks that
returns self._before_commit ?

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev