[development] PDO and database limitations

[Khalid Baheyeldin]

On 4/7/07, Gabriele Turchi <gabriele.turchi at l39a.com> wrote:
>
> Frankly, I don't think PDO could be a solution for a better database
> portability, at least in drupal.


Can you explain in some more detail why you think so?

My first feeling was to create a very light db persistence layer, based
> on php dynamic object creation (__get and __set): define a class with an
> array on info like: name, type (number, text, large text and blob), is
> (part of) primary key, is indexable. Do a mapping into a "create table"
> should be easy.


I have mixed feelings about abstraction layers. I am not opposed to
abstracting
DDL (table creations, alters, ...etc.), but have mixed feelings on full
abstraction
of DML (select, insert, ...etc.), on one hand it makes development easier,
but they
tend to be lowest common denominator and failing to optimize to the specific
engine
in use.

However, we already have an abstraction layer in Drupal that has worked
well.
The drawback is that it is not a standard though. If we are to write a new
layer, then it has to be something with wide support for various databases,
and PDO seems to be that layer.

About the db_num_rows question: there are more than a good reason to
> avoid it. As an example, the default behavior for the postgresql driver
> is to fetch in memory _all_ the results before returning the first one
> to the caller: with big tables this is simply devastating (and can be
> removed from future releases). And Oracle simply doesn't support it.


Many databases do not support, but for those that do, it avoids the
performance
penalty of two queries (one SELECT col1, col2 ...., and one SELECT
COUNT(*)).

In your other message, you mentioned that db_num_rows is bad for
performance.
How is that so? Is this true only for PostgreSQL?
-- 
2bits.com
http://2bits.com
Drupal development, customization and consulting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070407/f9aa4a24/attachment.htm