Re: [ZODB-Dev] RFC: Pre-commit hooks

[Chris Withers]

Tim Peters wrote:
Very nice, Florent -- thank you!  I added some stuff (trust me, you won't
object ), and merged it to the 3.4 branch and to the ZODB trunk.  I'll
remove ZODB/branches/efge-beforeCommitHook next.  One of the nice things
about SVN is that "retired" branches and tags don't have to keep punching
you in the face forever (of course you can get the branch back again, if you
need/want to, by reverting the checkin that deletes it!).
Or just checking it out at the revision where it last existed ;-)
Chris - ain't time travel great?
--
Simplistix - Content Management, Zope & Python Consulting
   - http://www.simplistix.co.uk
___
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] RFC: Pre-commit hooks

[Tim Peters]

[Florent Guillaume]
> I've added the code on a branch off 3.4:
>
>   http://svn.zope.org/?rev=29885&view=rev
>
> Could someone check if it's suitable and merge it ?

Very nice, Florent -- thank you!  I added some stuff (trust me, you won't
object ), and merged it to the 3.4 branch and to the ZODB trunk.  I'll
remove ZODB/branches/efge-beforeCommitHook next.  One of the nice things
about SVN is that "retired" branches and tags don't have to keep punching
you in the face forever (of course you can get the branch back again, if you
need/want to, by reverting the checkin that deletes 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

Re: [ZODB-Dev] RFC: Pre-commit hooks

[Florent Guillaume]

I've added the code on a branch off 3.4:

  http://svn.zope.org/?rev=29885&view=rev

Could someone check if it's suitable and merge it ?

Florent

Jim Fulton  <[EMAIL PROTECTED]> wrote:
> 
> I propose to add a pre-commit hook to ZODB.
> 
> Problem
> 
>Sometimes, applications want to execute some code when
>a transaction is committed.  For example, one might want to
>delay object indexing until a transaction commits, rather
>than indexing every time an object is changed. Or, someone
>might want to check invariants only after a set of operations.
> 
> Proposal
> 
>We add a new method to transaction objects:
> 
>   def beforeCommitHook(hook, *args, **kw):
>   """Register a hook to call before the transaction is committed
> 
>The provided hook will be called after the transaction's
>commit method has been called, but before the commit process
>has been started.  The hook will be passed the given
>positional and keyword arguments.
> 
>Multiple hooks can be registered and will be called in order.
>This method can be called from executing hooks.  That is, executing
>hooks can register more hooks.  (Applications should take care
>to avoid creating infinite loops by recursvely registering hooks.)
> 
>Hooks are not called and are discarded if the transaction aborts.
>"""
> 
>We would also modify transaction commit methods to call hooks.  Hooks would
>not be called on sub-transaction commit.  (If necessary, we could add
>separate sub-transaction hooks, but I don't think we need this.)
> 
>This hook is very simple to use an implement and, I think, addresses
>the requitement much more directly than implementing special data
>managers.
> 
> Thoughts?
> 
> Anyone up for implementing this (with a doctest, of course)?
> 
> I'd like to get this into ZODB 3.4.
> 
> Jim


-- 
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] RFC: Pre-commit hooks

[Tim Peters]

[Jim Fulton]
...
> In other words, implementing the interface that transactions expect of
> things like adtabase connections.  Unfortunately, this wasn't documented
> until recently.  In ZODB 3.3, transaction.interfaces has
> IDataManagerOriginal which attempts to document the ZODB 3.2
> transaction-manager interface.

Alas, no, ZODB 3.3 has no such thing.  IDataManagerOriginal was introduced
in ZODB 3.4, and seems to have gotten thrown away during the ZODB sprint,
although a comment still refers to it.  Have to look at an old revision to
find it now:


 
> Unfortunately, the data manager interface for ZODB 3.3 isn't accurately
> documented yet.  (There's even a bonus inacurate interface. ;) Tim and I
> intend to fix this this week.

And betting there's more to be fixed than we realize even now <0.9 wink>.

___
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] RFC: Pre-commit hooks

[Julien Anguenot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Fulton wrote:
> Julien Anguenot wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Jim Fulton wrote:
>>
>>> Julien Anguenot wrote:
>>>
>>>
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 I implemented a pre-commit hook on transaction supporting subscribers
 within CPS for our indexation use case. (for ZODB-3.2.x on
 Zope-2.7.x)
>>>
>>>
>>>
>>> Cool
>>>
>>>
 if you're interested to take a look at it :

 http://lists.nuxeo.com/pipermail/cps-devel/2005-April/001357.html
>>>
>>>
>>>
>>> I get a traceback from viewcvs when I try to view the patch.
>>>
>>
>>
>> this one ? :
>>
>> http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/CPS3/CPSCore/PatchZODB.py?rev=1.1&view=auto
>>
>>
> 
> No, the one given in
> 
>   http://lists.nuxeo.com/pipermail/cps-devel/2005-April/001357.html
> 
> which is:
> 
>   http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/CPS3/CPSCore/PatchZODB.py
> 
> :)
> 
>>
 The difference I can see with your proposal is the abort() hook
 facility
 that can be a good thing especially if the subscriber code has to
 communicate with external programs for rollback purpose.
>>>
>>>
>>>
>>> I suggest that if you are going to "communicate with external
>>> programs for rollback purpose", it would be much better to
>>> participate as a data manager.
>>>
>>
>>
>> in ZODB-3.2 ? Can you explain ?
> 
> 
> In other words, implementing the interface that transactions
> expect of things like adtabase connections.  Unfortunately,
> this wasn't documented until recently.  In ZODB 3.3,
> transaction.interfaces has IDataManagerOriginal which attempts
> to document the ZODB 3.2 transaction-manager interface.
> 
> Unfortunately, the data manager interface for ZODB 3.3 isn't
> accurately documented yet.  (There's even a bonus inacurate
> interface. ;) Tim and I intend to fix this this week.
>

ok.

>>> I would say that the main difference is that with the simple hook
>>> facility I proposed, you can just register simple callables. You
>>> don't have to create a class.
>>
>>
>>
>> ok for this. My idea is to control what people are going to register. So
>> I'm adding constraints by providing an interface they need to implement
>> for their own subscribers. That's mostly the point.
> 
> 
> Are you saying that you don't want people to use this facility
> and you want to make them work harder in order to discourage them?
> 
> ;)
> 

It's more to simplify mine and avoid debug time, actually :) Believe me
I'm having my reasons for doing this even if I get your point...


  Java people coming to Python like having constraints at first ;)


J.

- --
Julien Anguenot | Nuxeo R&D (Paris, France)
CPS Plateform : http://www.cps-project.org
mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFCUZWfGhoG8MxZ/pIRAgo/AJ9e9ALpAB5SHidH65f53ampgL4CogCeN2LH
4aRQeVoGdcAV0d6uuxXG/hw=
=TgN3
-END PGP SIGNATURE-
___
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] RFC: Pre-commit hooks

[Jim Fulton]

Julien Anguenot wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
Julien Anguenot wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I implemented a pre-commit hook on transaction supporting subscribers
within CPS for our indexation use case. (for ZODB-3.2.x on
Zope-2.7.x)

Cool

if you're interested to take a look at it :
http://lists.nuxeo.com/pipermail/cps-devel/2005-April/001357.html

I get a traceback from viewcvs when I try to view the patch.

this one ? :
http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/CPS3/CPSCore/PatchZODB.py?rev=1.1&view=auto
No, the one given in
  http://lists.nuxeo.com/pipermail/cps-devel/2005-April/001357.html
which is:
  http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/CPS3/CPSCore/PatchZODB.py
:)

The difference I can see with your proposal is the abort() hook facility
that can be a good thing especially if the subscriber code has to
communicate with external programs for rollback purpose.

I suggest that if you are going to "communicate with external
programs for rollback purpose", it would be much better to
participate as a data manager.

in ZODB-3.2 ? Can you explain ?
In other words, implementing the interface that transactions
expect of things like adtabase connections.  Unfortunately,
this wasn't documented until recently.  In ZODB 3.3,
transaction.interfaces has IDataManagerOriginal which attempts
to document the ZODB 3.2 transaction-manager interface.
Unfortunately, the data manager interface for ZODB 3.3 isn't
accurately documented yet.  (There's even a bonus inacurate
interface. ;) Tim and I intend to fix this this week.
I would say that the main difference is that with the simple hook
facility I proposed, you can just register simple callables. You
don't have to create a class.

ok for this. My idea is to control what people are going to register. So
I'm adding constraints by providing an interface they need to implement
for their own subscribers. That's mostly the point.
Are you saying that you don't want people to use this facility
and you want to make them work harder in order to discourage them?
;)
Jim
--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
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] RFC: Pre-commit hooks

[Julien Anguenot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Fulton wrote:
> Julien Anguenot wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> I implemented a pre-commit hook on transaction supporting subscribers
>> within CPS for our indexation use case. (for ZODB-3.2.x on
>> Zope-2.7.x)
> 
> 
> Cool
> 
>> if you're interested to take a look at it :
>>
>> http://lists.nuxeo.com/pipermail/cps-devel/2005-April/001357.html
> 
> 
> I get a traceback from viewcvs when I try to view the patch.
>

this one ? :

http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/CPS3/CPSCore/PatchZODB.py?rev=1.1&view=auto


>> The difference I can see with your proposal is the abort() hook facility
>> that can be a good thing especially if the subscriber code has to
>> communicate with external programs for rollback purpose.
> 
> 
> I suggest that if you are going to "communicate with external
> programs for rollback purpose", it would be much better to
> participate as a data manager.
>

in ZODB-3.2 ? Can you explain ?

> I would say that the main difference is that with the simple hook
> facility I proposed, you can just register simple callables. You
> don't have to create a class.

ok for this. My idea is to control what people are going to register. So
I'm adding constraints by providing an interface they need to implement
for their own subscribers. That's mostly the point.

> 
> I also don't see any point in making it the responsibility of
> the hook to register itself, 

Hum.. yeah it's probably useless in here... It's calling the
registerBeforeCommitHookSubscriber() method of the transaction anyway.

> or what the queue business is about.
>

It's specific for the indexation manager. All the objects that need to
be reindex during the transaction are stored there with properties
(idxs, security reindexation, etc...) and then this queue is flushed by
the susbcriber called by the hook added just before the commit. commit()
method.

Thanks for your feedbacks Jim.

J.


- --
Julien Anguenot | Nuxeo R&D (Paris, France)
CPS Plateform : http://www.cps-project.org
mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFCUYymGhoG8MxZ/pIRAjypAKCDDXJGKr9r8uz87dVQs9whFiM5BgCfc21S
R3f6qTXCrIcHzDme5UPhLoQ=
=167/
-END PGP SIGNATURE-
___
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] RFC: Pre-commit hooks

[Jim Fulton]

Julien Anguenot wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I implemented a pre-commit hook on transaction supporting subscribers
within CPS for our indexation use case. (for ZODB-3.2.x on
Zope-2.7.x)
Cool
if you're interested to take a look at it :
http://lists.nuxeo.com/pipermail/cps-devel/2005-April/001357.html
I get a traceback from viewcvs when I try to view the patch.
The difference I can see with your proposal is the abort() hook facility
that can be a good thing especially if the subscriber code has to
communicate with external programs for rollback purpose.
I suggest that if you are going to "communicate with external
programs for rollback purpose", it would be much better to
participate as a data manager.
I would say that the main difference is that with the simple hook
facility I proposed, you can just register simple callables. You
don't have to create a class.
I also don't see any point in making it the responsibility of
the hook to register itself, or what the queue business is about.
Jim
--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
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] RFC: Pre-commit hooks

[Julien Anguenot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I implemented a pre-commit hook on transaction supporting subscribers
within CPS for our indexation use case. (for ZODB-3.2.x on
Zope-2.7.x)

if you're interested to take a look at it :

http://lists.nuxeo.com/pipermail/cps-devel/2005-April/001357.html

The difference I can see with your proposal is the abort() hook facility
that can be a good thing especially if the subscriber code has to
communicate with external programs for rollback purpose.

J.

Jim Fulton wrote:
> 
> I propose to add a pre-commit hook to ZODB.
> 
> Problem
> 
>   Sometimes, applications want to execute some code when
>   a transaction is committed.  For example, one might want to
>   delay object indexing until a transaction commits, rather
>   than indexing every time an object is changed. Or, someone
>   might want to check invariants only after a set of operations.
> 
> Proposal
> 
>   We add a new method to transaction objects:
> 
>  def beforeCommitHook(hook, *args, **kw):
>  """Register a hook to call before the transaction is committed
> 
>   The provided hook will be called after the transaction's
>   commit method has been called, but before the commit process
>   has been started.  The hook will be passed the given
>   positional and keyword arguments.
> 
>   Multiple hooks can be registered and will be called in order.
>   This method can be called from executing hooks.  That is,
> executing
>   hooks can register more hooks.  (Applications should take care
>   to avoid creating infinite loops by recursvely registering
> hooks.)
> 
>   Hooks are not called and are discarded if the transaction aborts.
>   """
> 
>   We would also modify transaction commit methods to call hooks.  Hooks
> would
>   not be called on sub-transaction commit.  (If necessary, we could add
>   separate sub-transaction hooks, but I don't think we need this.)
> 
>   This hook is very simple to use an implement and, I think, addresses
>   the requitement much more directly than implementing special data
>   managers.
> 
> Thoughts?
> 
> Anyone up for implementing this (with a doctest, of course)?
> 
> I'd like to get this into ZODB 3.4.
> 
> Jim
> 


- --
Julien Anguenot | Nuxeo R&D (Paris, France)
CPS Plateform : http://www.cps-project.org
mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFCUXraGhoG8MxZ/pIRAsjtAJ4uKVSNOR3HcJT+pcCHKw8Xp4n+oACeMcxh
E8OiBlgq0dF43tGRasJsjyU=
=FLDY
-END PGP SIGNATURE-
___
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] RFC: Pre-commit hooks

[Jim Fulton]

Jeremy Hylton wrote:
On Apr 4, 2005 10:53 AM, Jim Fulton <[EMAIL PROTECTED]> wrote:
  We would also modify transaction commit methods to call hooks.  Hooks would
  not be called on sub-transaction commit.  (If necessary, we could add
  separate sub-transaction hooks, but I don't think we need this.)

The effect here is to register a one-short synchronizer, so all the
code already exists.  Or, add another line just after the
beforeCompletion() call in _transaction.py.  I think the question to
ask is how to make these two closely related APIs understandable to
users.  The synchronizers API is slightly more general, but still
focused clearly on observing transaction boundaries.  Perhaps the new
hook is just a sugar on top of the synchronizer API.
See my response to your earlier comment. I don't think the existing api
is a very good fit at all.

  This hook is very simple to use an implement and, I think, addresses
  the requitement much more directly than implementing special data
  managers.

Perhaps you misunderstand the synchronizer API.  It does not deal with
data managers at all.  The registered objects just implement
beforeCompletion() and afterCompletion().
I would argue though that it is well suited to data managers and
not well suited to the use case in question.
Jim
--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
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] RFC: Pre-commit hooks

[Tim Peters]

[Jeremy Hylton]
...
> Perhaps you misunderstand the synchronizer API.  It does not deal with
> data managers at all.  The registered objects just implement
> beforeCompletion() and afterCompletion().

Ya, the interfaces here are wrong.  There is no "synchronizer" interface,
and at the ZODB sprint {after,before}Completion got added to the
IDataManager interface (or already was there, or something -- don't want to
bother chasing down the history of this one).

___
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] RFC: Pre-commit hooks

[Jeremy Hylton]

On Apr 4, 2005 10:53 AM, Jim Fulton <[EMAIL PROTECTED]> wrote:
>We would also modify transaction commit methods to call hooks.  Hooks would
>not be called on sub-transaction commit.  (If necessary, we could add
>separate sub-transaction hooks, but I don't think we need this.)

The effect here is to register a one-short synchronizer, so all the
code already exists.  Or, add another line just after the
beforeCompletion() call in _transaction.py.  I think the question to
ask is how to make these two closely related APIs understandable to
users.  The synchronizers API is slightly more general, but still
focused clearly on observing transaction boundaries.  Perhaps the new
hook is just a sugar on top of the synchronizer API.

>This hook is very simple to use an implement and, I think, addresses
>the requitement much more directly than implementing special data
>managers.

Perhaps you misunderstand the synchronizer API.  It does not deal with
data managers at all.  The registered objects just implement
beforeCompletion() and afterCompletion().

Jeremy
___
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] RFC: Pre-commit hooks

[Jim Fulton]

Florent Guillaume wrote:
Jim Fulton  <[EMAIL PROTECTED]> wrote:
...
Proposal
  We add a new method to transaction objects:
 def beforeCommitHook(hook, *args, **kw):
 """Register a hook to call before the transaction is committed
  The provided hook will be called after the transaction's
  commit method has been called, but before the commit process
  has been started.  The hook will be passed the given
  positional and keyword arguments.

The hook probably may want to be called with the transaction object
itself as arguments, or is it a YAGNI? I'm saying this because
synchronizers are passed the transaction, OTOH this is at a slightly
higher level and we may not care about the transaction.
If the hook wants the transaction, then the transaction can be passed as
one of the arguments when the hook is registered.
...
Anyone up for implementing this (with a doctest, of course)?

Yes I'll look at it.
Great! Thanks.
Jim
--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
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] RFC: Pre-commit hooks

[Florent Guillaume]

Jim Fulton  <[EMAIL PROTECTED]> wrote:
> I propose to add a pre-commit hook to ZODB.

+1 of course.

> Proposal
> 
>We add a new method to transaction objects:
>
>   def beforeCommitHook(hook, *args, **kw):
>   """Register a hook to call before the transaction is committed
> 
>The provided hook will be called after the transaction's
>commit method has been called, but before the commit process
>has been started.  The hook will be passed the given
>positional and keyword arguments.

The hook probably may want to be called with the transaction object
itself as arguments, or is it a YAGNI? I'm saying this because
synchronizers are passed the transaction, OTOH this is at a slightly
higher level and we may not care about the transaction.

>Multiple hooks can be registered and will be called in order.
>This method can be called from executing hooks.  That is, executing
>hooks can register more hooks.  (Applications should take care
>to avoid creating infinite loops by recursvely registering hooks.)

Yes, that's exactly what I was doing for my post-publishing hook called by 
Publish.py

>Hooks are not called and are discarded if the transaction aborts.
>"""
> 
>We would also modify transaction commit methods to call hooks.  Hooks would
>not be called on sub-transaction commit.  (If necessary, we could add
>separate sub-transaction hooks, but I don't think we need this.)
> 
>This hook is very simple to use an implement and, I think, addresses
>the requitement much more directly than implementing special data
>managers.
> 
> Thoughts?
> 
> Anyone up for implementing this (with a doctest, of course)?

Yes I'll look at it.

Florent

> I'd like to get this into ZODB 3.4.
> 
> Jim

-- 
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] RFC: Pre-commit hooks

[Christian Robottom Reis]

On Mon, Apr 04, 2005 at 10:53:05AM -0400, Jim Fulton wrote:
>   Sometimes, applications want to execute some code when
>   a transaction is committed.  For example, one might want to
>   delay object indexing until a transaction commits, rather
>   than indexing every time an object is changed. Or, someone
>   might want to check invariants only after a set of operations.

+1. The IndexedCatalog Shelf, for instance, does exactly this, flushing
the cached changes into the index when shelf.commit() is called.

Take care,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331
___
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