[ckan-dev] moderated edits c(r)ep. http://trac.ckan.org/ticket/1129

Fri May 13 14:39:05 UTC 2011

After scanning through a book called "Temporal Data and The Relational
Model" I think I have come to another conclusion as to how our revisioning
system should work.

I think we should still have the revision tables but each one should have an
extra column expired_id.   This will be the revision_id of the next change
that happens to the object.  This column will be null if the object is
active or if a pending revision has not been discarded or approved.

* The continuity object should have an expired_id too and it should only be
filled if the object is deleted.
* The continuity object would be the active one.
* There should only be 2 states in this model, 'pending' and 'active' and
this state should *just* be in the revision tables.
* There would only be at most 1 non null revision_id_expired per entity in
the revision table with state 'active'.  This will be the one in the
continuity table.
* There could be many non null expired_id for state 'pending' in the
revision tables.
* When a pending revision is approved/rejected an end date is added to it.
* When deleting something a new revision will be made and it adds the
expired_id to the revision_object and continuity.

This model I am very happy with and it makes querying the revision tables
easier and faster as you would just filter by date ranges. I am not sure
what the implications to vdm are though.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20110513/2e581d7d/attachment-0001.html>