https://bugzilla.wikimedia.org/show_bug.cgi?id=24782

Roan Kattouw <roan.katt...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roan.katt...@gmail.com

--- Comment #2 from Roan Kattouw <roan.katt...@gmail.com> 2010-08-13 15:45:08 
UTC ---
(In reply to comment #0)
> <query-continue> absultely MUST use a unique index.
Yes, and the fact that it doesn't is very bad.

> The only unique index for
> recentchanges is rcid - but is it guaranteed to increase monotonously?
I'm not sure.

> Maybe
> <query-continue> could use a compund index too, like <recentchanges
> rcstart="2010-07-14T14:21:31Z" rcid="667455"/> ?
>
That would be the nicest solution, probably, but it requires adding rc_id to
the indexes we use (I think there's only two so that wouldn't be too bad). It
would be encoded differently though, as
rcontinue="2010-07-14T14:21:31Z|667455", to be consistent with other modules
paging on multiple fields.

> 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?
Yes, this is definitely OK. Clients are supposed to simply use whatever's in
query-continue and pass it back verbatim. Nevertheless, we would still announce
it, but not as a breaking change.

-- 
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

Reply via email to