[ckan-dev] Package modification date

[David Read]

On 18 May 2011 15:21, William Waites <ww at styx.org> wrote:
> * [2011-05-17 15:19:43 +0100] David Read <david.read at okfn.org> écrit:
>
> ] I guess we have a 2 step process to get the revision list, then query
> ] each revision. This follows our REST model. Do suggest an alternative!
>
> I have in the past, just add a modified_since or similar parameter
> to /api/package/search

Sounds like a good suggestion. Anyone else with opinions?

> What's happening here is that CKAN's interesting but complicated and
> idiosyncratic versioning model is leaking out the API.
>
> The rather
> complicated UNION needed to find the modified date (see the modified
> method on package) needs to be effectively done by the client.

Yes it's a two step process, as per most RESTful APIs. We put in a
shortcut for search results (all_fields) - maybe the revision list
could do with this too. But I prefer your suggestion earlier.

> It is
> also brittle because the gigantic UNION needs to be changed every time
> a related versioned object is added or

Yes, a greater package is normalised across several tables, but you're
right, we could probably improve the efficiency of the query we
currently have.

> as is being contemplated in
> other threads, the versioning mechanism is changed.

This API has been around for a year. I'd be interested to hear if
David Raznick's proposals impact this API - my understanding is it is
just an internal refactor. This may impact some users.

> This is a CKAN
> implementation detail that the clients shouldn't care about.
>
> ] As I have reiterated today (having already said to you a couple of
> ] weeks ago), the atom feed is not for machines - it is designed to be
> ] human readable. Instead, look at revision search which is. No scraping
> ] required - JSON format.
>
> Right, and the reason I haven't implemented that is because it's
> complicated enough, and just walking all the packages is works well
> enough that its a pretty low priority for me. Its even lower priority
> when I read that the way it works may change and it isn't clear how
> these changes might percolate out to the API. Easier to burn extra CPU
> cycles and network bandwidth.
>
> Modification time is a pretty common attribute for a thing to have
> (Ãyes, the net is cast widely on purpose and I don't know of a single
> other service or API that requires jumping through these types of
> hoops to search on it or otherwise get at it.

We do have modification time in the model, and hopefully we can
improve the API with suggestions like yours above, whilst keeping the
simplicity that the RESTfulness provides.

Dave

> Cheers,
> -w
> --
> William Waites                <mailto:ww at styx.org>
> http://river.styx.org/ww/        <sip:ww at styx.org>
> F4B3 39BF E775 CF42 0BAB  3DF0 BE40 A6DF B06F FD45
> <
>