[development] PDO and database limitations

[Gerhard Killesreiter]

-----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-----