Edgewall Software

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


Ignore:
Timestamp:
Apr 17, 2008, 12:08:06 PM (14 years ago)
Author:
Christian Boos
Comment:

Refer to TracDev/JournalingProposal for a simpler approach

Legend:

Unmodified
Added
Removed
Modified
  • TracDev/Proposals/Journaling

    v3 v4  
    3636== A solution ==
    3737
    38 Every ''change'' event could be journaled.
    39 Several `journal` tables (one per resource) could record all the transactions and serve as
    40 a basis for dispatching changes happening in one process
    41 to other processes, in a generic way.
     38See TracDev/JournalingProposal for a more concise solution.
    4239
    43 After all, such a kind of journaling is already done for tickets.
     40Now, 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.
     41
    4442
    4543=== Current Situation ===
     
    112110`ticket_history` could eventually be spread in multiple, type-specialized tables (`ticket_int_property`, ...).
    113111
    114 See also TracDev/Proposals/DataModel#ResourceChangeHistory.
    115112
    116113The `change` column in `<resource>_journal` could contain some keyword about
     
    145142
    146143=== Notifying changes ===
    147 Now, how to use this information?
    148 
    149 Each module's `notify(tnx)` method would have to propagate the appropriate change information to registered listeners (the IWikiChangeListener, ITicketChangeListener, etc. interfaces).
    150 
    151 Each module would also have to keep track of the last `tid` it has dispatched.
    152 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.
    153 
    154 This way, we could easily differentiate between '''primary''' changes and '''secondary''' changes.
    155  primary change:: `tid == tnx.tid`; the change originated from the same process.
    156   There's only one process which ever sees a change as being a primary change, it's the one which just created that change.
    157  secondary change:: `tid != tnx.tid`; the change originated from another process.
    158 
    159 This distinction is quite important w.r.t. to side-effects.
    160 
    161 Only ''primary'' changes should ever generate side-effects, such as e-mail
    162 notifications (a related topic: e-mail notifications should also be based
    163 on change listeners, see #1660). That way, one can be sure that the side-effects
    164 will be triggered only once, independantly from the number of server processes.
    165 
    166 Then, ''secondary'' changes could be used for all the informational stuff,
    167 for refreshing all sorts of internal caches (the use cases listed
    168 [TracDev/Proposals/Journaling#Someexamples above]).
    169 
    170 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.
     144(See TracDev/Proposals/Journaling@3 for the older proposal and see TracDev/JournalingProposal for how this could be handled in a simpler way)