internals:pdo:brainstorming

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
internals:pdo:brainstorming [2009/12/01 20:16] – Cross connection transactions lscesinternals:pdo:brainstorming [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 21: Line 21:
   * document finally remaining FETCH constants like FETCH_KEY_VALUE, FETCH_FUNC   * document finally remaining FETCH constants like FETCH_KEY_VALUE, FETCH_FUNC
   * better document fetchAll() constants   * better document fetchAll() constants
 +  * add support table for ATTR_FETCH_TABLE_NAMES (sqlite still has a pending patch)
 +  * ATTR_FETCH_CATALOG_NAMES unused?
 +  * FETCH_FUNC should mention it is only allowed with fetchAll
 +  * Mention PDOStatement can be used in foreach, but won't call an overloaded fetch as the internal iterator is used.
  
 === Parameter binding & explicit data type set === === Parameter binding & explicit data type set ===
Line 48: Line 52:
 see [[http://news.php.net/php.pdo/268]] see [[http://news.php.net/php.pdo/268]]
  
-For features not yet finalized: +<del>For features not yet finalized: 
-see [[http://news.php.net/php.pdo/286]]+see [[http://news.php.net/php.pdo/286]] PDO_Driver::getNative()::asyncQuery(); </del>
  
-PDO_Driver::getNative()::asyncQuery();+Most drivers allow some kind of async query except MySQL, 
 +additional connections could be created to allow concurrent queries.
  
 +see [[http://news.php.net/php.pdo/330]]
  
 === PDO Persistent Connections === === PDO Persistent Connections ===
Line 71: Line 77:
 === XML Support === === XML Support ===
 see [[http://news.php.net/php.pdo/233]] see [[http://news.php.net/php.pdo/233]]
 +
 +=== Transaction ===
 +PDO transaction object
 +see [[http://news.php.net/php.pdo/322]]
 +
 +Possible problems:
 +  * error handling
 +  * nested transaction (emulation)
 +
 +
 +=== Parameter Binding without Preparing ===
 +Allow prepareless binding of parameters for queries, like PostgreSQL PQexecParams.
 +  * queryParam() ?
 +
 +
  
  
Line 98: Line 119:
 for all bindValue/bindParam/execute input for all bindValue/bindParam/execute input
  
 +
 +=== Why do we need improvements to binding? ===
 +Currently has no standard or agreement how parameters like PDO_PARAM_BOOL should be handled on the user side or the internal PDO drivers.
 +There are even disagreements between PDOs code comment, explaining PDO_PARAM_INT is the internal PHP type, and the manual telling us it's the database native type.
 +The result is there is no agreement how even simple parameters should be bound properly and so each driver does it's own guessing how parameters are handled.
 +
 +=== The current situation ===
 +There are two basic categories how currently driver handle bindings:
 +Trying to guess the right meaning by the zval type (even if PDO is told to use a certain type)
 +Or try to convert it to string and let the database handle most stuff.
 +
 +So each driver needs some special care when binding, generally for PDO mysql you need to cast to the right type as setting the binding type constant has no affect.
 +The PDO core already convert doubles to string in the pdo_stmt.c really_register_bound_param function.
 +The current code may or may not separate the zval, so the contents of the variable may change after a successful binding or executing of a statement.
 +
 +
 +=== Proposal ===
 +PDO should enforce the zval type in really_register_bound_param so drivers will get a pre-filtered parameters
 +
 +This would mean: 
 +PDO_PARAM_* will map to internal PHP types, as the code comments in the enum pdo_param_type already tells us.
 +PDO_PARAM_ZVAL will be introduced to user space to let zvals pass directly.
 +
 +If the zval type isn't right, PDO should do a zval separation before converting so no user space variables will be altered.
 +
 +PDO_PARAM_DOUBLE should be introduced later to complete the current support.
 +
 +
 +=== Problems ===
 +PostgreSQL: Currently it's possible to pass a string like "NO" with PDO::PARAM_BOOL,
 +the string contents will be evaluated by the pdo driver, so "no" gets the equivalent of zend false.
 +
 +As soon as PDO Core enforces types and simply use convert_to_boolean bindValue(':foo', 'NO', PDO::PARAM_BOOL) would result into zend true, passed to pdo postgre it would store true! 
 +
 +But as bindValue defaults to PDO::PARAM_STR and so currently with PostgreSQL you don't need PDO::PARAM_BOOL the impact on current software shouldn't be big.
 +
 +
 +=== Workarounds ===
 +Possible workaround: A special convert_to_boolean function to support SQL FALSE and NO as zend false, however this would be unnatural to PHP core.
 +
 +
 +=== Matrix ===
 | zval/PDO           ^ PDO_PARAM_NULL  ^ PDO_PARAM_BOOL     ^ PDO_PARAM_INT     ^ PDO_PARAM_STR           ^ PDO_PARAM_LOB           ^ PDO_PARAM_AUTO (new)    ^ | zval/PDO           ^ PDO_PARAM_NULL  ^ PDO_PARAM_BOOL     ^ PDO_PARAM_INT     ^ PDO_PARAM_STR           ^ PDO_PARAM_LOB           ^ PDO_PARAM_AUTO (new)    ^
 ^ IS_NULL            | - no convert -  | SQL_NULL           | SQL_NULL          | SQL_NULL                | SQL_NULL                | SQL_NULL                | ^ IS_NULL            | - no convert -  | SQL_NULL           | SQL_NULL          | SQL_NULL                | SQL_NULL                | SQL_NULL                |
Line 114: Line 177:
 (3) Allowing streams (3) Allowing streams
  
-For compatibility the execute() function could be changed to PDO_PARAM_AUTO for less BC breaks.+For compatibility the execute() function could be changed to PDO_PARAM_ZVAL for less BC breaks on certain drivers.
internals/pdo/brainstorming.1259698585.txt.gz · Last modified: 2017/09/22 13:28 (external edit)