https://bugzilla.wikimedia.org/show_bug.cgi?id=73623
--- Comment #16 from Brad Jorsch <bjor...@wikimedia.org> --- (In reply to Matthew Flaschen from comment #13) > (In reply to Nik Everett from comment #12) > > OK. I'm not working on that now because I don't think it's as bad. Also I > > don't understand our API too well so I'd have to do some research. I don't > > even know enough to know if the bug is in CirrusSearch. > > The general idea is that lists return results directly, and generators use > the output of a list to feed into another module (like a UNIX pipe). So > generators essentially are the intended way to combine modules in one query > like this. The problem is for some reason list= is also used/necessary in > this case. See https://www.mediawiki.org/wiki/API:Query#Generators This. The general problem people seem to be running into with search as a generator is that they want to keep some indication of the ranking despite generators currently being defined as producing an unordered list of pageids (or revids). I'm not opposed to allowing generators to provide additional properties for the generated pages (reopening bug 14859, although I'd probably do it in a different manner than requested there) but it'll take some thought as to how to best do that. I'll put something on [[mw:API/Architecture work/Planning]] so I don't forget to look into it. As for how the API code works in this situation, it instantiates two instances of ApiQueryPrefixSearch, and each instance runs the same code to get a list of titles: $searcher = new TitlePrefixSearch; $titles = $searcher->searchWithVariants( $search, $limit, $namespaces ); The processing of that list of titles is different, but it should theoretically be the same titles in the list. What seems to be going on is that this code is not entirely deterministic. (In reply to Monte Hurd from comment #8) > Here is the exact query the iOS app used for those two screenshots: > > https://en.m.wikipedia.org/w/api. > php?action=query&format=json&generator=prefixsearch&gpslimit=24&gpsnamespace= > 0&gpssearch=fish&list=prefixsearch&pilimit=24&piprop=thumbnail&pithumbsize=14 > 4&ppprop=wikibase_item&prop=pageprops%7Cpageimages&pslimit=24&pssearch=fish I note you're using gpsnamespace=0, but not psnamespace=0. In this case that doesn't matter, though, since 0 is the default. I have been able to reproduce the issue with this query, BTW. (In reply to Matthew Flaschen from comment #13) > I notice this does not use indexpageids. So you're only getting it in the > correct order if whatever iOS JSON parser you're using preserves order in > hashes/associative arrays (possible, but not certain). They're presumably using query.prefixsearch (which *is* a JSON array) for the ordering, using the pageids from there to look up the additional info in the query.pages hash. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
