Changes between Version 31 and Version 32 of GenericTrac

Timestamp:

Aug 3, 2010, 6:38:10 PM (14 years ago)

Author:

Christian Boos

Comment:

reusing the #generic-scheme for the #History …

GenericTrac

@@ -95 +95 @@
 So for example the new model could be simply:
 
- ||||||||=     '''ticket'''       =||
+ ||||||||=     '''ticket_prop''    ||
  ||= id ||= prop ||= value ||= seq ||
 
@@ -113 +113 @@
 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.
 
-==== The Generic Scheme
+==== The Generic Scheme #generic-scheme
 Actually, for achieving requirement 3. & 4., we need specialized tables, 
 one for each different value column type we want to support:
@@ -167 +167 @@
  - ''**duplicate-of**/duplicated-by'': a ticket may be qualified to be a ''duplicate-of'' of another ticket ; that other ticket is ''duplicated-by'' one or many tickets, but this is less strong 
 
-
-=== Resource History ===
+==== History
 
 We need to differentiate between the changes to the data, and the metadata about the change. The metadata is about who did the change, when, why the change was made, etc.
@@ -174 +173 @@
 store arbitrary key/value pairs of "revision properties".
 
-'''resource_revprop'''
-|| ''changeid'' || ''revprop'' || ''value'' ||
+For implementing a simple db backed VCS, we can even adopt the same [#generic-scheme generic scheme] as described above, but for two derived resource:
+ - one for snapshotting the resource properties at a given point in time "{resource}_version", e.g. `ticket_version`
+ - one representing the metadata corresponding to the change, describing the act of creating a new version, i.e. revisioning:  "{resource}_rev", e.g. a `ticket_rev` (or `ticket_revision`?)
+
+||||||||=  '''ticket_version_prop'''  ||
+||= id ||= prop ||= value ||= seq ||
+||||||||=  '''ticket_rev_prop'''  ||
+||= id ||= prop ||= value ||= seq ||
+
+The main resource and the derived resources would be related together:
+ - the main resource would point to the lastchange (shortcut, this could be deduced by inspecting the ''date'' stored in the _rev_prop table - so in a "normalized" schema we wouldn't need it)
+ - a revision resource would point to the corresponding version which was created at the same time (again, matching with the ''date'' would be possible?)
 
 Typical example:
-|| 101001 || author  || cboos         ||
-|| 101001 || auth    || 1             ||
-|| 101001 || date    || 1231232114.12 ||
-|| 101001 || comment || random change ||
-
-A given ''changeid'' is usually related to a specific change in one resource,
+||||||||=  '''ticket_prop'''  ||
+|| 1001 || id || 1 || 2021010101 ||
+|| 1001 || lastchange || 101001 ||
+||||||||=  '''ticket_rev_prop'''  ||
+|| 101001 || ticket  || 1001         ||  23232323333 ||
+|| 101001 || auth    || 1            ||  23232323334 ||
+|| 101001 || date    || 123123211422 ||  23232323335 ||
+|| 101001 || version || 202002       ||  23232323336 ||
+||||||||=  '''ticket_rev_prop_int''  ||
+|| 202002 || author  || cboos        ||  23232323337 ||
+|| 202002 || comment || random change ||  23232323338 ||
+
+A given revision instance (here 101001) is usually related to a specific change in one resource,
 but there could be other situations:
  - one change affecting lots of resources (typically #4582 and #5658, ticket batch changes #525)
  - changes affecting changes (typically #454); now that we have completed #454, it would be interesting to see what constraints this impose on the new model
 
+Here we see that one change can easily cover multiple tickets, useful for storing metadata related to batch changes, via different sequence numbers for the ''ticket'' property, and a corresponding sequence of ''version'' property.
 
 The property changes themselves are stored in other tables.
-We only need the changed properties here, no need to store the old/new values
-for each change, as this can be deduced from the past changes.
-Deletions of fields should be represented by setting a field to the NULL value.
-
-Several possibilities here:
-
-'''ticket_change'''
-||= id ||= changeid ||= prop ||= value ||= seq ||
-
-'''milestone_change'''
-||= id ||= changeid ||= prop ||= value ||= seq ||
-
-or:
-
-'''resource_change'''
-||= id ||= changeid ||= prop ||= value ||= seq ||
-(surrogate key approach)
-
-The latter has the advantage that it would make easy to relate a given ``changeid``
-to the resource(s) that were affected by the change, without having to go through
-each resource table.
-
-We could also keep all property changes as text values
-or have extra `..._int` (`..._float`) tables for more compact 
-representation.
-
-See also ticket:6466#comment:10 and follow-ups for a discussion about how ticket changes and in particular ticket change edits, could be handled using this approach.
+We only need the properties that have changed here, no need to store the old/new values for each change, as this can be deduced from the past changes. No need to store the properties which haven't changed either (requirement 4.).
+Deletions of fields could be represented by setting a field to the NULL value.
+
+
+See also ticket:6466#comment:10 and follow-ups for a discussion about how ticket changes and in particular ticket change edits, could be handled using this approach //(not sure if this still applies, though)//.