Edgewall Software

Changes between Version 8 and Version 9 of TracDev/Proposals/DataModel


Ignore:
Timestamp:
Apr 28, 2018, 7:55:44 PM (17 months ago)
Author:
figaro
Comment:

Cosmetic changes

Legend:

Unmodified
Added
Removed
Modified
  • TracDev/Proposals/DataModel

    v8 v9  
    1 = Trac Data Model Proposal =
     1= Trac Data Model Proposal
    22
    3 '''Note:''' ''this was the original rough sketch. See GenericTrac for a later evolution of the proposal.''
     3{{{#!box info
     4'''Note:''' This was the original rough sketch. See GenericTrac for a later evolution of the proposal.
     5}}}
    46
    5 == The Context ==
     7== The Context
     8
    69Trac stores the data for its resources in various tables, each tailored to a specific situation.
    710This leads to a similar variety of APIs in our model modules, to heterogeneous functionality for no good reason etc. All of this has been exposed for a long time, in the TracObjectModelProposal.
    811
    9 More recently, I outlined a way to provide more consistent change tracking and store the authorship of resource modifications in a consistent way, in TracDev/Proposals/Journaling.
     12A way to provide more consistent change tracking and store the authorship of resource modifications can be found in TracDev/Proposals/Journaling.
    1013
     14== The Generic Model
    1115
    12 == The Generic Model ==
     16=== Resource Data
    1317
    14 === Resource Data ===
    15 The new model should have a good balance between ''generality'', so that the API can be the same across resources) and ''specificity'' so that the DB load is spread across multiple tables, and additional tables can be easily joined to the generic ones, depending on a module specific need (in particular, the vc layer).
     18The new model should have a good balance between ''generality'', so that the API can be the same across resources) and ''specificity'' so that the database load is spread across multiple tables, and additional tables can be easily joined to the generic ones, depending on a module specific need (in particular, the vc layer).
    1619
    1720Each resource type could eventually have its own main table, for registering the identity of each object. There are pros/cons for that:
     
    2831
    2932The property approach is essential for solving some of the main drawbacks of the current model:
    30  - overcome the 1:1 limitation of ticket -> milestone, ticket -> component (btw, components should also become toplevel resources)
     33 - overcome the 1:1 limitation of ticket -> milestone, ticket -> component (also, components should become top level resources)
    3134 - deal with content in an uniform way; for example, it should be possible to access a wiki page content and a ticket description the same way (see #2945).
    3235
    3336The property tables above contain a ''snapshot'' of the current values for those objects. They are always updated after a change.
    3437
    35 === Resource Change History ===
    36 Every "transaction" (change to any resource in the system) is tracked in a `<resource>_journal` table, containing an unique identifier for the change `tid`, the date of the change, the authorship information `(author, ip number, authenticated flag)` and the affected resource `id` (*).
     38=== Resource Change History
     39
     40Every "transaction" (change to any resource in the system) is tracked in a `<resource>_journal` table, containing an unique identifier for the change `tid`, the date of the change, the authorship information `(author, ip number, authenticated flag)` and the affected resource `id`. For dealing with "batch" changes (e.g. #525), there could eventually be a specific extension to this: if the `id` data stored in `<resource>_journal` is NULL, then we'd look in a `<resource>_batch` table, relating the `tid` to (1:N) `id` of resources.
    3741
    3842For each property table, there will be a corresponding `<resource>_<prop>_history` table, containing the `(tid, name, value)` triples corresponding to what has changed during this transaction. No more ''(old_value, new_value)'' pairs, as this can easily be reconstructed from the full history of changes.
     
    4448Lastly, there would be a `<resource>_overlay` table for storing old versions of versioned properties themselves, should they ever change. This would be a way to enable editing ticket comments (see #454), and possibly ''version 1'' of commit messages, should they change in the repository itself (#731).
    4549
    46 (*) ,,For dealing with "batch" changes (e.g. #525), there could eventually be a specific extension to this: if the `id` data stored in `<resource>_journal` is NULL, then we'd look in a `<resource>_batch` table, relating the `tid` to (1:N) `id` of resources.,,
    47 
    48  ''to be continued...''
    49 
    5050----
    5151See also: TracDev/Proposals, [[TicketQuery(status=!closed&keywords=~tracobject,compact)]]