Actually, the more I think about it, this would result in an
inadvertent API change. Right now, if you have a SQL syntax error, the
error would be thrown by ->execute(). But with this change, the error
would be thrown by ->prepare(). So code that currently wraps execute()
but not prepare() with a try{}catch(){} would start failing.Is this a show stopper? Or is restoring the "proper" execution path worth it? >From what I can see in the few open source drivers I looked at, it won't be an issue (Drupal, Doctrine, Zend, Lithium, etc)... Thanks, Anthony On Thu, Jun 21, 2012 at 10:19 PM, Anthony Ferrara <ircmax...@gmail.com> wrote: > As it turns out, the testing of this is far more difficult than I > originally suspected. Not because it fails, but because emulated > queries were behaving badly to begin with, so a number of tests were > testing bad behavior. For example, bug 44327: > > https://github.com/ircmaxell/php-src/blob/master/ext/pdo_mysql/tests/bug44327.phpt > > It runs the following code: > > $stmt = $db->prepare('foo'); > @$stmt->execute(); > $row = $stmt->fetch(); > var_dump($row->queryString); > > And expects: > > Notice: Trying to get property of non-object in %s on line %d > NULL > > Whereas the proper behavior is for the syntax error to be thrown from > `prepare`. PDO emulation doesn't do that, because it doesn't parse > until `execute`, hence the error delays until that point. > > When I run it, I get: > > Warning: PDO::prepare(): SQLSTATE[42000]: Syntax error or access > violation: 1064 You have an error in your SQL syntax; check the manual > that corresponds to your MySQL server version for the right syntax to > use near 'foo' at line 1 in %s on line %d > > Because it's sent back at prepare() instead of at execute (and prepare > doesn't have an @). > > There are at least a few more failures of this nature. > > To fix this, is going to take some significant refactoring of a number > of tests. Plus, without this patch, I'm still getting 2 warnings and 6 > failures: > > ===================================================================== > Number of tests : 166 157 > Tests skipped : 9 ( 5.4%) -------- > Tests warned : 2 ( 1.2%) ( 1.3%) > Tests failed : 6 ( 3.6%) ( 3.8%) > Expected fail : 1 ( 0.6%) ( 0.6%) > Tests passed : 148 ( 89.2%) ( 94.3%) > --------------------------------------------------------------------- > Time taken : 43 seconds > ===================================================================== > > ===================================================================== > EXPECTED FAILED TEST SUMMARY > --------------------------------------------------------------------- > PECL Bug #7976 (Calling stored procedure several times) > [ext/pdo_mysql/tests/bug_pecl_7976.phpt] XFAIL REASON: Works with > mysqlnd. It is not supported by libmysql. For libmysql is good enough > to see no crash. > ===================================================================== > > ===================================================================== > FAILED TEST SUMMARY > --------------------------------------------------------------------- > Bug #39858 (Lost connection to MySQL server during query by a repeated > call stored proced) [ext/pdo_mysql/tests/bug_39858.phpt] > PDO MySQL Bug #41997 (stored procedure call returning single rowset > blocks future queries) [ext/pdo_mysql/tests/bug_41997.phpt] > MySQL PDO->__construct() - Generic + DSN > [ext/pdo_mysql/tests/pdo_mysql___construct.phpt] > MySQL PDO->exec(), affected rows > [ext/pdo_mysql/tests/pdo_mysql_exec_load_data.phpt] > MySQL PDOStatement->nextRowSet() > [ext/pdo_mysql/tests/pdo_mysql_stmt_nextrowset.phpt] > MySQL Prepared Statements and different column counts > [ext/pdo_mysql/tests/pdo_mysql_stmt_variable_columncount.phpt] > ===================================================================== > > ===================================================================== > WARNED TEST SUMMARY > --------------------------------------------------------------------- > Bug #44454 (Unexpected exception thrown in foreach() statement) > [ext/pdo_mysql/tests/bug_44454.phpt] (warn: XFAIL section but test > passes) > MySQL PDO->prepare(), emulated PS > [ext/pdo_mysql/tests/pdo_mysql_prepare_emulated.phpt] (warn: XFAIL > section but test passes) > ===================================================================== > > Whereas with the patch, there are a few more failures: > > ===================================================================== > Number of tests : 166 157 > Tests skipped : 9 ( 5.4%) -------- > Tests warned : 2 ( 1.2%) ( 1.3%) > Tests failed : 18 ( 10.8%) ( 11.5%) > Expected fail : 1 ( 0.6%) ( 0.6%) > Tests passed : 136 ( 81.9%) ( 86.6%) > --------------------------------------------------------------------- > Time taken : 53 seconds > ===================================================================== > > > So to do this, I'd need to fix those as well... (at least all but the XFAIL) > > So I'm going to keep at it, but it's going to take a while (and would > like some insight into if this is the best approach to fixing the > tests)... > > Thanks, > > Anthony > > On Thu, Jun 21, 2012 at 2:57 AM, Ulf Wendel <ulf.wen...@phpdoc.de> wrote: >> Am 20.06.2012 08:39, schrieb Pierre Joye: >> >>> hi Chris, >>> >>> On Tue, Jun 19, 2012 at 11:45 PM, Christopher Jones >>> <christopher.jo...@oracle.com> wrote: >>> >>>> We should take this offline - I can see cases where I'd strongly >>>> disagree. >>> >>> >>> I see no reason to move a discussion offline or off list, this is a >>> topic that interests many other readers or developers. >> >> >> Agreed. There was enough trouble around PDO and discussions going on in the >> hidden. >> >> However, this does not impact the original topic. >> >> Ulf >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
