[development] PDO and database limitations

[Larry Garfield]

On Wed, 4 Apr 2007 21:33:49 +0200, Dries Buytaert <dries.buytaert at gmail.com> wrote:
> 
> On 04 Apr 2007, at 08:05, Larry Garfield wrote:
> 
>> 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.
> 
> I'd go for A.  :)
> 
> If we don't need the exact count, we might be able to replace
> db_num_rows() with something like db_table_is_empty().

Seems most people are OK with A, so A it is. :-)  I'll keep an eye on the queries as I'm fixing them to try and avoid double-queries when possible.  I don't know if db_result_set_is_empty() is a good solution or not.  I guess I'll find out.

> Let us know if you run into issues that need further attention/
> discussion.

One other FYI that is probably not going to break TOO much, I hope...  Since this affects db_query(), this patch will also involve moving db_query into each database.*.inc file rather than database.inc.  For the moment I'm just looking at copying and pasting them into the mysql and pgsql implementations, which so far has caused no issues.  We may, later, want to then refactor the relationship between db_query and _db_query(), but for the moment that is not something I'm worrying about.  (I suspect the pdo db_query() won't even have a _db_query(), as I'll just merge them.  TBD.)

--Larry Garfield