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

[David Raznick]

>
> I'm personally of the view that this fits very naturally with the
> proposed new 'changeset' vdm model. In that model it is natural and
> relatively easy to have changesets that have been 'created' but not
> 'applied' to the 'working copy' (i.e. continuity objects).
>

I do not see how this would make any difference in this case.   See below
for my explanation of this.

This is more along the lines of your option 1.
>
> You don't seem to favour this :-)


I am on the fence to be honest.  Proposal 1 is quick and dirty and will do
mostly what we need if we are prepared to throw away all our 'pending'
changes when we change our schema and if we do not care about looking at
historical changes.   I do think that proposal 1 should be separate from vdm
entirely as they do different things.

I will try and explain were I am coming from with an example.  Say we have
simplified package dict. with a many2many relationship with resources.

{'name': u'anna2',
'id': u'afafaff',
'resources': [{'id': u'fafafaff',
               'url':
u'http://www.annakarenina.com/'<http://www.annakarenina.com/download/x=1&y=2%27>
},
               {'id': u'fafafafa',
               'url': u'http://www.annakarenina.com/index.json'}]
}

Say somebody changes a resource, but leaves the package intact, so changes
it to.

{'name': u'anna2',
'id': u'afafaff',
'resources': [{'id': u'fafafaff',
               'url':
u'http://differenturl'<http://www.annakarenina.com/download/x=1&y=2%27>
},
              {'id': u'fafafafa',
               'url': u'http://www.annakarenina.com/index.json'}]
}

Both the new and old vdm will store changes to *just* the resource. There is
no getting round that unless the resource has a way of signalling the
package to make a whole new package dict to store.  This is my proposal 1,
to manually do this signalling selectively in the logic layer.  vdm cannot
guess what to signal nor shouldn't.

In my opinion our revisioning system (vdm) should not store package dicts
like that, as they are fragile to change.  It should only store changes to
individual tables like we do currently do.

To prove this, say also at one point you try and look at the data the other
way round, and you consider resources the primary object. You want the
resource dict to look like.

{'id': u'fafafaff',
 'url': u'http://differenturl'<http://www.annakarenina.com/download/x=1&y=2%27>
'packages': [{'name': u'anna2',
             'id': u'afafaff'}
             ]
}

If we have not pre-emptively stored the resource dict like this, then to
reproduce it will be very very hard if all we have is the above package
dicts.  It will be a lot easier to reproduce this if we make sure we store
each table separately.

Proposal 2 gives us a way of producing these dicts historically for any way
we decide to look at the data.  The new changeset model in vdm makes that
hard as we will need to join on keys contained in the
change_object_dicts, it is much nicer and faster if the data is in an
indexable table like it currently is.

If you have a new proposal then these two offered and uses the changeset
model then please add it to the c(r)ep :)

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20110509/76958981/attachment-0001.html>