[ckan-dev] Package modification date

William Waites ww at styx.org
Wed May 18 14:21:30 UTC 2011


* [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

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. It is
also brittle because the gigantic UNION needs to be changed every time
a related versioned object is added or, as is being contemplated in
other threads, the versioning mechanism is changed. 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.

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
<




More information about the ckan-dev mailing list