Changes between Version 34 and Version 35 of GenericTrac

Timestamp:

Aug 3, 2010, 7:24:11 PM (14 years ago)

Author:

Christian Boos

Comment:

some fine tuning after updating the example

GenericTrac

@@ -17 +17 @@
 == Related Proposals ==
 
-The idea is not new, it has its root in the TracObjectModelProposal, and was refined several times (TracDev/Proposals/DataModel, TracDev/Proposals/Journaling, see also [googlegroups:trac-dev:8cf3f5fe0e476ce5 this mail).
+The idea is not new, it has its root in the TracObjectModelProposal, and was refined several times (TracDev/Proposals/DataModel, TracDev/Proposals/Journaling, and [googlegroups:trac-dev:8cf3f5fe0e476ce5 this mail]).
 
 As this will be a major redesign of the data model, 
@@ -83 +83 @@
 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 ([[./Brainstorm#JBPM-approach|JBPM's approach]])
+ - a single `properties` table with `prop` and several typed columns (`int_value`, `string_value`, `date_value`, etc.), only the appropriate column being used (see in the discussion, the [[./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 ...
@@ -113 +113 @@
 Actually, for achieving requirement 3. & 4., we need specialized tables, 
 one for each different value column type we want to support:
- - '''{resource}_prop''' for text values
- - '''{resource}_prop_int''' for integer values, identifiers and dates (using "bigint")
+ - '''{resource}_prop''' for integer values, identifiers and dates (which are already stored using "bigint")
  - ('''{resource}_prop_float''' for float values, if really needed)
 And we could even differentiate between short and long text values (requirement 4):
- - '''{resource}_prop''' for short text values 
+ - '''{resource}_prop_string''' for short text values 
  - '''{resource}_prop_text''' for long text values
-(see #6986).
+See #6986, it will make a difference for MySQL, and I suppose it will matter for Oracle support also.
 
 This set of tables is a "generic scheme" that can be easily created for any kind of "resource". There's also a trade-off here, between using one very generic set of "resource_..." table versus special instances like "ticket_...": having one set of tables presents the risk of introducing too much contention for backends using table locking, and leads to writing queries that will contain lots of difficult to joins. We will already have enough issues with this when writing multicriteria search queries...
@@ -187 +186 @@
 
 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?)
+ - the main resource would point to the last ''revision'' (shortcut, this could be deduced by inspecting the ''date'' stored in the corresponding `_rev_prop` table - so in a "normalized" schema we wouldn't need it)
+ - a ''version'' resource would point to the corresponding ''revision'' which was created at the same time (again, matching with the ''date'' would be possible? better use an explicit ''revision'' property, though)
 
 Typical example:
@@ -260 +259 @@
  - Resource related: [[TicketQuery(status=!closed&keywords=~tracobject)]]
 
-
+See also: [./Brainstorm] for examples and "test" of the ideas, and discussion.
+