Last modified: 2014-06-13 18:20:34 UTC
list=logevents (le) does not have a namespace filter like list=recentchanges
It used to have one, but it was removed because filtering on namespace killed the database.
(In reply to comment #1) > It used to have one, but it was removed because filtering on namespace killed > the database. With the current db scheme, it may be killing. But I think through the years many valid bugs and requests have come to depend on such filter. Reopening with dependancy on bug 14711 which requests the actual filterability. Note that mw_logging has had an index on (log_namespace, log_title) since it was created in r4919. What is causing the kill actually ? (respond on bug 14711 ?)
There is no (namespace,timestamp) index.
It would be possible to do a faux NS filter in Miser mode as a middle ground hack... As for being able to do it efficiently....
(In reply to comment #3) > There is no (namespace,timestamp) index. r4919 - tables.sql (MediaWiki 1.3A) > KEY page_time (log_namespace, log_title, log_timestamp) r84394 - tables.sql (MediaWiki 1.18alpha) > CREATE INDEX /*i*/page_time ON /*_*/logging (log_namespace, log_title, log_timestamp);
Indeed, but you just can't use those skipping the middle field
Marking later, has no use staying open for the moment The API side can be reopened when (if?) the core issue is fixed
[Removing RESOLVED LATER as discussed in http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064240.html . Reopening and setting priority to "Lowest". For future reference, please use either RESOLVED WONTFIX (for issues that will not be fixed), or simply set lowest priority. Thanks a lot!]
lenamespace was added with Gerrit change #135283
