Changes between Version 28 and Version 29 of GenericTrac

Timestamp:

Aug 3, 2010, 9:16:04 AM (14 years ago)

Author:

Christian Boos

Comment:

some rewording, fix links

GenericTrac

@@ -41 +41 @@
  1. it has to be ''simple'';
  2. it must be ''flexible'', in order to accommodate different kinds of resources and   
-    allow for dynamic evolution;
- 3. it should remain ''fast'', if not faster than what we currently have;
+    allow for dynamic evolution, like addition or removal of fields by plugin or via the web admin;
+ 3. it should remain ''fast'', if not become faster than what we currently have;
  4. it should lead to a more ''compact'' representation of data
  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]). Also, as said above, the versioning of resources could be delegated to a version control backend.
+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 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.
+so we could use it as a basis to lay out the foundations of the new model.
 
 For ticket, we currently have a fixed set of properties
@@ -76 +76 @@
 (?) means ''yet to be verified''
 
-In order to reduce the overall complexity, the idea would be to pick only one approach, instead of having to support both.
+In order to reduce the overall complexity, the idea is to pick only one approach, instead of having to support both.
 By using the second style, we could also have our "fixed" set of properties, 
 while obviously the first style can't support the second.
@@ -87 +87 @@
 The second style (prop/value) can be implemented in several ways: 
  - a single `properties` table with `prop` and `value` string columns (this is what our current `ticket_custom`, `system` and `repository` tables do)
- - a single `properties` table with `prop` and several typed columns (`int_value`, `string_value`, `date_value`, etc.), only the appropriate column being used - see discussion [#JBPM-approach below]
+ - a single `properties` table with `prop` and several typed columns (`int_value`, `string_value`, `date_value`, etc.), only the appropriate column being used - see discussion ([[./Brainstorm#JBPM-approach|JBPM's approach]])
  - several `properties` tables with each `prop` and `value` columns, each table dedicated to a given type (`int_properties`, `string_properties`, etc.)
  - ... more ...