[ckan-discuss] Tag_count per group / packagecount in grouplist
john.bywater at appropriatesoftware.net
Thu Oct 14 18:19:29 BST 2010
Friedrich Lindenberg wrote:
>> But in any case, it might be nice to pass a list comprehension to the server, and have the results returned in one call. So I wondered whether a "List Comprehension API" would make sense?
> I don't get this - are you proposing to allow the client to pass actual code to the server (or a sufficiently large set of parameters for this to make sense)? That would not make things very RESTish, I think - but I'm eager to hear more about what you are proposing!
I was just wondering whether supporting a list comprehension syntax
would be useful, to cut down bandwidth in cases just like this.
For example, when to get all the package titles, you have to get all the
ids, and then get all the entities, and then get the title from each entity.
We could imagine a request something like:
($id, /package/$id/title) for $id in /package
which could return something like:
[(UUID, TITLE), (UUID, TITLE), (UUID, TITLE), ...]
Looking at what Martin asked for:
1. "To get a tag-list, with count, for a specific group"
I'm not sure whether we want to get a set of all tags on the packages of
a group? Or a list of the tags used on each package of a group?
For the first one, we publish a new resource locator:
For the second case, we could imagine a list comprehension:
[($id, /package/$id/tags) for $id in /group/mygroup/packages]
2. "To show a package count per group for a page of 30 groups"
We could imagine a list comprehension, like this:
[/group/$id/packages/count for $id in [id0, id1, id2, ... , id29]]
where the id0, id1, etc. are the items in the page.
>> That's not to argue against faceted search. Indeed, let's establish requirements before shaping up a solution. :-)
> As an intro to the kind of data that facets expose, let me point you at http://wiki.apache.org/solr/SimpleFacetParameters#Facet_Fields - this to me looks very much like the thing Martin is asking about - but I might be rorschaching there ;-)
Yes, it looks good. I'm not against this. We could adopt a faceted
search query syntax, regardless of anything else.
But I wondered whether we could make further use of the published API
There seems to be two separate concerns: how to implement efficient
filtering when the filter is complex; and how to implement a good way
for a user of the API to express the filter.
I mean, if you're looping over the result of one call with a load of
other calls, it might be nice to cut out most of the to-ing and fro-ing,
with a list comprehension, just like in programming languages. At this
point, you know the resource locators, so putting them into a list
comprehension would express what you're trying to do. Switching to a
whole new syntax might not feel so smooth. But I'm just guessing.
More information about the ckan-discuss