Hi there, On Mon, Oct 4, 2010 at 6:25 PM, Rufus Pollock <[email protected]> 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 _______________________________________________ okfn-help mailing list [email protected] http://lists.okfn.org/mailman/listinfo/okfn-help
