http://localhost/ticket/1077 <p> Have developed a new "changeset" based model for revisioning in vdm. This has several advantages: </p> <ul><li>Much simpler </li><li>Cleaner separation of continuity from changesets <ul><li>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). </li></ul></li><li>Easier support for pending state and similar behaviour </li><li>No need to introduce new tables (and hence migrations) when making something revisioned (or not). </li><li>Almost identical API </li></ul><h2 id="PossibleDisadvantages">Possible Disadvantages</h2> <ul><li>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. <ul><li>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 <ul><li>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. </li></ul></li></ul></li></ul><ul><li>Does not give us anything extra if we simplify our use of vdm currently. (see alternative below) <ul><li>RP: not quite true. E.g. pending support and API. <ul><li>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. </li></ul></li></ul></li></ul><ul><li>A large change to database structure needs to happen. </li></ul><h2 id="Implementation">Implementation</h2> <ul><li>The main challenge with this change is schema and data migration </li></ul><h3 id="Migration">Migration</h3> <p> Every revisioned object has a revision_id and revision attribute. </p> <p> Approximate algorithm: </p> <pre class="wiki">Revision -&gt; Changeset for revtype in [PackageRevision, ...]: for pkgrev in package_revision: changeset = lookupchangeset(package_revision) ChangeObject(cset, (table, id), dictize(pkgrev)) </pre><p> Question: </p> <ul><li>does pkg include tags attributes or not? or we have to dictize, pkgrev, pkg2tagrev, and tag. Probably the latter. </li></ul><h2 id="Alternative">Alternative</h2> <p> 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. </p> en-us http://assets.okfn.org/p/ckan/img/ckan_logo_shortname.png http://localhost/ticket/1077 Trac 0.12.3 rgrp Mon, 18 Apr 2011 11:36:41 GMT http://localhost/ticket/1077#comment:1 http://localhost/ticket/1077#comment:1 <ul> <li><strong>priority</strong> changed from <em>awaiting triage</em> to <em>critical</em> </li> <li><strong>description</strong> modified (<a href="/ticket/1077?action=diff&amp;version=1">diff</a>) </li> </ul> Ticket kindly Mon, 02 May 2011 11:01:19 GMT http://localhost/ticket/1077#comment:2 http://localhost/ticket/1077#comment:2 <ul> <li><strong>description</strong> modified (<a href="/ticket/1077?action=diff&amp;version=2">diff</a>) </li> </ul> Ticket rgrp Sun, 08 May 2011 12:24:53 GMT http://localhost/ticket/1077#comment:3 http://localhost/ticket/1077#comment:3 <ul> <li><strong>state</strong> set to <em>draft</em> </li> <li><strong>description</strong> modified (<a href="/ticket/1077?action=diff&amp;version=3">diff</a>) </li> </ul> Ticket kindly Sun, 08 May 2011 18:58:07 GMT http://localhost/ticket/1077#comment:4 http://localhost/ticket/1077#comment:4 <ul> <li><strong>description</strong> modified (<a href="/ticket/1077?action=diff&amp;version=4">diff</a>) </li> </ul> Ticket rgrp Thu, 12 May 2011 14:57:51 GMT http://localhost/ticket/1077#comment:5 http://localhost/ticket/1077#comment:5 <ul> <li><strong>description</strong> modified (<a href="/ticket/1077?action=diff&amp;version=5">diff</a>) </li> <li><strong>summary</strong> changed from <em>Switch to new vdm changeset model</em> to <em>Move to simpler vdm system</em> </li> </ul> Ticket shevski Fri, 08 Jul 2011 11:56:54 GMT http://localhost/ticket/1077#comment:6 http://localhost/ticket/1077#comment:6 <ul> <li><strong>milestone</strong> <em>ckan-v1.5</em> deleted </li> </ul> Ticket dread Fri, 28 Oct 2011 10:21:24 GMT http://localhost/ticket/1077#comment:7 http://localhost/ticket/1077#comment:7 <ul> <li><strong>priority</strong> changed from <em>critical</em> to <em>awaiting triage</em> </li> </ul> <p> I guess this is not a priority now. </p> Ticket kindly Mon, 18 Jun 2012 15:45:45 GMT http://localhost/ticket/1077#comment:8 http://localhost/ticket/1077#comment:8 <ul> <li><strong>milestone</strong> set to <em>ckan-backlog</em> </li> </ul> Ticket