[development] PDO and database limitations
gerhard at killesreiter.de
Wed Apr 4 09:42:03 UTC 2007
-----BEGIN PGP SIGNED MESSAGE-----
Larry Garfield schrieb:
> This is an RFC of sorts. :-)
> At Drupalcon, I was shopping around the idea of a PDO backend for Drupal.
> For brevity, I'll just reference the blog entry I made on why I think PDO is
> a good idea. The goal is that PHP 5 users get a nice speed bump and we
> get a start on eventually shifting Drupal's database layer from the 1997 APIs
> to the more robust 21st century PHP standards. Most people I talked to liked
Andrew Kirkham has also been working on PDOs.
> the idea, so after getting a nod from Dries I've been working on it since the
> Hackfest and made decent progress. However, I've run into a few snags I want
> to get a 2nd opinion on (or 3rd, or 4th, or whatever).
> 1) It turns out that PDO from PECL running under PHP 5.1.6, at least, has
> issues. Specifically, segfault issues on otherwise perfectly sane queries.
> This is apparently a known issue with 5.1.6, and one of the reasons 5.2
> exists. :-) At present, I have no solution for it other than saying "well,
> the PDO support is only if you're running 5.2, otherwise use the existing
> MySQL/PostgreSQL drivers, deal". Does anyone have a problem with that, and
> if so, an alternate solution?
No problem with that. Fits in line with the idea to get people to use
higher versions of PHP.
> 2) Like any wrapper, PDO, while it offers some really nice features with a
> common API (like C-level prepared statements, which are what I'm mainly
> after), has some "lowest common denominator" issues. The main one I've run
> into so far is that there is no reliable equivalent of mysql_num_rows() for
> SELECT statements, only for data-changing statements. In testing it
> doesn't look like the MySQL PDO driver returns anything useful for rowCount()
> on SELECT. That gives us 3 options.
> A) Stop using db_num_rows() on result sets. (It's a database-specific feature
> in the first place.) In places where we use it, use a separate count(*)
> query instead. That's the more database-agnostic method, and is what the PHP
> manual recommends. If we go this route, it will involve removing the
> db_num_rows() function from the existing mysql and postgres drivers and
> refactoring core queries accordingly.
Sounds ok to me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the development