Changes between Version 35 and Version 36 of GenericTrac

Timestamp:

Aug 3, 2010, 7:45:56 PM (14 years ago)

Author:

Christian Boos

Comment:

#Base: some implementation notes

GenericTrac

@@ -221 +221 @@
 == Possible Implementation Plan ==
 
-=== Milestone First ===
+=== Base 
+
+The model is relatively simple to implement.
+
+There will be a few generic utility functions for creating a set tables for the "generic scheme", and one for versioned resource:
+{{{
+#!python
+  def create_resource_tables(env, resource):
+     """Create resource_prop, _prop_string and _prop_text tables."""
+     ...
+
+  def create_versioned_resource_tables(env, resource):
+     """Create a generic scheme for resource plus related ancillary
+     versioning resource (_rev and _version)"""
+         with env.db_transaction():
+             for r in (resource, 
+                       resource + "_rev", 
+                       resource + "_version"):
+                 create_generic_scheme(r)
+}}}
+
+On the model level, we could create a few utility classes:
+ - a "view" (read-only dictionary), which will contain the current values
+   for an instance (i.e. all the records within `{resource}_prop...` 
+   tables with the same `id`)
+ - an "abstractmodel",  object wrapping a view 
+   (for keeping around the "old" values), but mutable
+ - "model", concrete subclass of the above, which implements loading 
+   by fetching the data from a set of tables following the generic scheme
+
+Note that `view`s could eventually be cached, somehow (need to think carefully about how to do cross-process invalidation, though; there's certainly a way on top of the CacheManager).
+
+=== Applied on Milestone module ===
  - modify the Milestone module so that it uses the new proposed datamodel.
  - experiment new tabbed view for the milestone (''View'', ''Discussion'', ''History''). See TracProject/UiGuidelines.
@@ -230 +262 @@
 Once this is complete, validate the genericity by promoting the components to be first class resources as well (#1233).
 
-=== Ticket First ===
+=== Applied on Ticket module ===
 
 As the ticket module is by far the most complex, it might be worth to
@@ -241 +273 @@
    custom fields, queries, etc.) to other resources (milestone, wiki, component, ...)
 
-=== Wiki First ===
+=== Applied on Wiki module  ===
 
 Milestone and components are closer in spirit to a wiki page than to a ticket (we have the long standing #3776 ticket).
@@ -249 +281 @@
 If we do this, we can also at the same time think about the storage model, in particular how past versions could be stored in a VCS (#1132). We could then think about a serialization model that would play nicely with the genericity of the Trac resources on one hand side, and with the external editors on the other hand.
 
-=== Component First ===
+=== Applied on Component module ===
 
 An other possibility would be to start on fresh ground, implementing not yet existing resource typse in a generic way. That would be the less disrupting approach, as everything else should just continue to work unchanged (or mostly unchanged, except for things like #5211 and places where we deal with the old `component` table).