[okfn-help] vdm: pending state

[Martijn Faassen]

Hi there,

On Mon, Oct 4, 2010 at 6:25 PM, Rufus Pollock <rufus.pollock at okfn.org> wrote:
> Apologies for the delay Martijn!

I'm late with responding too, but expect to spend some more time on
this the coming weeks..

>> * certain can publish changes (add/update/removals made)
>
> I assume you mean 'certain people'

Yes.

>> I understand vdm maintains the database in the normal tables, which
>> you'd access as if the content wasn't
>> revisioned. It then retains information about this and other revisions
>> in the revision tables.
>
> Right, but also adds a 'state' field and revision_id field to the
> 'normal' table.

Doesn't this break uniqueness of primary keys? If you have more than
one record with id '1' with different states, what then? Though I
think you avoid this in the sketch below.

>> In the pending use case, should the normal tables contain the pending
>> information or the published information?
>
> This is an interesting question. Suggestion:

> 1. Case where object is entirely new. Write it in normal way (to both
> normal table with copy to revision table) and set state to 'pending'
>
> 2. When writing a 'pending' change to an already 'active' object. In
> this case, I suggest we just write a new revision to the 'revision'
> table with state set to pending and make no change to the 'normal'
> table. Then when the change is approved we will write that change to
> the active table (and, I guess, update the revision table to set the
> state on that revision to active -- to avoid issues if we revert).
> This will require a bit of a change to vdm to support this
> functionality:
>
>  * Change the Revisioner MapperExtension so that it checks the state
> field when making the write (before_update method i imagine) and does
> not write to continuity object fields if state is 'pending'.
>  * Have some support for marking 'pending' revisions as approved
> which triggers write to continuity object (normal table)

How would this work for records that are pending-removed?

So your suggestion is to write the published info to the normal tables
(the "continuity", right?), but also have pending new records in it?

Doesn't that make two common use cases more difficult?

* query & manipulate "pending" data - the normal tables don't quite
represent this as records may be updated invisibly in the revision
table instead.

* query & manipulate published data - the normal tables don't quite
represent this as new pending records may be present.

One important use case is that people may want to query the published
data using raw SQL - it should be as close to unversioned data as
possible. It's less important that the pending state can be queried in
this way - though there should of course be some way to query a
consistent state through the ORM so that a UI can be presented.

I almost think there should be two continuities: one pending and one published.

When a pending change is published, all other pending changes that
point to it with a foreign key relation should also be published.

I'm trying to figure how this relates to the concept of Revisions,
which are global per database. It doesn't appear to be enough to be
able to point to a revision and declare it the most recently published
revision, because pending objects would be included as well. The
analogy to a version control system is that "pending" changes are
modifications to a checkout but haven't been committed yet.

If we follow the analogy with a version control system, you could say
the pending continuity is the checkout, and the normal continuity is
the trunk. When a commit is made, parts (or the whole) of the checkout
is committed into the trunk. This can all be done in a single
revision. The checkout itself does not have individual revisions, only
the trunk does. We can also assume that only a single checkout ever
exists - that's a difference with a software version control system,
so that updating the checkout to synchronize changes should never be
needed.

Regards,

Martijn