Changes between Version 11 and Version 12 of GenericTrac

Timestamp:

Sep 4, 2009, 2:54:31 PM (15 years ago)

Author:

Christian Boos

Comment:

rewording of the intro and other minor edits

GenericTrac

@@ -1 +1 @@
 = GenericTrac Data Model = 
 
-This page attempts to define a new data model for Trac that could be suitable
-for most of its resources. The main benefits expected from the new model are:
+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.
+
+The main benefits expected from the new model are:
  - simplification of the internals of Trac, especially for the ticket model,
    in which the storage of changes is quite cumbersome (see #454, #6466)
  - 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 (numerous examples for that, 
-   see [#RelatedTickets] below)
+   among different kinds of resources (like #695, #1113, etc.
+   see [#RelatedTickets] for more)
 
 This stems from the following former proposals:
@@ -20 +22 @@
 it could also be a good opportunity to take the 
 ''[TracMultipleProjects multiple project]'' considerations into account (#130).
-Each resource related table could get a `project` identifier field.
-
-Working on the generic aspect of Trac should also make it possible to implement various ''generic'' operations on Trac resources as plugins, mainly being able to (re-)implement TracCrossReferences as a plugin (see also #6543).
+
+Somehow related to the generic data model, but not strictly depending on it,
+Trac should also make it possible to implement new kinds of plugins that would
+perform ''generic'' operations on Trac resources.
+This could allow the (re-)implementation of the TracCrossReferences idea
+as a plugin, for example.
+See #6543 and TracDev/Proposals/TracRelations.
 
 
@@ -60 +66 @@
 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.
+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.
 
 So the new model could be simply:
@@ -96 +104 @@
 can't interpret fields as being special. Quite the opposite, as modules are what
 provides the real "behavior" of resources.
+Furthermore, properties not defined in the schema could simply be ignored, so this would allow a great deal of flexibility for plugins when they need to store "special" properties or revision properties.
 
 As a possible refining, it could be possible to have specialized tables,