Request for Comments: PDO version 1 improvements
- Version: pre alpha 0.1
- Date: 2008-03-06
- Author: Lukas Smith email@example.com
- Status: Draft (Inactive)
This RFC aims to collect a set of ideas to improve PDO version 1. These ideas will hopefully end up in a set of concret feature requests and patches.
PDO is a thin layer above native RDBMS interfaces. As such its focused on providing a unified API on the PHP level without getting too much into SQL abstraction. PDO provides a framework to make the development of RDBMS specific drivers for PDO easier.
Why do we need improvements to PDO?
PDO has become the de-facto standard for the development of PHP libraries that interact with RDBMS. As such developers have come to expect that PDO minimizes any portability differences to a minimum, while accepting that PDO will not solve most issues in the differences of the actual SQL syntax.
A lot in PDO can be fixed without a new major version.
Proposal and Patch
- Convenience features
- Add a common syntax to specify the DSN along the lines of the PEAR DSN format
- Add ability to generate a properly quoted comma separated list to be embedded in a query inside an IN() clause (see implodeArray())
- Higher level emulation features
- Fix differences in behavior for data fetches (possibly add a compatibility mode in order to maintain BC)
- Add ability to manage connection session aspects like charset/collation, locale (datetime/currency format)
- Add limited sub select emulation (see subSelect())
- A class for administrative functionality which can come in handy for projects like phpMyAdmin. (possibly partially in userland)
- Nested transaction emulation via SAVEPOINTs
- Emulate scrollable cursors via buffered result sets
- Prepared statements
- Fix differences in when bind/prepare issues an exception for an invalid bound value/parameter.
- Add ability to bind short binary values
- Improve the prepared statement emulation parser to better deal with quoted strings that contain things that look like a placeholder
- Make it possible to disable parsing and rewriting of placeholders and require the use of the given native syntax (:name, $name, ? etc.)
- Fix the problems with ODBC prepared statements when executing procedures on all platforms.
- Add support for PDO::PARAM_CLOB and generally work harder on making the LOB behavior more similar across the drivers (see Bug 7943)
- Add support for datatypes like float and datetime/timestamp
- Do not force the use of prepared statements internally for simple queries without any parameters
- Optionally only use native prepared statement for SQL injection protection, but leverage the ability of some RDBMS to pass the [http://pooteeweet.org/blog/1233 statement and the values in a single call]
- Improve documentation
- Add support of multiple resultsets for mssql and odbc on all platforms.
- Add ability to retrieve the parameters set in the constructor (like DSN etc.)
- Add ability to determine the state of the connection/transactions (as well as the ability to reconnect)
- Make sure PDO classes implement interfaces so that frameworks can use it as a generic data access interface and implement native driver versions of it if needed (esp. PDOStatement).
- OCI8 has some persistent connection tuning parameters like timeout, max_connections, … Make that generic and consistent in PDO.
- Improved Quoting
- Consider having an attribute that sets quoting style + maybe even allow for a callback for quoting.
- Making quoting function aware of encoding in PDO (add quoting for identifier & value)
- Improved error handling and debugging
- Add some better debugging hooks (like a way to get the last submitted statement, this is important especially when PDO does some rewriting like with prepared statements)
- For consistency it would be good to clear errors on every call and provide facility to expose multiple notices/errors that have occurred within a transaction
- Throw an exception if a fetch method is call on a statement that has not been executed at least once
- Expand support for SQLSTATE error codes to ensure that all drivers return more or less compatible error codes
- Full blown Metadata APIs ala JDBC (important for higher-level DB layers). (possibly partially in userland)
- Test suite which DB driver authors can use for compliance testing.
- Add support for “IN (?)” type prepared placeholders. ⇐ native prepared statement mandate that all placeholders only handle a single scalar value