Changes between Version 26 and Version 27 of GenericTrac

Timestamp:

Aug 2, 2010, 4:10:02 PM (14 years ago)

Author:

Christian Boos

Comment:

a few more notes (versioning backends, #31, …)

GenericTrac

@@ -3 +3 @@
 This page defines a new data model for Trac that should be suitable
 for storing most of the data from resources, along with their change history.
+
+In the longer term, it would be more appropriate to keep the change history in a dedicated system (a version control backend, even a [DistributedTrac distributed] one).
+In that picture, we could even provide a simple "dbvcs" backend, which would use the database for storing the change history much like we do now.
 
 The main benefits expected from the new model are:
@@ -30 +33 @@
 This could allow the (re-)implementation of the TracCrossReferences idea
 as a plugin, for example.
-See #6543 and TracDev/Proposals/TracRelations.
+See #31, #886, #6543 and TracDev/Proposals/TracRelations.
 
 
@@ -43 +46 @@
  5. all the existing constraints about maintaining resource history and associated metadata should be taken into account
 
-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]). Alternatively, the versioning of resources could be delegated to a version control backend, and even a [DistributedTrac distributed] one.
+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 could be delegated to a version control backend.
 
 === Resource Content ===
@@ -49 +52 @@
 The ticket model is by far richer data model we would have to support, 
 so we could take this as a basis to lay out the foundations of the new model.
+
 For ticket, we currently have a fixed set of properties
 (as columns in the `ticket` table)
@@ -54 +58 @@
 (as prop/value columns in a `ticket_custom` table).
 
-Both styles have advantages and disadvantages:
- 1. properties as columns:
+Note that we might soon get ''relations'' (or ''links'') as well, see #31.
+
+Let's examine the advantages and disadvantages of each different kind of storage, for the properties:
+ 1. properties stored in columns of a main table:
    - (-) only flexibility is to not use some fields (e.g. 'severity', 'url') 
    - (-) no multiple values per field possible  
-   - (+) faster (?)
+   - (+) faster especially for multicriteria queries (?) 
    - (+) straightforward code (`for field1,field2, ... in cursor: ...`) (?)
- 2. properties in prop/value columns
+ 2. properties stored in prop/value columns of a generic table
    - (+) highest flexibility, add or remove fields at will
    - (+) allow for multiple values per property, provided we don't use a primary key
@@ -66 +72 @@
      - (+) a slight extension would allow ordered multiple values (sequences), otherwise we have no control over the order in which those multiple values are retrieved, which might introduce confusion as this order will vary when new values are added;
        while primarily useful for `int` fields, this could also be useful to implement `text` fields for Oracle (working around the limits on varchars and not having to use CLOBs)
-   - (-) slower, less memory efficient (?)
+   - (-) slower, less memory efficient, especially for multicriteria queries(?)
    - (-) more complex code (?)
 (?) means ''yet to be verified''