Last modified: 2013-10-23 18:17:23 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T40444, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 38444 - db functions don't handle options sanely
db functions don't handle options sanely
Status: RESOLVED DUPLICATE of bug 36568
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
1.18.x
All All
: Unprioritized normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-17 17:44 UTC by Nischay Nahata
Modified: 2013-10-23 18:17 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Nischay Nahata 2012-07-17 17:44:57 UTC
In Database.php Select() and SelectRow() accept parameter options as string as well as array but doesn't handle strings well

SelectRow() accepts $options as string and does 
		$options['LIMIT'] = 1;
and then later selectSQLText() does
                $options = (array)$options;
which is strange.

String type should not be supported or handled with care.
Comment 1 Sam Reed (reedy) 2012-07-17 18:43:48 UTC
	public function selectRow( $table, $vars, $conds, $fname = 'DatabaseBase::selectRow',
		$options = array(), $join_conds = array() )
	{
		$options = (array)$options;
Comment 2 Alexandre Emsenhuber [IAlex] 2012-07-18 07:35:14 UTC

*** This bug has been marked as a duplicate of bug 36568 ***
Comment 3 Nischay Nahata 2012-07-18 07:47:02 UTC
(In reply to comment #2)
> 
> *** This bug has been marked as a duplicate of bug 36568 ***

I don't think its the same bug. The problem I reported is that string shouldn't be accepted as options
Comment 4 Alexandre Emsenhuber [IAlex] 2012-07-18 07:52:06 UTC
Strings are accepted as $options since many versions, doing the opposite would create backward compatibility problems with extensions using that for no benefit at all.

The cast to array simply does the following:
if ( is_string( $options ) ) {
    $options = array( $options );
}
I don't see where there is a problem with this.
Comment 5 Alexandre Emsenhuber [IAlex] 2012-07-18 08:14:46 UTC
I saw your comment on Gerrit, the point of this is not to allow such constructions, since you cannot pass array( 'ORDER BY `smw` ' ) as $options. This is only intended for already-defined options that do not require a value, see $noKeyOptions in DatabaseBase::makeSelectOptions() (currently lines 1219 to 1262 of includes/db/Database.php on master).
Comment 6 Nischay Nahata 2012-07-18 08:41:22 UTC
I think its better to depreciate strings, as only no key options when passed as strings are turned into SQL, for ex:

options = 'DISTINCT' will be processed into SQL but options = 'ORDER BY `smw`' wouldn't be processed at all. However, the extension code has a wrong notion of this, I identified this only when I saw my output wasn't ORDERed. 

May be a better solution is to just allow arrays, for options like DISTINCT one could pass array('DISTICT' => true)
Comment 7 Marcin Cieślak 2012-07-18 09:16:53 UTC
isn't array('ORDER BY', 'smw') going to work?
Comment 8 Marcin Cieślak 2012-07-18 09:17:13 UTC
er, array('ORDER BY' => 'smw')
Comment 9 Nischay Nahata 2012-07-18 09:38:10 UTC
(In reply to comment #8)
> er, array('ORDER BY' => 'smw')
(In reply to comment #7)
> isn't array('ORDER BY', 'smw') going to work?

It will, but the docs @param $options string|array give a wrong notion that 'ORDER BY `smw`' will work too.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links