Ticket #267 (closed task: fixed)
Change Propel to use PDO for runtime db abstraction
| Reported by: | hans | Owned by: | hans |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.3 |
| Component: | Generator | Version: | devel |
| Severity: | normal | Keywords: | pdo |
| Cc: |
Description
When the Propel project started, there were several PHP DBAL (DB abstraction layer) options, but none of them fit our needs. In particular we needed:
- A PHP5-native layer that would throw db errors as exceptions
- A layer that would do a better jobs than the alternatives at providing metadata
- A completely OO layer that wouldn't rely on associative arrays or other idiosyncratic conventions in the API
- ... and just in general, it needed to be good, readable, documented, clean code.
Creole was thus born a sub-project of Propel, and indeed, Creole has become quite popular in its own right.
In the time since the project's inception, however, PDO has become stable and a part of the PHP distribution. Other than the metadata requirement, PDO fits Propel's needs very nicely, and the fact that this is compiled code should result in a big speed improvement. Hence, it makes sense to switch to using PDO for Propel's runtime DBAL.
PDO's API is very similar to Creole's and in general has support for the features we need. There are, however, a few challenges that we need to address in porting Propel to use PDO.
- PDO doesn't support nested transactions (or, more precisely, it doesn't support the API the way Creole does, although none of the Creole drivers actually implement the nested transactions at this time). PDO will throw an exception if you attempt to begin a transaction when another one is already in-progress. This doesn't work well with Propel's model of nested units of work. (I also opened a PHP feature request for this: http://pecl.php.net/bugs/bug.php?id=7718)
- PDO doesn't support LIMIT. This makes sense, it was never really the job of a DBAL to support LIMIT/OFFSET stuff, but alas convenience won out with Creole :)
- PDO doesn't handle temporal type conversion timestamps. This also makes sense, but adds some more responsibility to the Propel DBAdapter classes.
