Changes between Version 3 and Version 4 of TracDev/Proposals/Journaling

Timestamp:

Apr 17, 2008, 12:08:06 PM (16 years ago)

Author:

Christian Boos

Comment:

Refer to TracDev/JournalingProposal for a simpler approach

TracDev/Proposals/Journaling

@@ -36 +36 @@
 == A solution ==
 
-Every ''change'' event could be journaled.
-Several `journal` tables (one per resource) could record all the transactions and serve as
-a basis for dispatching changes happening in one process 
-to other processes, in a generic way.
+See TracDev/JournalingProposal for a more concise solution.
 
-After all, such a kind of journaling is already done for tickets.
+Now, what is described below is still useful for what has been discussed in #1890 (improved recording of ticket changes) and will eventually be consolidated with  TracDev/Proposals/DataModel#ResourceChangeHistory one day.
+
 
 === Current Situation ===
@@ -112 +110 @@
 `ticket_history` could eventually be spread in multiple, type-specialized tables (`ticket_int_property`, ...).
 
-See also TracDev/Proposals/DataModel#ResourceChangeHistory.
 
 The `change` column in `<resource>_journal` could contain some keyword about
@@ -145 +142 @@
 
 === Notifying changes ===
-Now, how to use this information?
-
-Each module's `notify(tnx)` method would have to propagate the appropriate change information to registered listeners (the IWikiChangeListener, ITicketChangeListener, etc. interfaces).
-
-Each module would also have to keep track of the last `tid` it has dispatched.
-In `notify(tnx)`, we would check for all existing `tid` inserted since the last dispatched `tid` (or the one we had at system startup). If there are more than one `tid`, those are coming from changes created by ''other'' processes.
-
-This way, we could easily differentiate between '''primary''' changes and '''secondary''' changes. 
- primary change:: `tid == tnx.tid`; the change originated from the same process.
-  There's only one process which ever sees a change as being a primary change, it's the one which just created that change.
- secondary change:: `tid != tnx.tid`; the change originated from another process.
-
-This distinction is quite important w.r.t. to side-effects.
-
-Only ''primary'' changes should ever generate side-effects, such as e-mail
-notifications (a related topic: e-mail notifications should also be based 
-on change listeners, see #1660). That way, one can be sure that the side-effects 
-will be triggered only once, independantly from the number of server processes.
-
-Then, ''secondary'' changes could be used for all the informational stuff,
-for refreshing all sorts of internal caches (the use cases listed 
-[TracDev/Proposals/Journaling#Someexamples above]).
-
-Finally note that this Transaction class could make good use of the [http://www.sqlalchemy.org/docs/unitofwork.myt Unit Of Work] concept of SQLAlchemy, should we use that in a future version.
+(See TracDev/Proposals/Journaling@3 for the older proposal and see TracDev/JournalingProposal for how this could be handled in a simpler way)