Last modified: 2008-11-02 18:23:51 UTC
I just noticed that running a list=usercontribs query returns a totally wrong value for query-continue. at the moment, you get: <query-continue> <usercontribs ucstart="timestamp" /> </query-continue> when you really ought to be getting: <query-continue> <usercontribs uccontinue="timestamp" /> </query-continue> the timestamp value might be the correct value (I'll try that and see) but the parameter name is wrong. it even says this in the docs, incidentally...
addendum: I don't think the timestamp returned is the correct value for uccontinue. don't know what it is, but it doesn't seem to have the desired effect.
This is correct behavior. When listing contributions for just one user, usercontribs sets ucstart=timestamp as its query-continue value. When listing contributions for multiple users (with ucuserprefix or multiple values for ucuser), usercontribs sets uccontinue=username|timestamp as its query-continue value. It's perfectly legal for a module to use different query-continue parameters in different situations: clients are supposed to just do what query-continue says. Of course this kind of behavior can be confusing; usercontribs is the only module to do this, and was only recently updated to do so.
Follow-up question. just thinking programmatically here, but if a script sends both the 'ucstart' and 'uccontinue' parameters, does the latter obviate the former? basically I want to know if I need to remove the ucstart parameter when I continue a query with uccontinue.
(In reply to comment #3) > Follow-up question. just thinking programmatically here, but if a script > sends both the 'ucstart' and 'uccontinue' parameters, does the latter > obviate the former? basically I want to know if I need to remove the > ucstart parameter when I continue a query with uccontinue. > Neither overrides the other, the most restrictive one applies. In real-life situations, uccontinue will always be more restrictive than ucstart, so you *could* leave out ucstart when you've got a uccontinue, but you don't *have* to.
well, it's an issue of a single line that messes up my beautiful, generalized code. In other words, you're KILLING me! lol =)
(In reply to comment #5) > well, it's an issue of a single line that messes up my beautiful, generalized > code. > > In other words, you're KILLING me! lol > > =) > It shouldn't mess up sane code. Sane code would just blindly do whatever query-continue says and not modify the original request in any other way. That always works, and always will.
no worries, I was just joking around. :-)
