[ckan-dev] Package modification date
Seb Bacon
seb.bacon at gmail.com
Wed May 18 14:53:22 UTC 2011
On 18 May 2011 15:48, David Read <david.read at okfn.org> wrote:
> 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?
I agree with this.
>> 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.
In a nutshell, David's proposals will make queries like "tell me about
all objects that make up package X on such-and-such-a-date" easy. As
a byproduct, I imagine it would make computing a last-modified time
for a package (as a semantic concept) a bit cheaper.
Seb
More information about the ckan-dev
mailing list