Edgewall Software

Changes between Version 29 and Version 30 of GenericTrac


Ignore:
Timestamp:
Aug 3, 2010, 10:59:01 AM (14 years ago)
Author:
Christian Boos
Comment:

"generic scheme" and moved the metadata example to the Brainstorm page

Legend:

Unmodified
Added
Removed
Modified

  • GenericTrac

    v29 v30  
    9494So for example the new model could be simply:
    9595
    96 '''ticket'''
    97 ||= id ||= prop ||= value ||= seq ||
     96 ||||||||=     '''ticket'''       =||
     97 ||= id ||= prop ||= value ||= seq ||
    9898
    9999//seq// is the sequence number in case of multiple entries with the same property name.
    100100
    101 or even:
    102 
    103 '''resource_prop'''
    104 ||= realm ||= id ||= prop ||= value ||= seq ||
    105 (if we use one mega table for all resources)
    106 
    107 
    108 
    109 Note by the way that newer "resources", like `repository` in MultiRepos already have this `(id,prop/value)` form.
     101Note by the way that newer "resources", like `repository` in MultiRepos already have this `(id,prop,value)` form, we'd only have to add `seq`.
     102
    110103
    111104We could also keep the metadata associated to the properties in the database,
    … …  
    113106unification of the representation for fixed fields and custom fields.
    114107
    115 '''resource_schema'''
    116 ||= realm ||= prop ||= metaprop ||= value ||
    117 
    118 Here, possible content for ''prop'' could be 'label', 'default', 'order', 'type', etc.
    119 
    120 Example:
    121 || ticket || description || type || wiki ||
    122 || ticket || priority || type || enum ||
    123 || ticket || priority || enum || priority ||
    124 || ticket || priority || default || normal ||
    125 || ticket || need_review || type || checkbox ||
    126 || ticket || need_review || default || 0 ||
    127108
    128109Note: the existence of a schema describing the fields doesn't mean that modules
    … …  
    131112Furthermore, 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.
    132113
    133 As a possible refining, it could be possible to have specialized tables,
     114
     115Actually, for achieving requirement 3. & 4., we need specialized tables,
    134116one for each different value column type we want to support:
    135  - '''resource_prop''' for text values
    136  - '''resource_prop_int''' for integer values
    137  - ('''resource_prop_float''' for float values, if really needed)
     117 - '''{resource}_prop''' for text values
     118 - '''{resource}_prop_int''' for integer values, identifiers and dates (using "bigint")
     119 - ('''{resource}_prop_float''' for float values, if really needed)
    138120And we could even differentiate between short and long text values (requirement 4):
    139  - '''resource_prop''' for short text values
    140  - '''resource_prop_text''' for long text values
     121 - '''{resource}_prop''' for short text values
     122 - '''{resource}_prop_text''' for long text values
    141123(see #6986).
    142124
     125This 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...
    143126
    144127Along the same lines there's also the question of what should be the ''id'':
    … …  
    157140   - renaming is easy (relations are preserved)
    158141
    159 
    160 This all suggests that using surrogate keys would be preferable, with a single  '''resource_prop''' table.
     142This all suggests that using surrogate keys would be preferable.
    161143
    162144If this is the case, the '''resource_prop''' table could as well become simply:
    … …  
    224206
    225207See 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.
     208
    226209
    227210