[doc/book] remove merged chapter stable
authorAurelien Campeas <aurelien.campeas@logilab.fr>
Mon, 12 Apr 2010 16:57:11 +0200
branchstable
changeset 5221 b851558456bb
parent 5220 42f854b6083d
child 5222 ed6905d98a5e
[doc/book] remove merged chapter
doc/book/en/development/devrepo/hooks.rst
doc/book/en/development/devrepo/index.rst
doc/book/en/development/devrepo/operations.rst
--- a/doc/book/en/development/devrepo/hooks.rst	Mon Apr 12 16:49:35 2010 +0200
+++ b/doc/book/en/development/devrepo/hooks.rst	Mon Apr 12 16:57:11 2010 +0200
@@ -41,7 +41,7 @@
 
 * implement computed attributes
 
-Operations are Hook-like objects that are created by Hooks and
+Operations are Hook-like objects that maye be created by Hooks and
 scheduled to happen just before (or after) the `commit` event. Hooks
 being fired immediately on data operations, it is sometime necessary
 to delay the actual work down to a time where all other Hooks have
@@ -50,6 +50,10 @@
 is data dependant (and thus hard to predict), it is possible to force
 an order on Operations.
 
+Operations also may be used to process various side effects associated
+with a transaction such as filesystem udpates, mail notifications,
+etc.
+
 Operations are subclasses of the Operation class in `server/hook.py`,
 implementing `precommit_event` and other standard methods (wholly
 described later in this chapter).
--- a/doc/book/en/development/devrepo/index.rst	Mon Apr 12 16:49:35 2010 +0200
+++ b/doc/book/en/development/devrepo/index.rst	Mon Apr 12 16:57:11 2010 +0200
@@ -8,7 +8,6 @@
    sessions
    hooks
    notifications
-   operations
    tasks
 
 
--- a/doc/book/en/development/devrepo/operations.rst	Mon Apr 12 16:49:35 2010 +0200
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,38 +0,0 @@
-.. -*- coding: utf-8 -*-
-
-Repository operations
-======================
-
-When one needs to perform operations (real world operations like mail
-notifications, file operations, real-world side-effects) at
-transaction commit time, Operations are the way to go.
-
-Possible events are:
-
-* precommit: the pool is preparing to commit. You shouldn't do
-  anything things which has to be reverted if the commit fail at this
-  point, but you can freely do any heavy computation or raise an
-  exception if the commit can't go.  You can add some new operation
-  during this phase but their precommit event won't be triggered
-
-* commit: the pool is preparing to commit. You should avoid to do to
-  expensive stuff or something that may cause an exception in this
-  event
-
-* revertcommit: if an operation failed while commited, this event is
-  triggered for all operations which had their commit event already to
-  let them revert things (including the operation which made fail the
-  commit)
-
-* rollback: the transaction has been either rollbacked either
-
-  - intentionaly
-  - a precommit event failed, all operations are rollbacked
-  - a commit event failed, all operations which are not been triggered
-    for commit are rollbacked
-
-Exceptions signaled from within a rollback are logged and swallowed.
-
-The order of operations may be important, and is controlled according
-to operation's class (see : Operation, LateOperation, SingleOperation,
-SingleLastOperation).