Page MenuHomePhabricator

API: Provide a way to combine prefixsearch results with knowledge of whether they are in a given collection
Closed, ResolvedPublic


As a developer with a collection id I need to be able to generate a list of titles with a property telling me whether the page is in the given collection or not.
Use case: Do a prefix search and combine with this new query via a generator.

@Yurik proposed using a new prop

action=query & titles=pageA|pageB & prop=listmembership & lsmid=<listID>

Resulting in

{ 'query': { 'pages': [ {
   'id':10, 'title':'pageA', listmembership:""  // becomes true if formatversion=2+
}, {
   'id':15, 'title':'pageB'

Because its a prop, it can easily use a generator to supply list of titles. Can also do lsmlabel=label, and possibly even other user's public lists with lsmowner=User


Related Gerrit Patches:
mediawiki/extensions/Gather : masterImplements prop=listmembership

Event Timeline

Change 203003 had a related patch set uploaded (by Yurik):
Implements prop=listmembership

Jdlrobson moved this task from Needs triage to Product triage on the Gather board.Apr 9 2015, 3:59 PM
Jdlrobson moved this task from Product triage to In sprint on the Gather board.Apr 11 2015, 12:10 AM

@Jdlrobson, this request is done, and needs to be +2ed. The usage of the api is another matter.

I feel it is really weird to return "listmembership:" "" when the page is member and not including the field when it is not. Why not return "listmembership": true or something similar that makes more sense?

Yurik added a subscriber: Anomie.Apr 22 2015, 6:07 PM

According to @Anomie, this is being changed globally - if you use formatversion=latest (2+), you should get true instead of "".

As for not including it - see comment inside the code - calculating items that are NOT part of the list requires going through all the results for each api call. But if you request many different properties in the same call and they doesn't all fit into one response, the next continuation would need to process everything it has done before, which is fairly complex. Thus, it is easier to simply return what is known as TRUE, but don't report the FALSE.

Wait formatversion=version ? The API has versioning (see T41592)?

Yurik updated the task description. (Show Details)Apr 22 2015, 6:13 PM

I feel it is really weird to return "listmembership:" "" when the page is member and not including the field when it is not. Why not return "listmembership": true or something similar that makes more sense?

Historically, the XML format came first and in XML you'll often do a boolean attribute by having it present (with any value) for true and absent for false. When JSON was added boolean outputs were left XML-style instead of fixing it to be actual booleans.

As Yuri pointed out I just recently got around to making that fix, but for backwards compatibility you need to ask for it specifically (along with other structural changes with the same reasoning, like having keys with useful names rather than "*").

Yurik added a comment.Apr 22 2015, 7:03 PM

Yep, good work on that @Anomie! I really wish I foresaw that XML was a mistake back in 2005. Everyone was heavily into XML, mostly pushed by Microsoft.

@Anomie super cool. So glad this is happening.

Tgr added a comment.May 4 2015, 4:19 PM

lsmlabel is not part of the patch. Is it needed?

Change 203003 merged by jenkins-bot:
Implements prop=listmembership

Jdlrobson closed this task as Resolved.May 7 2015, 9:54 PM
Jdlrobson moved this task from Ready for signoff to Done on the Gather Sprint Greatest Hits board.