Changes between Version 1 and Version 2 of Ticket #1077


Ignore:
Timestamp:
05/02/11 11:01:19 (3 years ago)
Author:
kindly
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1077 – Description

    v1 v2  
    66 * Easier support for pending state and similar behaviour 
    77 * Almost identical API 
     8 
     9Disadvantages: 
     10 
     11 * 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. 
     12 
     13 * Does not give us anything extra if we simplify our use of vdm currently. (see alternative below) 
     14 
     15 * A large change to database structure needs to happen. 
    816 
    917== Implementation == 
    … …  
    2836Question: 
    2937   * does pkg include tags attributes or not? or we have to dictize, pkgrev, pkg2tagrev, and tag. Probably the latter. 
     38 
     39== Alternative == 
     40 
     41Instead 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.