Changes between Version 41 and Version 42 of GenericTrac

Timestamp:

Nov 26, 2014, 12:09:22 AM (9 years ago)

Author:

Christian Boos

Comment:

focusing on the ticket mode, presenting the #legacy model

GenericTrac

@@ -48 +48 @@
 Note that the persistence constraints imposed by the Trac data model are not necessarily only (or even best) approached using the RelationalModel, one could imagine that a future version could use more document-oriented persistence layers (e.g. [http://www.mongodb.org/ MongoDB]), or object-oriented databases (e.g. [http://www.zodb.org/ ZODB]). Also, as said above, the versioning of resources should be delegated to a version control backend, with a default, simple, in-database VCS backend.
 
-=== Resource Content ===
+=== The ticket data model ===
 
 The ticket model is by far richer data model we would have to support, 
 so we could use it as a basis to lay out the foundations of the new model.
 
+==== Trac =< 1.1.3 model #legacy
 For ticket, we currently have a fixed set of properties
 (as columns in the `ticket` table)
@@ -60 +61 @@
 Note that we'd like to get ''relations'' (or ''links'') as well, see #31.
 
-==== Properties
 Let's examine the advantages and disadvantages of each different styles of properties storage:
  1. properties stored in columns of a main table:
@@ -79 +79 @@
 
 (?) means ''yet to be verified''
+
+The current ticket tables look like this (`.schema ticket` and `.schema ticket_custom` in SQLite):
+{{{
+CREATE TABLE ticket (
+        id              integer PRIMARY KEY,
+        type            text,           -- the nature of the ticket
+        time            integer,        -- the time it was created
+        changetime      integer,
+        component       text,
+        severity        text,
+        priority        text,
+        owner           text,           -- who is this ticket assigned to
+        reporter        text,
+        cc              text,           -- email addresses to notify
+        version         text,           --
+        milestone       text,           --
+        status          text,
+        resolution      text,
+        summary         text,           -- one-line summary
+        description     text,           -- problem description (long)
+        keywords        text
+);
+
+CREATE TABLE ticket_custom (
+       ticket               integer,
+       name             text,
+       value            text,
+       UNIQUE(ticket,name)
+);
+}}}
+
+Such a flat table makes it hard to get 1-n associations, or this has to be faked somehow (cf. the cc and keywords).
+
+And for the "versioning" of ticket changes, we have (`.schema ticket_change`):
+{{{
+CREATE TABLE ticket_change (
+    ticket integer,
+    time integer,
+    author text,
+    field text,
+    oldvalue text,
+    newvalue text,
+    UNIQUE (ticket,time,field)
+);
+}}}
+
+Squeezed in the above are the ticket comments, complete with "reply-to" information and their own versioning scheme ;-)