Changes between Version 4 and Version 5 of Ticket #1077


Ignore:
Timestamp:
05/12/11 14:57:51 (3 years ago)
Author:
rgrp
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1077

    • Property Summary changed from Switch to new vdm changeset model to Move to simpler vdm system

  • Ticket #1077 – Description

    v4 v5  
    1 Have developed a new "changeset" based model for revisioning in vdm. This has several advantages: 
     1== Option 1: 'Changeset' Model == 
    22 
    3  * Much simpler 
    4  * Cleaner separation of continuity from changesets 
    5   * Supports certain operations that are impossible now (e.g. deleting all changes to a particular object irrespective of whether other objects were changed in same revisions). 
    6  * Easier support for pending state and similar behaviour 
    7  * No need to introduce new tables (and hence migrations) when making something revisioned (or not). 
    8  * Almost identical API 
     3See ticket:1135 for vdm ticket. This would involve a) moving to changeset in vdm b) doing the migration in ckan to support this. 
    94 
    10 == Possible Disadvantages == 
     5Have developed a new "changeset" based model for revisioning in vdm.  
    116 
    12  * Difficult to query revision history. Currently we have a way of finding out the diffs of particular packages.  These diffs *include* changes to objects associated with packages (i.e a resource attached to a package).  With the new model the only way to get this information is by looking in the json stored in the change object which is very awkward. 
    13   * RP: not sure this is true. You can query on object id very easily in the changeset model. Possible complication here is working out what objects are associated to say a package (e.g. have to look up ids of package_tags) but this does not seem more problematic than what you would do in other model to achieve the same ends.s  
    14     * DR: In looking for related objects we do joins between revision tables and the main tables.  For example we join the package_extras_revision table to the package table.  We could not do this with the new model as we would need to look into change object table dict for the join, which is painful.  Also the object_ids are tuples as the moment which is difficult to join on. 
    157 
    16  * Does not give us anything extra if we simplify our use of vdm currently. (see alternative below) 
    17   * RP: not quite true. E.g. pending support and API. 
    18    * DR: pending support would be there if we did not use any stateful lists/dicts and use vdm as a copy on write only with revision_id only.  I do not know what you mean by api. 
    19  
    20  * A large change to database structure needs to happen. 
    21  
    22 == Implementation == 
     8=== Implementation === 
    239 
    2410 * The main challenge with this change is schema and data migration 
    25  
    26 === Migration === 
    2711 
    2812Every revisioned object has a revision_id and revision attribute. 
    … …  
    4226   * does pkg include tags attributes or not? or we have to dictize, pkgrev, pkg2tagrev, and tag. Probably the latter. 
    4327 
    44 == Alternative == 
     28== Option 2: Simplify Revision Object Model == 
    4529 
    46 Instead of restructuring the whole of the database to fit the new changeset model just simplifying our use of the current vdm by removing stateful list/dicts and handling this state ourselves in the logic layer could be adequate. The vdm would then be just a simple copy on write mechanism at the table level.  This seems to cover all advantages/disadvantages above. 
     30Just use a simpler vdm, see ticket:1136 (move to !SessionExtension) and ticket:1137 (remove need for statefulness in vdm). 
     31 
     32== Discussion == 
     33 
     34Advantage of Option 1 versus 2: 
     35 
     36 * Easier support for pending state and similar behaviour 
     37 * No need to introduce new tables (and hence migrations) when making something revisioned (or not). 
     38 
     39=== Disadvantages === 
     40 
     41 * Migration is required 
     42 * More difficult to query revision history. 
     43  * Could be addressed by having !ChangeObject have separate cols for table name and id but would likely be more difficult. 
     44 * Performance (?) 
     45  * Have one big !ChangeObject table to query when looking at changed objects rather than many revision tables. 
     46   * Not sure this is a biggie as even with Revision model biggest revision object tables are probably on the order of the !ChangeObject table 
     47 
     48== Conclusion == 
     49 
     50Implement Option 2 and leave Option 1 for present. 
     51 
     52Option 1 includes Option 2 so it seems that that is required in either case (so we may as well with Option 2). 
     53 
     54Option 1 requires significant effort (esp migration) so leave for present and then review the situation at some later date.