wikimedia-l | wikisource-l | meta | mediawiki | Phabricator | feedback

MySQL-specific hacks in the API code


#1

As Greg rightfully notices it seems that the API code has a couple of MySQL-specific hacks, judging just by looking at the comments:

saper@tools.wikimedia.pl $ git log -1 --oneline
0b4f6ba Merge "Add $wgSoftBlockRanges"
saper@tools.wikimedia.pl $ grep -Ri mysql api/*
api/ApiPageSet.php:		// It seems with a load of revision rows, MySQL gets upset
api/ApiQueryAllDeletedRevisions.php:		// only do it when sorting ASC (because MySQL apparently can't use an
api/ApiQueryAllPages.php:			// MySQL filesorts if we use a GROUP BY that works with the rules
api/ApiQueryAllPages.php:			if ( $dbType === 'mysql' || $dbType === 'sqlite' ) {
api/ApiQueryAllUsers.php:		# MySQL can't figure out that 'user_name' and 'qcc_title' are the same
api/ApiQueryBacklinksprop.php:		// MySQL's query planner screws up if we include a field in ORDER BY
api/ApiQueryBacklinksprop.php:		// MySQL's optimizer chokes if we have too many values in "$bl_title IN
api/ApiQueryBacklinksprop.php:		// MySQL (or at least 5.5.5-10.0.23-MariaDB) chooses a really bad query
api/ApiQueryCategoryMembers.php:			// This is needed because cl_type is an enum, and MySQL has
api/ApiQueryContributors.php:			'username' => 'MAX(rev_user_text)', // Non-MySQL databases don't like partial group-by
api/ApiQueryDeletedrevs.php:				// @todo Does this work on non-MySQL?
api/ApiQueryLinks.php:		// Here's some MySQL craziness going on: if you use WHERE foo='bar'
api/ApiQueryLinks.php:		// and later ORDER BY foo MySQL doesn't notice the ORDER BY is pointless
api/ApiQuerySearch.php:			// of the way we initially set up the MySQL fulltext-based

Inspired-by: http://pastie.org/10988359