Changes between Version 44 and Version 45 of GenericTrac

Timestamp:

Nov 27, 2014, 10:30:51 PM (9 years ago)

Author:

Christian Boos

Comment:

expand on the role of metadata (custom fields, sub-types)

GenericTrac

@@ -17 +17 @@
    in which the storage of changes is quite cumbersome (see #454, #6466)
  - solve a few design problems with the current data model (like #1890, #4582)
- - allow better code reuse and share of the base features 
+ - 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)
@@ -27 +27 @@
 As this will be a major redesign of the data model, 
 it could also be a good opportunity to take the 
-**MultipleProjectSupport** considerations into account (#130).
+**MultipleProjectSupport** considerations into account (#11025).
 
 Somehow related to the generic data model, but not strictly depending on it,
@@ -136 +136 @@
 The new model is heavily relational, as opposed to the earlier EAV-like approach (see [./Brainstorm#EAV]).
 
-We keep a main table for the resource, for all 1-to-1 properties and relations (table named `Ticket` here).
+We keep a ''primary'' table for the resource, for all 1-to-1 properties and relations (table named `Ticket` here).
 
 We now make systematic use of surrogate keys, to allow for efficient relations between resources. That key will however remain hidden, an implementation detail. The visible ID for a ticket either stays the same as before or can even become more flexible (#9624, sub-tickets with dotted notation).
 
-All the properties that may contain multiple values are located in a secondary table (`<Resource>_<[Ff]ield>`) with three columns: `<resource>`, `<field>` and `<seq>` for keeping the multiple values ordered. Note that `<[Ff]ield>` might be either a //property// (`<field>`), the secondary table `<field>` column then contains directly a value, or a //relation// (`<Field>`), in which case the secondary table `<field>` column contains the surrogate key of the related resource.
+All the properties that may contain multiple values are located in ''secondary'' tables (`<Resource>_<[Ff]ield>`) with three columns: `<resource>`, `<field>` and `<seq>` for keeping the multiple values ordered. Note that `<[Ff]ield>` might be either a //property// (`<field>`), the secondary table `<field>` column then contains directly a value, or a //relation// (`<Field>`), in which case the secondary table `<field>` column contains the surrogate key of the related resource.
 
 There's only one multi-valued property left, for the keywords, and all the others 1-m fields become relations:
@@ -309 +309 @@
 }}}
 
-At first sight, this seems far more complex than the old model, 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.
+At 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.
 
 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?).
+
+This 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 DB. 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.
+
+Finally, 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.
+
+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).
 
 
@@ -329 +335 @@
    custom fields, queries, etc.) to other resources (milestone, wiki, component, ...)
 
+=== Applied on new Component and Version resources ===
+
+The not yet existing resource types like 'component' and 'version' will be implemented using this generic approach (#1233). Initially the corresponding fields would remain in the primary  Ticket table, they will be replaced from being properties (`component`, `version`) to relations (`Component`, `Version`). In a second step we could move these fields from the primary Ticket table to new secondary relation tables (`Ticket_Version`) and (`Ticket_Component`), still keeping the 1-to-1 relationship. The last step would be to allow them to be used as multi-valued relations (1 ticket to m versions and components).
 
 === Applied on Milestone module ===
@@ -352 +361 @@
 See how a VCS backend could be written for the versioned generic scheme...
 
-=== Applied on Component module ===
-
-An other possibility would be to start on fresh ground, implementing not yet existing resource typse in a generic way (#1233). That would be the less disrupting approach, as everything else should just continue to work unchanged (or mostly unchanged, except for things like #5211 and places where we deal with the old `component` table).
-
 
 == Related Tickets ==