Changes between Version 36 and Version 37 of GenericTrac

Timestamp:

Aug 3, 2010, 10:25:49 PM (14 years ago)

Author:

Christian Boos

Comment:

a few clean-ups

GenericTrac

@@ -166 +166 @@
 
 For other relations, it can be less clear cut, we have to take sides. For example, concerning the ticket relations:
- - ''**parent**/child'': a child ticket necessarily has a ''parent'' ticket, otherwise it's not a child ticket ; the parent ticket may have one or more children tickets, but it can also exist on its own
- - ''**blocked-by**/is-blocking'': a ticket can be ''blocked-by'' one or more tickets ; the converse relation ''is-blocking'' is less strong
- - ''**duplicate-of**/duplicated-by'': a ticket may be qualified to be a ''duplicate-of'' of another ticket ; that other ticket is ''duplicated-by'' one or many tickets, but this is less strong 
+ - ''**parent**/child'': a child ticket necessarily has a ''parent'' ticket, otherwise it's not a child ticket; the parent ticket may have one or more children tickets, but it can also exist on its own
+ - ''**blocked-by**/is-blocking'': a ticket can be ''blocked-by'' one or more tickets; the converse relation ''is-blocking'' is less strong
+ - ''**duplicate-of**/duplicated-by'': a ticket may be qualified to be a ''duplicate-of'' of another ticket; that other ticket is ''duplicated-by'' one or many tickets, but this is less strong 
 
 ==== History
@@ -180 +180 @@
  - one representing the metadata corresponding to the change, describing the act of creating a new version, i.e. revisioning:  "{resource}_rev", e.g. a `ticket_rev` (or `ticket_revision`?)
 
-||||||||=  '''ticket_version_prop'''  ||
-||= id ||= prop ||= value ||= seq ||
-||||||||=  '''ticket_rev_prop'''  ||
-||= id ||= prop ||= value ||= seq ||
+ ||||||||=  '''ticket_version_prop'''  ||
+ ||= id ||= prop ||= value ||= seq ||
+
+ ||||||||=  '''ticket_rev_prop'''  ||
+ ||= id ||= prop ||= value ||= seq ||
 
 The main resource and the derived resources would be related together:
@@ -190 +191 @@
 
 Typical example:
-||||||||=  '''ticket_prop'''  ||
-|| 1001 || id || 1 || 2021010101 ||
-|| 1001 || lastchange || 101001 ||
-||||||||=  '''ticket_rev_prop'''  ||
-|| 101001 || ticket  || 1001         ||  23232323333 ||
-|| 101001 || auth    || 1            ||  23232323334 ||
-|| 101001 || date    || 123123211422 ||  23232323335 ||
-|| 101001 || version || 202002       ||  23232323336 ||
-||||||||=  '''ticket_rev_prop_int''  ||
-|| 202002 || author  || cboos        ||  23232323337 ||
-|| 202002 || comment || random change ||  23232323338 ||
+ ||||||||=  '''ticket_prop'''  ||
+ || 1001 || id || 1 || 2021010101 ||
+ || 1001 || revision || 101001 ||  2021010102 ||
+
+ ||||||||=  '''ticket_rev_prop'''  ||
+ || 101001 || ticket  || 1001         ||  23232323333 ||
+ || 101001 || auth    || 1            ||  23232323334 ||
+ || 101001 || date    || 123123211422 ||  23232323335 ||
+ || 101001 || version || 202002       ||  23232323336 ||
+
+ ||||||||=  '''ticket_rev_prop_int''  ||
+ || 202002 || author  || cboos        ||  23232323337 ||
+ || 202002 || comment || random change ||  23232323338 || 
 
 A given revision instance (here 101001) is usually related to a specific change in one resource,
@@ -246 +249 @@
    for an instance (i.e. all the records within `{resource}_prop...` 
    tables with the same `id`)
- - an "abstractmodel",  object wrapping a view 
+ - an abstract "model",  object wrapping a view 
    (for keeping around the "old" values), but mutable
- - "model", concrete subclass of the above, which implements loading 
-   by fetching the data from a set of tables following the generic scheme
+ - "sqlmodel", concrete subclass of the above, which implements loading 
+   by fetching the data from the database, in a set of tables following 
+   the generic scheme
 
 Note that `view`s could eventually be cached, somehow (need to think carefully about how to do cross-process invalidation, though; there's certainly a way on top of the CacheManager).
 
+If most of the code deals with the "model", the SQL details can be abstracted away, 
+facilitating eventual adaptation to other backends (e.g. "nosqlmodel").
+
 === Applied on Milestone module ===
+
  - modify the Milestone module so that it uses the new proposed datamodel.
- - experiment new tabbed view for the milestone (''View'', ''Discussion'', ''History''). See TracProject/UiGuidelines.
- - milestone should be able to have attachments, too (#3068)
  - adapt the Roadmap module to the new model
  - adapt the Milestone admin component to the new model
-
-Once this is complete, validate the genericity by promoting the components to be first class resources as well (#1233).
+ - for a first approach, the generic scheme would be enough, 
+   no need for versioning as we currently don't support that 
+
+Later:
+ - experiment new tabbed view for the milestone (''View'', ''Discussion'', ''History''). See TracProject/UiGuidelines.
+ - migrate to generic versioned scheme
 
 === Applied on Ticket module ===
@@ -281 +291 @@
 If we do this, we can also at the same time think about the storage model, in particular how past versions could be stored in a VCS (#1132). We could then think about a serialization model that would play nicely with the genericity of the Trac resources on one hand side, and with the external editors on the other hand.
 
+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. 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).
+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).