Discussion:
[Bug 14859] add an index field to show original order of queried titles
bugzilla-daemon-f4n82jGjeJOzKZ/5c+
2008-07-19 21:13:00 UTC
Permalink
https://bugzilla.wikimedia.org/show_bug.cgi?id=14859


Roan Kattouw <roan.kattouw-***@public.gmane.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |roan.kattouw-***@public.gmane.org
Status|NEW |RESOLVED
Resolution| |WONTFIX




--- Comment #1 from Roan Kattouw <roan.kattouw-***@public.gmane.org> 2008-07-19 21:13:02 UTC ---
(In reply to comment #0)
When querying a number of titles in a singe request, especially when it is
expected that some won't exist, it would be very useful to be able to access
the results in the same order the titles were in.
I don't see how that's particularly useful, as our target audience are bots who
just load all the result data in memory and iterate through it. If you really
need titles in the requested order, you can reorder them yourself.
It should be much less work to add an index field to api.php compared to
iterating through the results with lots of string operations at the local side.
Actually, it's not. We feed the list of titles to the database, which spits out
the data you need ordered by page ID. There's really no difference between
reordering stuff to conform to the requested order on the server side and doing
so on the client side. In this case, it's better to leave it at the client
side, since it's not a very popular feature.
"index" could be a new field next to "pageid", "ns", "title" etc. It seems so
low cost that it need not even be optional.
Ordering stuff by ns/title on the database side is *far* from low-cost in most
cases. This is because the database is pretty restrictive in the things it can
order by efficiently. Ordering by page ID works for most queries, which is why
we do it. As to ordering in the API itself (on the server side): that's every
bit as slow/fast as ordering on the client side, so let's just leave that up to
the client.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
b***@wikimedia.org
2014-06-26 15:06:03 UTC
Permalink
https://bugzilla.wikimedia.org/show_bug.cgi?id=14859

Brad Jorsch <***@wikimedia.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #2 from Brad Jorsch <***@wikimedia.org> ---
*** Bug 67131 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are on the CC list for the bug.
b***@wikimedia.org
2014-07-27 20:35:38 UTC
Permalink
https://bugzilla.wikimedia.org/show_bug.cgi?id=14859

Brad Jorsch <***@wikimedia.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@joernhees.de

--- Comment #3 from Brad Jorsch <***@wikimedia.org> ---
*** Bug 68515 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are on the CC list for the bug.
b***@wikimedia.org
2014-11-12 20:08:31 UTC
Permalink
https://bugzilla.wikimedia.org/show_bug.cgi?id=14859

Brad Jorsch <***@wikimedia.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #4 from Brad Jorsch <***@wikimedia.org> ---
*** Bug 73323 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are on the CC list for the bug.
b***@wikimedia.org
2014-11-20 18:15:48 UTC
Permalink
https://bugzilla.wikimedia.org/show_bug.cgi?id=14859

Brad Jorsch <***@wikimedia.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
CC| |***@wikimedia.org
Resolution|WONTFIX |---

--- Comment #5 from Brad Jorsch <***@wikimedia.org> ---
I'm going to look at doing something along these lines, although it's going to
be more general than just "stick an index field somewhere" and targeted at
things like generator=search where the order actually matters.

Details at
https://www.mediawiki.org/wiki/API/Architecture_work/Planning#Allow_generators_to_provide_data
--
You are receiving this mail because:
You are on the CC list for the bug.
b***@wikimedia.org
2014-11-20 19:26:32 UTC
Permalink
https://bugzilla.wikimedia.org/show_bug.cgi?id=14859

--- Comment #6 from Max Semenik <***@gmail.com> ---
Just preserving the order from generator would be really awesome. There is no
reason why it's not being done other than "that's how link batch query sorts
titles", however you don't really have to use the order from the query.
--
You are receiving this mail because:
You are on the CC list for the bug.
b***@wikimedia.org
2014-11-20 20:44:48 UTC
Permalink
https://bugzilla.wikimedia.org/show_bug.cgi?id=14859

--- Comment #7 from Brad Jorsch <***@wikimedia.org> ---
(In reply to Max Semenik from comment #6)
Post by b***@wikimedia.org
There is
no reason why it's not being done other than "that's how link batch query
sorts titles"
Not exactly. To "preserve" the order, we'd have to save the order somewhere and
then reorder a number of different arrays after they were populated from
various queries.

And then your JSON decoder might throw the ordering away anyway.
--
You are receiving this mail because:
You are on the CC list for the bug.
Loading...