getOne() produces a warning if the query returns no results.

[borb]

getOne() calls fetchInto() with an initialised $row containing null. If the query returns no results, $row is never populated with an array of results, and getOne() returns $row[0], which is both an array operation on something that isn't an array, and also an undefined value. In all cases, null is returned as the result of getOne(), even if the field contains null.

We can't fix the logic of returning null, but we can fix the invalid array access by checking if $row is_array() and $row[0] isset() before returning.

[ghost]

This is brilliantly complicated, much more than I had previously considered.

At the moment, this evades testing because when writing the stub driver for the unit tests, we wrote a perfect-world scenario which included checks to ensure we didn't send any more data when fetching a non-existant row.

We will have to look at the stub driver architecture to ensure that we reproduce what the real drivers actually do in order to validate that we can test this with real world scenarios.

[ghost]

This is not the bug we previously thought it was, and this bug definitely originates in PEAR DB beforehand.

The older DB_mysql driver, and reproduced in the PdoDriver, checks the result of the fetch from the database. The older driver did not consider that the result could be '0', and thus if you fetch from '0' the database, it will return 'null' in the getOne() call, which is annoying and should be fixed.

However, mysql_fetch_row would return false for no row, so we should fix the PdoDriver and DoctrineDbal drivers to correctly check the returned data so that we can legitimately send '0' back verbatim to the caller, and handle situations where there is no data to be returned (possibly returning null, possibly returning an Error instance with the correct error constant).

But I am taking this off of the 0.3.1 milestone because this is a pre-existing bug and thus is expected behaviour.