Edgewall Software

Changes between Version 47 and Version 48 of GenericTrac


Ignore:
Timestamp:
Aug 31, 2017, 5:55:51 PM (2 years ago)
Author:
figaro
Comment:

Further cosmetic changes

Legend:

Unmodified
Added
Removed
Modified
  • GenericTrac

    v47 v48  
    99 - the storage level, how the resource data are stored on persistent memory
    1010
    11 The high level API is intended to unify and take the best aspects of the different model used so far (!WikiPage, Ticket, Milestone, etc.). Actually, only the Ticket is really flexible and nice, the others are just simpler and much more limited models, so it's rather an "embrace and extend" move from the Ticket model to the others.
     11The high level API is intended to unify and take the best aspects of the different model used so far, such as !WikiPage, Ticket, Milestone. Only the Ticket is flexible and nice, the others are simpler and more limited models, so it's rather an "embrace and extend" move from the Ticket model to the others.
    1212
    1313While the high level API tends to unify things, the low level API will be there to introduce some diversity in the storage, at best transparent to the "user" of the higher level API. Those different storage models could be different table layouts in the database, but also in the longer term, different or complementary storage backend. It would be more appropriate to keep the change history in a dedicated system, like a version control backend, even a [DistributedTrac distributed] one.
    1414
    1515The main benefits expected from the new API are:
    16  - simplification of the internals of Trac, especially for the ticket model, in which the storage of changes is quite cumbersome (see #454, #6466)
    17  - solve a few design problems with the current data model (like #1890, #4582)
     16 - simplification of the internals of Trac, especially for the Ticket model, in which the storage of changes is quite cumbersome (see #454, #6466)
     17 - solve design problems with the current data model (like #1890, #4582)
    1818 - allow better code reuse and sharing of the base features among different kinds of resources (like #695, #1113, and a lot more, see [#RelatedTickets] below)
    1919
    2020== Related Proposals
    2121
    22 The idea is not new, it has its root in the TracObjectModelProposal, and was refined several times in TracDev/Proposals/DataModel, TracDev/Proposals/Journaling and [googlegroups:trac-dev:8cf3f5fe0e476ce5 this mail].
     22The idea is not new, it has its root in the TracObjectModelProposal, and was refined in TracDev/Proposals/DataModel, TracDev/Proposals/Journaling and [googlegroups:trac-dev:8cf3f5fe0e476ce5 this mail].
    2323
    2424As this will be a major redesign of the data model, it could also be a good opportunity to take the **MultipleProjectSupport** considerations into account (#11025).
     
    137137Most 1-to-1 fields will also be indexed, in order to better support queries.
    138138
    139 A note about the cardinality: in case resources have a n-m relationship, the side expected to have the less relations is the one that will come first in the relation table. For example, a project will have many (n) tickets, but a ticket will usually be associated with 1 or perhaps a few (m) projects, and we have n >> m. In this case, the relation table will be `Ticket_Project`. The idea is that when we retrieve information about tickets, we'll want to get the information about their projects, but not necessarily the converse. Another factor to take into account is the //order//. We put an emphasis on keeping track of the order in which the relations are laid out. Sometimes it's not that that important (CC:), sometimes we could take advantage of this information (keywords), special importance for first listed component or version... But it's true that there are situations where the distinction is less clear cut, like for `Ticket_Milestone`, based on the current interface we could say that we seldom consider a milestone without its associated tickets, and we might want to order tickets in a milestone (Scrum-like). Anyway, we'll use the hint given by the "m" cardinality for a start.
     139A note about the cardinality: in case resources have a n-m relationship, the side expected to have the less relations is the one that will come first in the relation table. For example, a project will have many (n) tickets, but a ticket will usually be associated with 1 or perhaps a few (m) projects, and we have n >> m. In this case, the relation table will be `Ticket_Project`. The idea is that when we retrieve information about tickets, we'll want to get the information about their projects, but not necessarily the converse. Another factor to take into account is the //order//. We put an emphasis on keeping track of the order in which the relations are laid out. Sometimes it's not that that important (CC:), sometimes we could take advantage of this information (keywords), special importance for first listed component or version. But it's true that there are situations where the distinction is less clear cut, like for `Ticket_Milestone`, based on the current interface we could say that we seldom consider a milestone without its associated tickets, and we might want to order tickets in a milestone (Scrum-like). Anyway, we'll use the hint given by the "m" cardinality for a start.
    140140
    141141{{{#!sql
     
    263263}}}
    264264
    265 The `<Resource>Change` table is clearly inspired of the existing `ticket_change`: we don't want to replicate all the complexity of the ticket relational model in dedicated versioning tables, because it would be clearly overkill. We're not interested in //querying// these values anyway, only in storing them for displaying them whenever we're going to show the history of the resource.
     265The `<Resource>Change` table is clearly inspired of the existing `ticket_change`: we don't want to replicate all the complexity of the ticket relational model in dedicated versioning tables, because it would be overkill. We're not interested in //querying// these values anyway, only in storing them for display purposes whenever we're going to show the history of the resource.
    266266
    267267The comments are a different story, we're not going to "hide" them in the above, they'll rather behave as secondary (ancillary) resources related to the //events// themselves.
     
    307307At first sight, this seems far more complex than the old model was, but in fact it's above all more explicit, with no "hidden" structure (except for the `oldval`/`newval`). And the regularities in the model means we're going to be able to provide a convenient high-level API for dealing with it.
    308308
    309 In addition, even though the relational information given by the foreign keys can be enlightening for understanding the data model, we'll need an additional descriptive layer, metadata describing the precise relationships between the tables (e.g. list of fields for a given resource/type?).
     309In addition, even though the relational information given by the foreign keys can be enlightening for understanding the data model, we'll need an additional descriptive layer, metadata describing the precise relationships between the tables, for example list of fields for a given resource/type?.
    310310
    311311This metadata is a natural continuation of the configuration of fields one can find in `[ticket-custom]` section of TracIni. Of course this time it is generalized to the "standard" resources and fields, and it is stored in the database. Speaking of custom fields, one can see how custom fields fit in the above approach: they will simply correspond to additional secondary tables. The presence of a field in the primary table or in one secondary table becomes an implementation detail abstracted away by the metadata description of the resource. This will be also used to ease the transition to the new model by first describing the "current" state (all 1-to-1 fields in the primary table) and allowing for progressive upgrade steps.
     
    313313Finally, for the code that would handle the resources in a generic way, instead of dealing with the same tables for every resources (the EAV approach), they would deal with the same API and use the metadata to know how to handle each particular kind of resources.
    314314
    315 By the way, we could also easily graft the idea of ''sub-types'' (cf. TicketTypes) that would use the same primary table as their main type but perhaps a subset (or a slightly different set) of secondary tables (e.g. no 'Version' for tasks).
     315By the way, we could also easily graft the idea of ''sub-types'' (cf. [TracDev/Proposals/TicketTypes TicketTypes]) that would use the same primary table as their main type but perhaps a subset (or a slightly different set) of secondary tables, for example no 'Version' for tasks.
    316316
    317317== Implementation Plan
     
    322322
    323323As the ticket module is by far the most complex, it might be worth to try out the new model there first:
    324  - we could verify that we meet the expectations in terms of code simplification,
    325    solving open issues, etc.
     324 - we could verify that we meet the expectations in terms of code simplification, solving open issues, etc.
    326325 - we could detect early if there are no regressions or risk of losing current features
    327  - by redeploying the ticket infrastructure to the other components,
    328    we could spread the most benefits of tickets (comments,
    329    custom fields, queries, etc.) to other resources (milestone, wiki, component, ...)
     326 - by redeploying the ticket infrastructure to the other components, we could spread the most benefits of tickets (comments, custom fields, queries, etc.) to other resources (milestone, wiki, component)
    330327
    331328=== Applied on new Component and Version resources