The issue is essentially the same as described here for db_result: http://drupal.org/node/98988
mysql, pg, sqlite, etc. functions in PHP all return FALSE if there is there is no data, but the mysqli functions return NULL.
This inconsistency makes it difficult to actually do comparisons against the return value.
see:
http://us.php.net/manual/en/function.mysqli-fetch-array.php
http://us.php.net/manual/en/function.mysql-fetch-array.php
http://us.php.net/manual/en/function.pg-fetch-object.php
chx confirmed this in the C code:
http://cvs.php.net/viewvc.cgi/php-src/ext/mysqli/mysqli.c?revision=1.106...
if (!(row = mysql_fetch_row(result))) {
RETURN_NULL();
}
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | mysqli_unannoy_3.patch | 4.75 KB | pwolanin |
| #2 | mysqli_unannoy_2.patch | 58 bytes | pwolanin |
| #1 | mysqli_unannoy.patch | 716 bytes | chx |
Comments
Comment #1
chx commentedComment #2
pwolanin commentedthis patch updates the doxygen comments so that it's clear that the return value for no data is expected to be FALSE. This may be important guidance if others are developing other db abstractions (e.g. sqlite, oracle, etc).
Also, I find
return $returnhard to parse, so this renames these variables too.Comment #3
pwolanin commentedoops - ignore the previous file...
Comment #4
webernet commentedPatch looks good, tested OK, and it fixes some minor bugs that have shown up in the menu system.
Comment #5
pwolanin commentedthis really needs to get in soon, since it's holding up testing of other patches with PHP 5.2
Comment #6
dries commentedAt one point (not now), we might want to consider nuking db_fetch_array(). For core:
$ grep -r db_fetch_array * | wc -l 60 $ grep -r db_fetch_object * | wc -l 272pwolanin: what other patches are you referring too?
Comment #7
dries commentedNo reason not to commit this patch. Committed.
Comment #8
(not verified) commented