https://bugzilla.wikimedia.org/show_bug.cgi?id=67131
--- Comment #3 from Jörn Hees <[email protected]> --- I actually disagree that this is simply a duplicate of bug 14859: in bug 14859 the op already knows the order of titles he's querying for. Here search internally returns the order to the generator but that information is just destroyed and never given to the end user, causing us to need two queries instead of just one. I don't see how not destroying that ordering information and returning it as an optional index list would have any significant performance impact. If one is considered about re-ordering the up to 500 "pages" results one could even leave them in the order they are in atm [1], because with that optional index list from the generator input function one could actually resort the results on client side as mentioned in bug 14859. Additionally generator=search would not need 2 individual queries. @Brad: Would be nice if you could reconsider your decision on this one and maybe reopen it. [1]: (they are actually a result dict not list, so it's probably not wise to rely on their order anyhow) -- 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
