2008-03-17 09:16:38 +00:00
|
|
|
<?php
|
|
|
|
|
|
2010-02-24 13:34:11 +00:00
|
|
|
/**
|
2008-03-17 09:16:38 +00:00
|
|
|
* API for MediaWiki 1.12+
|
|
|
|
|
*
|
2010-08-07 19:59:42 +00:00
|
|
|
* Created on Mar 16, 2008
|
|
|
|
|
*
|
2010-02-24 13:34:11 +00:00
|
|
|
* Copyright © 2008 Vasiliev Victor vasilvv@gmail.com,
|
2012-04-11 15:10:22 +00:00
|
|
|
* based on ApiQueryAllPages.php
|
2008-03-17 09:16:38 +00:00
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
|
* with this program; if not, write to the Free Software Foundation, Inc.,
|
2010-06-21 13:13:32 +00:00
|
|
|
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
2008-03-17 09:16:38 +00:00
|
|
|
* http://www.gnu.org/copyleft/gpl.html
|
2010-08-07 19:59:42 +00:00
|
|
|
*
|
|
|
|
|
* @file
|
2008-03-17 09:16:38 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Query module to enumerate all available pages.
|
2008-04-14 07:45:50 +00:00
|
|
|
*
|
WARNING: HUGE COMMIT
Doxygen documentation update:
* Changed alls @addtogroup to @ingroup. @addtogroup adds the comment to the group description, but doesn't add the file, class, function, ... to the group like @ingroup does. See for example http://svn.wikimedia.org/doc/group__SpecialPage.html where it's impossible to see related files, classes, ... that should belong to that group.
* Added @file to file description, it seems that it should be explicitely decalred for file descriptions, otherwise doxygen will think that the comment document the first class, variabled, function, ... that is in that file.
* Removed some empty comments
* Removed some ?>
Added following groups:
* ExternalStorage
* JobQueue
* MaintenanceLanguage
One more thing: there are still a lot of warnings when generating the doc.
2008-05-20 17:13:28 +00:00
|
|
|
* @ingroup API
|
2008-03-17 09:16:38 +00:00
|
|
|
*/
|
2012-04-11 15:10:22 +00:00
|
|
|
class ApiQueryAllImages extends ApiQueryGeneratorBase {
|
2008-03-17 09:16:38 +00:00
|
|
|
|
2011-03-07 14:45:11 +00:00
|
|
|
protected $mRepo;
|
2011-01-12 00:29:17 +00:00
|
|
|
|
2010-01-11 15:55:52 +00:00
|
|
|
public function __construct( $query, $moduleName ) {
|
2010-02-24 13:34:11 +00:00
|
|
|
parent::__construct( $query, $moduleName, 'ai' );
|
2009-08-04 08:40:38 +00:00
|
|
|
$this->mRepo = RepoGroup::singleton()->getLocalRepo();
|
|
|
|
|
}
|
2010-02-24 13:34:11 +00:00
|
|
|
|
2009-08-04 08:40:38 +00:00
|
|
|
/**
|
2011-03-20 19:09:41 +00:00
|
|
|
* Override parent method to make sure to make sure the repo's DB is used
|
2009-08-04 08:40:38 +00:00
|
|
|
* which may not necesarilly be the same as the local DB.
|
2010-02-24 13:34:11 +00:00
|
|
|
*
|
2009-08-04 08:40:38 +00:00
|
|
|
* TODO: allow querying non-local repos.
|
2011-01-02 04:37:06 +00:00
|
|
|
* @return DatabaseBase
|
2009-08-04 08:40:38 +00:00
|
|
|
*/
|
|
|
|
|
protected function getDB() {
|
|
|
|
|
return $this->mRepo->getSlaveDB();
|
2008-03-17 09:16:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function execute() {
|
|
|
|
|
$this->run();
|
|
|
|
|
}
|
|
|
|
|
|
2010-07-23 07:17:56 +00:00
|
|
|
public function getCacheMode( $params ) {
|
|
|
|
|
return 'public';
|
|
|
|
|
}
|
|
|
|
|
|
2011-02-19 00:30:18 +00:00
|
|
|
/**
|
|
|
|
|
* @param $resultPageSet ApiPageSet
|
2012-01-12 19:41:18 +00:00
|
|
|
* @return void
|
2011-02-19 00:30:18 +00:00
|
|
|
*/
|
2010-01-11 15:55:52 +00:00
|
|
|
public function executeGenerator( $resultPageSet ) {
|
2010-02-24 13:34:11 +00:00
|
|
|
if ( $resultPageSet->isResolvingRedirects() ) {
|
2010-01-11 15:55:52 +00:00
|
|
|
$this->dieUsage( 'Use "gaifilterredir=nonredirects" option instead of "redirects" when using allimages as a generator', 'params' );
|
2010-02-24 13:34:11 +00:00
|
|
|
}
|
2008-03-17 09:16:38 +00:00
|
|
|
|
2010-01-11 15:55:52 +00:00
|
|
|
$this->run( $resultPageSet );
|
2008-03-17 09:16:38 +00:00
|
|
|
}
|
|
|
|
|
|
2011-02-19 00:30:18 +00:00
|
|
|
/**
|
|
|
|
|
* @param $resultPageSet ApiPageSet
|
2012-01-12 19:41:18 +00:00
|
|
|
* @return void
|
2011-02-19 00:30:18 +00:00
|
|
|
*/
|
2010-01-11 15:55:52 +00:00
|
|
|
private function run( $resultPageSet = null ) {
|
2009-08-04 08:40:38 +00:00
|
|
|
$repo = $this->mRepo;
|
2010-02-24 13:34:11 +00:00
|
|
|
if ( !$repo instanceof LocalRepo ) {
|
2010-01-11 15:55:52 +00:00
|
|
|
$this->dieUsage( 'Local file repository does not support querying all images', 'unsupportedrepo' );
|
2010-02-24 13:34:11 +00:00
|
|
|
}
|
2008-03-17 09:16:38 +00:00
|
|
|
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
$prefix = $this->getModulePrefix();
|
|
|
|
|
|
2008-03-17 09:16:38 +00:00
|
|
|
$db = $this->getDB();
|
|
|
|
|
|
|
|
|
|
$params = $this->extractRequestParams();
|
2008-04-14 07:45:50 +00:00
|
|
|
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
// Table and return fields
|
|
|
|
|
$this->addTables( 'image' );
|
|
|
|
|
|
|
|
|
|
$prop = array_flip( $params['prop'] );
|
|
|
|
|
$this->addFields( LocalFile::selectFields() );
|
|
|
|
|
|
|
|
|
|
$ascendingOrder = true;
|
|
|
|
|
if ( $params['dir'] == 'descending' || $params['dir'] == 'older') {
|
|
|
|
|
$ascendingOrder = false;
|
2012-05-21 17:07:37 +00:00
|
|
|
}
|
|
|
|
|
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
if ( $params['sort'] == 'name' ) {
|
|
|
|
|
// Check mutually exclusive params
|
|
|
|
|
$disallowed = array( 'start', 'end', 'user' );
|
|
|
|
|
foreach ( $disallowed as $pname ) {
|
|
|
|
|
if ( isset( $params[$pname] ) ) {
|
|
|
|
|
$this->dieUsage( "Parameter '{$prefix}{$pname}' can only be used with {$prefix}sort=timestamp", 'badparams' );
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if ( $params['filterbots'] != 'all' ) {
|
|
|
|
|
$this->dieUsage( "Parameter '{$prefix}filterbots' can only be used with {$prefix}sort=timestamp", 'badparams' );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Pagination
|
|
|
|
|
if ( !is_null( $params['continue'] ) ) {
|
|
|
|
|
$cont = explode( '|', $params['continue'] );
|
2013-01-15 02:19:16 +00:00
|
|
|
$this->dieContinueUsageIf( count( $cont ) != 1 );
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
$op = ( $ascendingOrder ? '>' : '<' );
|
|
|
|
|
$continueFrom = $db->addQuotes( $cont[0] );
|
|
|
|
|
$this->addWhere( "img_name $op= $continueFrom" );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Image filters
|
|
|
|
|
$from = ( is_null( $params['from'] ) ? null : $this->titlePartToKey( $params['from'] ) );
|
|
|
|
|
$to = ( is_null( $params['to'] ) ? null : $this->titlePartToKey( $params['to'] ) );
|
|
|
|
|
$this->addWhereRange( 'img_name', ( $ascendingOrder ? 'newer' : 'older' ), $from, $to );
|
|
|
|
|
|
|
|
|
|
if ( isset( $params['prefix'] ) ) {
|
|
|
|
|
$this->addWhere( 'img_name' . $db->buildLike( $this->titlePartToKey( $params['prefix'] ), $db->anyString() ) );
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
// Check mutually exclusive params
|
|
|
|
|
$disallowed = array( 'from', 'to', 'prefix' );
|
|
|
|
|
foreach ( $disallowed as $pname ) {
|
|
|
|
|
if ( isset( $params[$pname] ) ) {
|
|
|
|
|
$this->dieUsage( "Parameter '{$prefix}{$pname}' can only be used with {$prefix}sort=name", 'badparams' );
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if ( !is_null( $params['user'] ) && $params['filterbots'] != 'all' ) {
|
|
|
|
|
// Since filterbots checks if each user has the bot right, it doesn't make sense to use it with user
|
|
|
|
|
$this->dieUsage( "Parameters '{$prefix}user' and '{$prefix}filterbots' cannot be used together", 'badparams' );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Pagination
|
|
|
|
|
$this->addTimestampWhereRange( 'img_timestamp', ( $ascendingOrder ? 'newer' : 'older' ), $params['start'], $params['end'] );
|
2010-08-06 18:58:10 +00:00
|
|
|
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
// Image filters
|
|
|
|
|
if ( !is_null( $params['user'] ) ) {
|
|
|
|
|
$this->addWhereFld( 'img_user_text', $params['user'] );
|
|
|
|
|
}
|
|
|
|
|
if ( $params['filterbots'] != 'all' ) {
|
|
|
|
|
$this->addTables( 'user_groups' );
|
|
|
|
|
$this->addJoinConds( array( 'user_groups' => array(
|
|
|
|
|
'LEFT JOIN',
|
|
|
|
|
array(
|
|
|
|
|
'ug_group' => User::getGroupsWithPermission( 'bot' ),
|
|
|
|
|
'ug_user = img_user'
|
|
|
|
|
)
|
|
|
|
|
) ) );
|
|
|
|
|
$groupCond = ( $params['filterbots'] == 'nobots' ? 'NULL': 'NOT NULL' );
|
|
|
|
|
$this->addWhere( "ug_group IS $groupCond" );
|
|
|
|
|
}
|
|
|
|
|
}
|
2010-01-11 15:55:52 +00:00
|
|
|
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
// Filters not depending on sort
|
2010-02-24 13:34:11 +00:00
|
|
|
if ( isset( $params['minsize'] ) ) {
|
2010-01-11 15:55:52 +00:00
|
|
|
$this->addWhere( 'img_size>=' . intval( $params['minsize'] ) );
|
2008-03-17 09:16:38 +00:00
|
|
|
}
|
2008-04-14 07:45:50 +00:00
|
|
|
|
2010-02-24 13:34:11 +00:00
|
|
|
if ( isset( $params['maxsize'] ) ) {
|
2010-01-11 15:55:52 +00:00
|
|
|
$this->addWhere( 'img_size<=' . intval( $params['maxsize'] ) );
|
2008-03-17 09:16:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$sha1 = false;
|
2010-01-11 15:55:52 +00:00
|
|
|
if ( isset( $params['sha1'] ) ) {
|
2012-12-16 22:45:31 +00:00
|
|
|
$sha1 = strtolower( $params['sha1'] );
|
|
|
|
|
if ( !$this->validateSha1Hash( $sha1 ) ) {
|
2011-05-15 13:16:13 +00:00
|
|
|
$this->dieUsage( 'The SHA1 hash provided is not valid', 'invalidsha1hash' );
|
|
|
|
|
}
|
2012-12-16 22:45:31 +00:00
|
|
|
$sha1 = wfBaseConvert( $sha1, 16, 36, 31 );
|
2010-01-11 15:55:52 +00:00
|
|
|
} elseif ( isset( $params['sha1base36'] ) ) {
|
2012-12-16 22:45:31 +00:00
|
|
|
$sha1 = strtolower( $params['sha1base36'] );
|
2011-06-25 03:50:41 +00:00
|
|
|
if ( !$this->validateSha1Base36Hash( $sha1 ) ) {
|
2011-05-15 13:16:13 +00:00
|
|
|
$this->dieUsage( 'The SHA1Base36 hash provided is not valid', 'invalidsha1base36hash' );
|
|
|
|
|
}
|
2008-03-17 09:16:38 +00:00
|
|
|
}
|
2010-01-11 15:55:52 +00:00
|
|
|
if ( $sha1 ) {
|
2011-05-15 13:16:13 +00:00
|
|
|
$this->addWhereFld( 'img_sha1', $sha1 );
|
2008-03-17 09:16:38 +00:00
|
|
|
}
|
|
|
|
|
|
2011-03-13 22:23:57 +00:00
|
|
|
if ( !is_null( $params['mime'] ) ) {
|
|
|
|
|
global $wgMiserMode;
|
|
|
|
|
if ( $wgMiserMode ) {
|
2011-06-05 23:44:37 +00:00
|
|
|
$this->dieUsage( 'MIME search disabled in Miser Mode', 'mimesearchdisabled' );
|
2011-03-13 22:23:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
list( $major, $minor ) = File::splitMime( $params['mime'] );
|
|
|
|
|
|
|
|
|
|
$this->addWhereFld( 'img_major_mime', $major );
|
|
|
|
|
$this->addWhereFld( 'img_minor_mime', $minor );
|
|
|
|
|
}
|
|
|
|
|
|
2008-03-17 09:16:38 +00:00
|
|
|
$limit = $params['limit'];
|
2010-01-11 15:55:52 +00:00
|
|
|
$this->addOption( 'LIMIT', $limit + 1 );
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
$sortFlag = '';
|
|
|
|
|
if ( !$ascendingOrder ) {
|
|
|
|
|
$sortFlag = ' DESC';
|
|
|
|
|
}
|
|
|
|
|
if ( $params['sort'] == 'timestamp' ) {
|
|
|
|
|
$this->addOption( 'ORDER BY', 'img_timestamp' . $sortFlag );
|
|
|
|
|
if ( !is_null( $params['user'] ) ) {
|
|
|
|
|
$this->addOption( 'USE INDEX', array( 'image' => 'img_usertext_timestamp' ) );
|
|
|
|
|
} else {
|
|
|
|
|
$this->addOption( 'USE INDEX', array( 'image' => 'img_timestamp' ) );
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
$this->addOption( 'ORDER BY', 'img_name' . $sortFlag );
|
|
|
|
|
}
|
2008-03-17 09:16:38 +00:00
|
|
|
|
2010-01-11 15:55:52 +00:00
|
|
|
$res = $this->select( __METHOD__ );
|
2008-03-17 09:16:38 +00:00
|
|
|
|
* API: BREAKING CHANGE: (bug 11430) Return fewer results than the limit in some cases to prevent running out of memory
* This means queries could possibly return fewer results than the limit and still set a query-continue
* Add iicontinue, rvcontinue, cicontinue, incontinue, amfrom to faciliate query-continue for these modules
* Implemented by blocking additions to the ApiResult object if they would make it too large
** Important things like query-continue values and warnings are exempt from this check
** RSS feeds and exported XML are also exempted (size-checking them would be too messy)
** Result size is checked against $wgAPIMaxResultSize, which defaults to 8 MB
For those who really care, per-file details follow:
ApiResult.php:
* Introduced ApiResult::$mSize which keeps track of the result size.
* Introduced ApiResult::size() which calculates an array's size
(which is the sum of the strlen()s of its elements).
* ApiResult::addValue() now checks that the result size stays below
$wgAPIMaxResultSize. If the item won't fit, it won't be added and addValue()
will return false. Callers should check the return value and set a
query-continue if it's false.
* Closed the back door that is ApiResult::getData(): callers can't manipulate
the data array directly anymore so they can't bypass the result size limit.
* Added ApiResult::setIndexedTagName_internal() which will call
setIndexedTagName() on an array already in the result. This is needed for the
'new' order of adding results, which means addValue()ing one result at a time
until you hit the limit or run out, then calling this function to set the tag
name.
* Added ApiResult::disableSizeCheck() and enableSizeCheck() which disable and
enable size checking in addValue(). This is used for stuff like query-continue
elements and warnings which shouldn't count towards the result size.
* Added ApiResult::unsetValue() which removes an element from the result and
decreases $mSize.
ApiBase.php:
* Like ApiResult::getData(), ApiBase::getResultData() no longer returns a
reference.
* Use ApiResult::disableSizeCheck() in ApiBase::setWarning()
ApiQueryBase.php:
* Added ApiQueryBase::addPageSubItem(), which adds page subitems one item
at a time.
* addPageSubItem() and addPageSubItems() now return whether the subitem
fit in the result.
* Use ApiResult::disableSizeCheck() in setContinueEnumParameter()
ApiMain.php:
* Use ApiResult::disableSizeCheck() in ApiMain::substituteResultWithError()
* Use getParameter() rather than $mRequest to obtain requestid
DefaultSettings.php:
* Added $wgAPIMaxResultSize, with a default value of 8 MB
ApiQuery*.php:
* Added results one at a time, and set a query-continue if the result is full.
ApiQueryLangLinks.php and friends:
* Migrated from addPageSubItems() to addPageSubItem(). This eliminates the
need for $lastId.
ApiQueryAllLinks.php, ApiQueryWatchlist.php, ApiQueryAllimages.php, ApiQuerySearch.php:
* Renamed $data to something more appropriate ($pageids, $ids or $titles)
ApiQuerySiteinfo.php:
* Abuse siprop as a query-continue parameter and set it to all props that
couldn't be processed.
ApiQueryRandom.php:
* Doesn't do continuations, because the result is supposed to be random.
* Be smart enough to not run the second query if the results of the first
didn't fit.
ApiQueryImageInfo.php, ApiQueryRevisions.php, ApiQueryCategoryInfo.php, ApiQueryInfo.php:
* Added continue parameter which basically skips the first so many items
ApiQueryBacklinks.php:
* Throw the result in a big array first and addValue() that one element at a time if necessary
** This is necessary because the results aren't retrieved in order
* Introduced $this->pageMap to map namespace and title to page ID
* Rewritten extractRowInfo() and extractRedirRowInfo() a little
* Declared all private member variables explicitly
ApiQueryDeletedrevs.php:
* Use a pagemap just like in Backlinks
* Introduce fake page IDs and keep track of them so we know where to add what
** This doesn't change the output format, because the fake page IDs start at 0 and are consecutive
ApiQueryAllmessages.php:
* Add amfrom to facilitate query-continue
ApiQueryUsers.php:
* Rewrite: put the getOtherUsersInfo() code in execute()
2009-02-05 14:30:59 +00:00
|
|
|
$titles = array();
|
2008-03-17 09:16:38 +00:00
|
|
|
$count = 0;
|
2008-05-20 14:32:52 +00:00
|
|
|
$result = $this->getResult();
|
2010-06-20 18:48:34 +00:00
|
|
|
foreach ( $res as $row ) {
|
2010-01-11 15:55:52 +00:00
|
|
|
if ( ++ $count > $limit ) {
|
2008-03-17 09:16:38 +00:00
|
|
|
// We've reached the one extra which shows that there are additional pages to be had. Stop here...
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
if ( $params['sort'] == 'name' ) {
|
|
|
|
|
$this->setContinueEnumParameter( 'continue', $row->img_name );
|
|
|
|
|
} else {
|
|
|
|
|
$this->setContinueEnumParameter( 'start', wfTimestamp( TS_ISO_8601, $row->img_timestamp ) );
|
|
|
|
|
}
|
2008-03-17 09:16:38 +00:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2010-01-11 15:55:52 +00:00
|
|
|
if ( is_null( $resultPageSet ) ) {
|
2008-05-16 21:25:13 +00:00
|
|
|
$file = $repo->newFileFromRow( $row );
|
2010-01-11 15:55:52 +00:00
|
|
|
$info = array_merge( array( 'name' => $row->img_name ),
|
|
|
|
|
ApiQueryImageInfo::getInfo( $file, $prop, $result ) );
|
2011-07-17 17:02:06 +00:00
|
|
|
self::addTitleInfo( $info, $file->getTitle() );
|
|
|
|
|
|
2010-01-11 15:55:52 +00:00
|
|
|
$fit = $result->addValue( array( 'query', $this->getModuleName() ), null, $info );
|
|
|
|
|
if ( !$fit ) {
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
if ( $params['sort'] == 'name' ) {
|
|
|
|
|
$this->setContinueEnumParameter( 'continue', $row->img_name );
|
|
|
|
|
} else {
|
|
|
|
|
$this->setContinueEnumParameter( 'start', wfTimestamp( TS_ISO_8601, $row->img_timestamp ) );
|
|
|
|
|
}
|
* API: BREAKING CHANGE: (bug 11430) Return fewer results than the limit in some cases to prevent running out of memory
* This means queries could possibly return fewer results than the limit and still set a query-continue
* Add iicontinue, rvcontinue, cicontinue, incontinue, amfrom to faciliate query-continue for these modules
* Implemented by blocking additions to the ApiResult object if they would make it too large
** Important things like query-continue values and warnings are exempt from this check
** RSS feeds and exported XML are also exempted (size-checking them would be too messy)
** Result size is checked against $wgAPIMaxResultSize, which defaults to 8 MB
For those who really care, per-file details follow:
ApiResult.php:
* Introduced ApiResult::$mSize which keeps track of the result size.
* Introduced ApiResult::size() which calculates an array's size
(which is the sum of the strlen()s of its elements).
* ApiResult::addValue() now checks that the result size stays below
$wgAPIMaxResultSize. If the item won't fit, it won't be added and addValue()
will return false. Callers should check the return value and set a
query-continue if it's false.
* Closed the back door that is ApiResult::getData(): callers can't manipulate
the data array directly anymore so they can't bypass the result size limit.
* Added ApiResult::setIndexedTagName_internal() which will call
setIndexedTagName() on an array already in the result. This is needed for the
'new' order of adding results, which means addValue()ing one result at a time
until you hit the limit or run out, then calling this function to set the tag
name.
* Added ApiResult::disableSizeCheck() and enableSizeCheck() which disable and
enable size checking in addValue(). This is used for stuff like query-continue
elements and warnings which shouldn't count towards the result size.
* Added ApiResult::unsetValue() which removes an element from the result and
decreases $mSize.
ApiBase.php:
* Like ApiResult::getData(), ApiBase::getResultData() no longer returns a
reference.
* Use ApiResult::disableSizeCheck() in ApiBase::setWarning()
ApiQueryBase.php:
* Added ApiQueryBase::addPageSubItem(), which adds page subitems one item
at a time.
* addPageSubItem() and addPageSubItems() now return whether the subitem
fit in the result.
* Use ApiResult::disableSizeCheck() in setContinueEnumParameter()
ApiMain.php:
* Use ApiResult::disableSizeCheck() in ApiMain::substituteResultWithError()
* Use getParameter() rather than $mRequest to obtain requestid
DefaultSettings.php:
* Added $wgAPIMaxResultSize, with a default value of 8 MB
ApiQuery*.php:
* Added results one at a time, and set a query-continue if the result is full.
ApiQueryLangLinks.php and friends:
* Migrated from addPageSubItems() to addPageSubItem(). This eliminates the
need for $lastId.
ApiQueryAllLinks.php, ApiQueryWatchlist.php, ApiQueryAllimages.php, ApiQuerySearch.php:
* Renamed $data to something more appropriate ($pageids, $ids or $titles)
ApiQuerySiteinfo.php:
* Abuse siprop as a query-continue parameter and set it to all props that
couldn't be processed.
ApiQueryRandom.php:
* Doesn't do continuations, because the result is supposed to be random.
* Be smart enough to not run the second query if the results of the first
didn't fit.
ApiQueryImageInfo.php, ApiQueryRevisions.php, ApiQueryCategoryInfo.php, ApiQueryInfo.php:
* Added continue parameter which basically skips the first so many items
ApiQueryBacklinks.php:
* Throw the result in a big array first and addValue() that one element at a time if necessary
** This is necessary because the results aren't retrieved in order
* Introduced $this->pageMap to map namespace and title to page ID
* Rewritten extractRowInfo() and extractRedirRowInfo() a little
* Declared all private member variables explicitly
ApiQueryDeletedrevs.php:
* Use a pagemap just like in Backlinks
* Introduce fake page IDs and keep track of them so we know where to add what
** This doesn't change the output format, because the fake page IDs start at 0 and are consecutive
ApiQueryAllmessages.php:
* Add amfrom to facilitate query-continue
ApiQueryUsers.php:
* Rewrite: put the getOtherUsersInfo() code in execute()
2009-02-05 14:30:59 +00:00
|
|
|
break;
|
|
|
|
|
}
|
2008-03-17 09:16:38 +00:00
|
|
|
} else {
|
2012-06-24 19:50:10 +00:00
|
|
|
$titles[] = Title::makeTitle( NS_FILE, $row->img_name );
|
2008-03-17 09:16:38 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2010-01-11 15:55:52 +00:00
|
|
|
if ( is_null( $resultPageSet ) ) {
|
|
|
|
|
$result->setIndexedTagName_internal( array( 'query', $this->getModuleName() ), 'img' );
|
2008-03-17 09:16:38 +00:00
|
|
|
} else {
|
2010-01-11 15:55:52 +00:00
|
|
|
$resultPageSet->populateFromTitles( $titles );
|
2008-03-17 09:16:38 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function getAllowedParams() {
|
|
|
|
|
return array (
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
'sort' => array(
|
|
|
|
|
ApiBase::PARAM_DFLT => 'name',
|
|
|
|
|
ApiBase::PARAM_TYPE => array(
|
|
|
|
|
'name',
|
|
|
|
|
'timestamp'
|
|
|
|
|
)
|
|
|
|
|
),
|
|
|
|
|
'dir' => array(
|
|
|
|
|
ApiBase::PARAM_DFLT => 'ascending',
|
|
|
|
|
ApiBase::PARAM_TYPE => array(
|
|
|
|
|
// sort=name
|
|
|
|
|
'ascending',
|
|
|
|
|
'descending',
|
|
|
|
|
// sort=timestamp
|
|
|
|
|
'newer',
|
|
|
|
|
'older'
|
|
|
|
|
)
|
|
|
|
|
),
|
2008-03-17 09:16:38 +00:00
|
|
|
'from' => null,
|
2010-08-06 18:58:10 +00:00
|
|
|
'to' => null,
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
'continue' => null,
|
|
|
|
|
'start' => array(
|
|
|
|
|
ApiBase::PARAM_TYPE => 'timestamp'
|
|
|
|
|
),
|
|
|
|
|
'end' => array(
|
|
|
|
|
ApiBase::PARAM_TYPE => 'timestamp'
|
|
|
|
|
),
|
|
|
|
|
'prop' => array(
|
|
|
|
|
ApiBase::PARAM_TYPE => ApiQueryImageInfo::getPropertyNames( $this->propertyFilter ),
|
|
|
|
|
ApiBase::PARAM_DFLT => 'timestamp|url',
|
|
|
|
|
ApiBase::PARAM_ISMULTI => true
|
|
|
|
|
),
|
2008-03-17 09:16:38 +00:00
|
|
|
'prefix' => null,
|
2010-02-24 13:34:11 +00:00
|
|
|
'minsize' => array(
|
|
|
|
|
ApiBase::PARAM_TYPE => 'integer',
|
2008-04-14 07:45:50 +00:00
|
|
|
),
|
2010-02-24 13:34:11 +00:00
|
|
|
'maxsize' => array(
|
|
|
|
|
ApiBase::PARAM_TYPE => 'integer',
|
2008-03-17 18:51:32 +00:00
|
|
|
),
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
'sha1' => null,
|
|
|
|
|
'sha1base36' => null,
|
|
|
|
|
'user' => array(
|
|
|
|
|
ApiBase::PARAM_TYPE => 'user'
|
|
|
|
|
),
|
|
|
|
|
'filterbots' => array(
|
|
|
|
|
ApiBase::PARAM_DFLT => 'all',
|
|
|
|
|
ApiBase::PARAM_TYPE => array(
|
|
|
|
|
'all',
|
|
|
|
|
'bots',
|
|
|
|
|
'nobots'
|
|
|
|
|
)
|
|
|
|
|
),
|
|
|
|
|
'mime' => null,
|
2010-02-24 13:34:11 +00:00
|
|
|
'limit' => array(
|
|
|
|
|
ApiBase::PARAM_DFLT => 10,
|
|
|
|
|
ApiBase::PARAM_TYPE => 'limit',
|
|
|
|
|
ApiBase::PARAM_MIN => 1,
|
|
|
|
|
ApiBase::PARAM_MAX => ApiBase::LIMIT_BIG1,
|
|
|
|
|
ApiBase::PARAM_MAX2 => ApiBase::LIMIT_BIG2
|
2008-03-17 09:16:38 +00:00
|
|
|
),
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function getParamDescription() {
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
$p = $this->getModulePrefix();
|
2010-02-24 13:34:11 +00:00
|
|
|
return array(
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
'sort' => 'Property to sort by',
|
2008-03-17 09:16:38 +00:00
|
|
|
'dir' => 'The direction in which to list',
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
'from' => "The image title to start enumerating from. Can only be used with {$p}sort=name",
|
|
|
|
|
'to' => "The image title to stop enumerating at. Can only be used with {$p}sort=name",
|
|
|
|
|
'continue' => 'When more results are available, use this to continue',
|
|
|
|
|
'start' => "The timestamp to start enumerating from. Can only be used with {$p}sort=timestamp",
|
|
|
|
|
'end' => "The timestamp to end enumerating. Can only be used with {$p}sort=timestamp",
|
|
|
|
|
'prop' => ApiQueryImageInfo::getPropertyDescriptions( $this->propertyFilter ),
|
|
|
|
|
'prefix' => "Search for all image titles that begin with this value. Can only be used with {$p}sort=name",
|
2008-03-17 09:16:38 +00:00
|
|
|
'minsize' => 'Limit to images with at least this many bytes',
|
|
|
|
|
'maxsize' => 'Limit to images with at most this many bytes',
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
'sha1' => "SHA1 hash of image. Overrides {$p}sha1base36",
|
2008-03-17 18:51:32 +00:00
|
|
|
'sha1base36' => 'SHA1 hash of image in base 36 (used in MediaWiki)',
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
'user' => "Only return files uploaded by this user. Can only be used with {$p}sort=timestamp. Cannot be used together with {$p}filterbots",
|
|
|
|
|
'filterbots' => "How to filter files uploaded by bots. Can only be used with {$p}sort=timestamp. Cannot be used together with {$p}user",
|
2011-03-13 22:23:57 +00:00
|
|
|
'mime' => 'What MIME type to search for. e.g. image/jpeg. Disabled in Miser Mode',
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
'limit' => 'How many images in total to return',
|
2008-03-17 09:16:38 +00:00
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
2012-07-13 15:25:22 +00:00
|
|
|
private $propertyFilter = array( 'archivename', 'thumbmime' );
|
2011-03-21 23:51:26 +00:00
|
|
|
|
Added result properties to action=paraminfo
Added information about the properties of the results of API calls
to action=paraminfo, including information about "property groups":
what should the prop parameter be set to to get that property.
Uses the same format for types as parameters already do.
The output format of some modules doesn't fit this, so the result
properties for them weren't added, or only partially.
Partially implemented modules:
* expandtemplates:
parsetree is in its own tag
* protect, allusers, backlinks, deletedrevs, info, imageinfo,
logevents, querypage, recentchanges, revisions, searchinfo,
usercontribs, userinfo, users, watchlist, upload:
response with partially complex structure
Not implemented modules:
* feedcontributions, feedwatchlist, opensearch, rds:
non-standard reponse
* help:
error is normal response; not very useful for automated tools anyway
* paraminfo, parse, pageprops, siteinfo, userrights:
response with complex structure
Change-Id: Iff2a9bef79f994e73eef3062b4dd5461bff968ab
2012-05-02 15:00:30 +00:00
|
|
|
public function getResultProperties() {
|
|
|
|
|
return array_merge(
|
|
|
|
|
array(
|
|
|
|
|
'' => array(
|
|
|
|
|
'name' => 'string',
|
|
|
|
|
'ns' => 'namespace',
|
|
|
|
|
'title' => 'string'
|
|
|
|
|
)
|
|
|
|
|
),
|
|
|
|
|
ApiQueryImageInfo::getResultPropertiesFiltered( $this->propertyFilter )
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
2008-03-17 09:16:38 +00:00
|
|
|
public function getDescription() {
|
|
|
|
|
return 'Enumerate all images sequentially';
|
|
|
|
|
}
|
2010-02-24 13:34:11 +00:00
|
|
|
|
2010-02-13 00:48:31 +00:00
|
|
|
public function getPossibleErrors() {
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
$p = $this->getModulePrefix();
|
2010-02-13 00:48:31 +00:00
|
|
|
return array_merge( parent::getPossibleErrors(), array(
|
|
|
|
|
array( 'code' => 'params', 'info' => 'Use "gaifilterredir=nonredirects" option instead of "redirects" when using allimages as a generator' ),
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
array( 'code' => 'badparams', 'info' => "Parameter'{$p}start' can only be used with {$p}sort=timestamp" ),
|
|
|
|
|
array( 'code' => 'badparams', 'info' => "Parameter'{$p}end' can only be used with {$p}sort=timestamp" ),
|
|
|
|
|
array( 'code' => 'badparams', 'info' => "Parameter'{$p}user' can only be used with {$p}sort=timestamp" ),
|
|
|
|
|
array( 'code' => 'badparams', 'info' => "Parameter'{$p}filterbots' can only be used with {$p}sort=timestamp" ),
|
|
|
|
|
array( 'code' => 'badparams', 'info' => "Parameter'{$p}from' can only be used with {$p}sort=name" ),
|
|
|
|
|
array( 'code' => 'badparams', 'info' => "Parameter'{$p}to' can only be used with {$p}sort=name" ),
|
|
|
|
|
array( 'code' => 'badparams', 'info' => "Parameter'{$p}prefix' can only be used with {$p}sort=name" ),
|
|
|
|
|
array( 'code' => 'badparams', 'info' => "Parameters '{$p}user' and '{$p}filterbots' cannot be used together" ),
|
2010-02-13 00:48:31 +00:00
|
|
|
array( 'code' => 'unsupportedrepo', 'info' => 'Local file repository does not support querying all images' ),
|
2011-06-05 23:44:37 +00:00
|
|
|
array( 'code' => 'mimesearchdisabled', 'info' => 'MIME search disabled in Miser Mode' ),
|
2011-05-15 13:16:13 +00:00
|
|
|
array( 'code' => 'invalidsha1hash', 'info' => 'The SHA1 hash provided is not valid' ),
|
|
|
|
|
array( 'code' => 'invalidsha1base36hash', 'info' => 'The SHA1Base36 hash provided is not valid' ),
|
2010-02-13 00:48:31 +00:00
|
|
|
) );
|
|
|
|
|
}
|
2008-03-17 09:16:38 +00:00
|
|
|
|
2011-08-17 22:24:21 +00:00
|
|
|
public function getExamples() {
|
2010-02-24 13:34:11 +00:00
|
|
|
return array(
|
2011-12-27 16:22:35 +00:00
|
|
|
'api.php?action=query&list=allimages&aifrom=B' => array(
|
|
|
|
|
'Simple Use',
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
'Show a list of files starting at the letter "B"',
|
|
|
|
|
),
|
|
|
|
|
'api.php?action=query&list=allimages&aiprop=user|timestamp|url&aisort=timestamp&aidir=older' => array(
|
|
|
|
|
'Simple Use',
|
|
|
|
|
'Show a list of recently uploaded files similar to Special:NewFiles',
|
2011-12-27 16:22:35 +00:00
|
|
|
),
|
|
|
|
|
'api.php?action=query&generator=allimages&gailimit=4&gaifrom=T&prop=imageinfo' => array(
|
|
|
|
|
'Using as Generator',
|
(bug 27202) Add timestamp sort to list=allimages
New parameter 'sort' that defaults to 'name' so if not specified it will
act exactly as before.
Changes in the access to $params['dir'] to a boolean variable
$ascendingOrder in a try to be more meaningful.
Some existing filtering parameters are mutually exclusive with new ones.
The reason is because the table is sorted by name, as primary key, while
sorting by timestamp use the timestamp or usertext_timestamp index which
is not the primary key, thus filtering and ordering by different indices
doesn't make an efficient index usage.
Exceptions are:
* mime: disabled in Miser Mode
* size: although there's apparently no use for this when sorting by
timestamp, there's an index on that and the EXPLAIN doesn't use filesort
algorythm (unlike other combinations):
EXPLAIN
select img_name, img_user_text, img_timestamp
from image
where img_size>=1000 and img_size<=20000
and img_timestamp > '20120916153705'
ORDER BY img_timestamp\G
* Same for sha1 (see comment on Patchset 1)
In function run:
* Added USE INDEX query options when sort=timestamp to ensure the proper
index is being used.
* Table selection and result fields moved at top, then filter parameters,
and finally order by and options.
Parameter description and definition sorted by purpose: sort and dir
first, then pagination, result fields, filters and limit.
Change-Id: Ide2ff3dbc3e617e749685d558444854617535bab
2012-09-16 20:00:37 +00:00
|
|
|
'Show info about 4 files starting at the letter "T"',
|
2011-12-27 16:22:35 +00:00
|
|
|
),
|
2008-03-17 09:16:38 +00:00
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
2011-07-17 17:02:06 +00:00
|
|
|
public function getHelpUrls() {
|
2011-11-28 15:43:11 +00:00
|
|
|
return 'https://www.mediawiki.org/wiki/API:Allimages';
|
2011-07-17 17:02:06 +00:00
|
|
|
}
|
2008-03-17 09:16:38 +00:00
|
|
|
}
|