Dear API hackers, I am trying to restrict query results by namespace.
In the following query, there are some members of namespace 6. However, there are many members in namespace 14. http://commons.wikimedia.org/w/api.php?action=query&generator=categoryme...
I have prefixed the cmnamespace with "g" for use as a generator. Leaving the "g" off produces the same results.
Have I stumbled upon a bug?
Thanks for your help, Karl
On Wed, Aug 26, 2009 at 10:01 AM, Karl Ostmokostmo@gmail.com wrote:
Dear API hackers, I am trying to restrict query results by namespace.
In the following query, there are some members of namespace 6. However, there are many members in namespace 14. http://commons.wikimedia.org/w/api.php?action=query&generator=categoryme...
I have prefixed the cmnamespace with "g" for use as a generator. Leaving the "g" off produces the same results.
Have I stumbled upon a bug?
Thanks for your help, Karl
Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
cmnamespace has been disabled on WMF wikis due to performance reasons. A workaround to the issue has been committed and reviewed. It will be sync'd to WMF wikis when code review is completed.
-Chad
On Wed, Aug 26, 2009 at 09:01:29AM -0500, Karl Ostmo wrote:
Have I stumbled upon a bug?
https://bugzilla.wikimedia.org/show_bug.cgi?id=19640
Basically, Domas decided on July 10 that use of cmnamespace was overloading the servers in some manner (which manner, specifically, is unknown), so he broke the cmnamespace parameter in about the worst possible way in a live hack to the site.
On July 11 a change was made in SVN to at least give people an error instead of silently ignoring the parameter, on July 13 that was changed to a warning, and on July 15 a change was made to allow the parameter to work at the expense of not necessarily giving cmlimit results before needing a cmcontinue. But in the month since then, no one with the appropriate access has bothered to use any of those changes to fix the original incredibly-broken live hack, so that incredibly-broken live hack is still causing us issues.
I've heard rumors that they may be (FINALLY!) getting ready to sync all the changes from the last two months, which will finally fix the bug on Wikipedia.
Interesting situation.
For now I am just requesting a large number of results per page in order to get to the first result in namespace 6. I'm submitting an entry to ADC2http://code.google.com/android/adc/with queries that specify the cmnamespace parameter, just in case it starts working again. However, I won't be able to change it after the deadline. So long as use of the cmnamespace parameter doesn't suddenly start raising an error, I'll be happy :)
Karl
On Wed, Aug 26, 2009 at 11:12 AM, Brad Jorsch b-jorsch@northwestern.eduwrote:
On Wed, Aug 26, 2009 at 09:01:29AM -0500, Karl Ostmo wrote:
Have I stumbled upon a bug?
https://bugzilla.wikimedia.org/show_bug.cgi?id=19640
Basically, Domas decided on July 10 that use of cmnamespace was overloading the servers in some manner (which manner, specifically, is unknown), so he broke the cmnamespace parameter in about the worst possible way in a live hack to the site.
On July 11 a change was made in SVN to at least give people an error instead of silently ignoring the parameter, on July 13 that was changed to a warning, and on July 15 a change was made to allow the parameter to work at the expense of not necessarily giving cmlimit results before needing a cmcontinue. But in the month since then, no one with the appropriate access has bothered to use any of those changes to fix the original incredibly-broken live hack, so that incredibly-broken live hack is still causing us issues.
I've heard rumors that they may be (FINALLY!) getting ready to sync all the changes from the last two months, which will finally fix the bug on Wikipedia.
Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
mediawiki-api@lists.wikimedia.org