https://bugzilla.wikimedia.org/show_bug.cgi?id=24782
Summary: API uses non-unique value for paging for
list=recentchanges
Product: MediaWiki
Version: 1.17-svn
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: Normal
Component: API
AssignedTo: roan.katt...@gmail.com
ReportedBy: brightb...@gmail.com
CC: bryan.tongm...@gmail.com, s...@reedyboy.net,
vasi...@gmail.com, soxre...@gmail.com
When listing recentchanges, the API uses rctimestamp for paging, which is not a
unique index:
<query-continue>
<recentchanges rcstart="2010-07-14T14:21:31Z" />
</query-continue>
This is quite bad: say, there where 23 changes in 14:21:39, but the first call
only retrieved 10. Using 14:21:39 for rcstart for the next page will return the
*same* 10 again, not any of the 134 remaining records. This might even put the
client into an infinite loop.
Using 14:21:40 would not be better: it go to the next timestamp, thus
effectively skipping the 13 items we didn not yet read for 14:21:39.
<query-continue> absultely MUST use a unique index. The only unique index for
recentchanges is rcid - but is it guaranteed to increase monotonously? Maybe
<query-continue> could use a compund index too, like <recentchanges
rcstart="2010-07-14T14:21:31Z" rcid="667455"/> ?
The problem is also how to change this in a B/C fashion. In theory, the client
should simply use whatever attriubute it finds in
<query-continue><recentchanges>. But can we be sure non has the timestamp
hard-coded for that? Would it be ok to break clients that rely on rcstart being
a timestamp?
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
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
