Changes between Version 2 and Version 3 of Ticket #1077


Ignore:
Timestamp:
05/08/11 12:24:53 (3 years ago)
Author:
rgrp
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1077

    • Property State changed from to draft

  • Ticket #1077 – Description

    v2 v3  
    55  * 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). 
    66 * Easier support for pending state and similar behaviour 
     7 * No need to introduce new tables (and hence migrations) when making something revisioned (or not). 
    78 * Almost identical API 
    89 
    9 Disadvantages: 
     10== Possible Disadvantages == 
    1011 
    1112 * 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. 
    1214 
    1315 * Does not give us anything extra if we simplify our use of vdm currently. (see alternative below) 
     16  * RP: not quite true. E.g. pending support and API. 
    1417 
    1518 * A large change to database structure needs to happen.