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

[Seb Bacon]

Any chance of an entity diagram of some kind?  Even just a photo of a
sketch on a bit of paper. I'm having trouble quickly digesting all of
this.

Thanks,

Seb

On 13 May 2011 15:39, 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.
> * 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
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>
>