[okfn-help] vdm: pending state

[Martijn Faassen]

Hey,

Thanks for the discussion, it's helping me think! I'll sketch out some
of my use cases and I'll sketch out some possible answers after that.

Use cases first (after having thought about it more):

* A certain revision of the database is declared to be "published". It
is important that it is easy to query this revision of the database
without having to worry about pending changes.

* It should be easy to get a consistent overview of the "current"
database. That is, the pending changes + those parts of the database
that remained unchanged.

* possible pending changes are: added items, updates, and deletions

* cherry-picking is important. That is, if I see a pending item, I
should be able to publish it individually.

* consistency is also important. If I publish a pending item that has
other pending items that refer to it, these should also be published.
(for one to many this is relatively straightforward. not sure whether
it is for many to many? there's also the question whether publishing
one record will result in a "cascade" where everything is essentially
published at once)

* it should be possible to revert a pending change, that is:
pending-add -> not there at all, pending-update -> back to previously
published record, pending-delete -> record is published again.

* if a pending change is subsequently modified again, it's not
important that the previously pending data can be retrieved (just the
published data). Then again, it's okay if it can be. (in the solution
below, we do track changes to pending data)

* it'd be nice if the system prevented the developer from making
changes to the continuity that are illegal, such as modifying a record
without setting it to pending-update, or deleting a record instead of
setting it to pending-delete, or adding a new record that's not set to
pending-add. But not utterly essential.

Possible solution strategy:

* the continuity represents the most recent revision of the database
(correct?). The continuity contains pending changes.

* the continuity is used to modify the database, and it's also used by
the UI - anything in the continuity is relevant to the UI. This means
that since the continuity is easy to query, the UI can be constructed
fairly easily.

* The state can be 'pending-new', 'pending-updated', and
'pending-deleted'. Continuity records have a state.

* the developer makes sure that when a new record is added to the
continuity it is set to pending-new, that when a record is updated
it's set to pending-update, and when a record is deleted it's set to
pending-delete.

* when we do a state change, we make a new revision. Essentially every
operation is a revision.

* only a single record of any state can exist in the continuity; i.e.
there can't be a pending-record that's also pending-deleted

* pending items can be in older revisions as well.

* there is way to turn the pending state into the published state,
that knows about relations.

* there is a way to revert the pending state back to the previously
published state. This is aware of relations.

* reverting a pending-new involves simply removing that pending new
record from the revision.

* reverting a pending-deleted involves turning the state back to published.

* reverting a pending-updated record involves going through the
historical revisions of that record to a place where it was not
pending, and putting those data back in.

* there is a tool/system that can extract be pointed to a particular
revision and produce a "non-pending" version of the database for that
revision. I.e. all pending-deleted records are gone, pending-new
records are also gone, and pending-update records are the value of the
most recent revision that was not pending-update before then. I think
it's okay if we can generate this off-line; it doesn't need to be
maintained in the same database. It would be *nice* if we could
maintain this information on the fly though.

How does that sound?

Regards,

Martijn