Changes between Version 39 and Version 40 of GenericTrac

Timestamp:

Jun 12, 2011, 1:23:51 PM (13 years ago)

Author:

Christian Boos

Comment:

minor clean-ups for the first part

GenericTrac

@@ -18 +18 @@
  - solve a few design problems with the current data model (like #1890, #4582)
  - allow better code reuse and share of the base features 
-   among different kinds of resources (like #695, #1113, etc.
-   see [#RelatedTickets] for more)
+   among different kinds of resources (like #695, #1113, and a lot more, 
+   see [#RelatedTickets] below)
 
 == Related Proposals ==
@@ -40 +40 @@
 
 Requirements for the new model:
- 1. it has to be ''simple'';
- 2. it must be ''flexible'', in order to accommodate different kinds of resources and   
-    allow for dynamic evolution, like addition or removal of fields by plugin or via the web admin;
+ 1. it has to be ''simple'' (//easy to understand, easy to code with, when looking at the raw data in the database one should be able to intuitively understand what it means//)
+ 2. it must be ''flexible'' ((//accommodate different kinds of resources, 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
@@ -62 +61 @@
 
 ==== Properties
-Let's examine the advantages and disadvantages of each different kind of storage, for the properties:
+Let's examine the advantages and disadvantages of each different styles of properties storage:
  1. properties stored in columns of a main table:
    - (-) only flexibility is to not use some fields (e.g. 'severity', 'url') 
@@ -82 +81 @@
 
 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.
-
-It remains to be seen whether the second approach is really less efficient than the first, but this doesn't really matter as we anyway have already to pay the 
-price for that flexibility.
-Note also that by an appropriate use of indexes, we might eventually get 
-''better'' performance compared to what we have today.
+The main argument in favor of a change is that currently (for the `ticket` resources) we //already// implement both styles. The point is that by using //only// the second style (but maybe in a more efficient way), we could also have our "fixed" set of properties, while obviously the opposite is not true, the first style can't provide the flexibility provided by the second style.
+
+And it remains to be seen whether the second approach is really less efficient than the first, as by an appropriate use of indexes we might eventually get ''better'' performance than what we have today.
 
 The second style (prop/value) can be implemented in several ways: