Last modified: 2011-03-13 18:04:26 UTC
In list=categorymembers function, it would be great to add support to cmtitle to handle more than one category. This would be useful when requesting members from multiple categories at once. The possible scenario I would use this for to to query list of categories to be checked for tagging WikiProject banners.
This can't be implemented efficiently, because we sort results by category name first, then by sortkey, then by page ID. That means cmtitles=Category:Foo|Category:Bar will first list all members of Category:Foo, then all members of Category:Bar, meaning it's no better than just doing two queries.
roan, an inefficient implementation would still help me a lot, so i hope you might reconsider. i am writing an application which, for a given article, acquires lists of peer articles in some of its categories. without paging, this means making one asynchronous HTTP connection per category, which breaks badly on "Amtrak" (with over 60 categories, many of which have almost no members). the order the contents were returned is less important than a big cut in the number of connections i need to make. by executing action=query&generator=categories&prop=categoryinfo in advance, i can pick out which categories have suitable numbers of pages in them to proceed to the member listing step. this means that a category with hundreds of members could come last in the list, giving me access to a good subset of the category members in a single HTTP request (several if i page on through the results, but still not 60).
(In reply to comment #2) > roan, an inefficient implementation would still help me a lot, so i hope you > might reconsider. I meant inefficient on the server side. So I'm sure it would help you a lot, but it would also overload the database servers. > i am writing an application which, for a given article, acquires lists of peer > articles in some of its categories. without paging, this means making one > asynchronous HTTP connection per category, which breaks badly on "Amtrak" (with > over 60 categories, many of which have almost no members). the order the > contents were returned is less important than a big cut in the number of > connections i need to make. I understand that ordering isn't important to everyone, but it's needed to make query-continue possible. > by executing action=query&generator=categories&prop=categoryinfo in advance, i > can pick out which categories have suitable numbers of pages in them to proceed > to the member listing step. this means that a category with hundreds of members > could come last in the list, giving me access to a good subset of the category > members in a single HTTP request (several if i page on through the results, but > still not 60). > Sounds like a good solution.
