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

[Rufus Pollock]

On 13 May 2011 13:59, David Raznick <kindly at gmail.com> wrote:
> On Fri, May 13, 2011 at 11:02 AM, Rufus Pollock <rufus.pollock at okfn.org>
> wrote:

Not commenting directly on this thread really but pulling out
something you said ...

>> To parse that I think that means you agree with ticket 1137 but want
>> limited version. The question I still think we need to clarify is why
>> keep state in main continuity objects?
>
>
> Personally I would be happy to remove continuity objects entirely and just
> have the revision tables.

I think this is *really* interesting point.

I had a long talk at Christmas with Matthew Brett (in cc) about
datapkg and the domain model and functionality of practically doing
data packaging especially installing stuff on the local machine [1].

One of the insights that came out of that discussion is that:

We work with (Data) PackageRevisions not (Data) Packages

That is when I install a Data Package I'm not getting the abstract
'package' but some particular revision of that package. This is true
of code: one may say one has installed e.g. python but really we
install python v2.6.1 (which in turn is just an alias to some revision
number of the code source).

The abstract Package (as platonic ideal) only really then exists as
convenient way to collect together PackageRevisions and it is
PackageRevisions that should be central in our system.

I believe you are saying something similar. If so I think we are onto
something important here.

Rufus

Aside: the practical fact that we use SQL introduces a slight
confusion because as a practical matter SQL requires, for foreign keys
to work, that we have a concrete instantiation of the continuity
object -- i.e. the Package -- so we can refer to it from other
objects. But this is just an implementation "detail" and should not
distract us from the fact that PackageRevision is actually what
matters.

[1]: Some of this is documented in this thread here
<http://lists.okfn.org/pipermail/okfn-dev/2011-January/000034.html>