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

[David Raznick]

On Fri, May 13, 2011 at 3:39 PM, David Raznick <kindly at gmail.com> wrote:

> 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.
>

  Actually even in this model I think the continuity should be the latest
edit.


> * 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.
>

by revision_id_expired I meant expired_id


> * 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/03cbc21d/attachment-0001.html>