-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Larry Garfield schrieb:
This is an RFC of sorts. :-)
At Drupalcon, I was shopping around the idea of a PDO[1] backend for Drupal. For brevity, I'll just reference the blog entry I made on why I think PDO is a good idea[2]. 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[3]. 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[3]. 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. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGE3Lqfg6TFvELooQRAmCJAJ9+7D5+7JpAUcUw45MP6wc9xXZYugCfTEeW 21xgTFKTIt1d5W9GbqNIcSQ= =9BZ1 -----END PGP SIGNATURE-----