On 4/7/07, <b class="gmail_sendername">Gabriele Turchi</b> <<a href="mailto:gabriele.turchi@l39a.com">gabriele.turchi@l39a.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Frankly, I don't think PDO could be a solution for a better database<br>portability, at least in drupal.</blockquote><div><br>Can you explain in some more detail why you think so? </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
My first feeling was to create a very light db persistence layer, based<br>on php dynamic object creation (__get and __set): define a class with an<br>array on info like: name, type (number, text, large text and blob), is
<br>(part of) primary key, is indexable. Do a mapping into a "create table"<br>should be easy.</blockquote><div><br>I have mixed feelings about abstraction layers. I am not opposed to abstracting<br>DDL (table creations, alters, ...etc.), but have mixed feelings on full abstraction
<br>of DML (select, insert, ...etc.), on one hand it makes development easier, but they<br>tend to be lowest common denominator and failing to optimize to the specific engine <br>in use.<br></div><br>However, we already have an abstraction layer in Drupal that has worked well.
<br>The drawback is that it is not a standard though. If we are to write a new <br>layer, then it has to be something with wide support for various databases,<br>and PDO seems to be that layer. <br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
About the db_num_rows question: there are more than a good reason to<br>avoid it. As an example, the default behavior for the postgresql driver<br>is to fetch in memory _all_ the results before returning the first one<br>
to the caller: with big tables this is simply devastating (and can be<br>removed from future releases). And Oracle simply doesn't support it.</blockquote><div><br>Many databases do not support, but for those that do, it avoids the performance
<br>penalty of two queries (one SELECT col1, col2 ...., and one SELECT COUNT(*)).<br><br>In your other message, you mentioned that db_num_rows is bad for performance.<br>How is that so? Is this true only for PostgreSQL?<br>
</div></div>-- <br><a href="http://2bits.com">2bits.com</a><br><a href="http://2bits.com">http://2bits.com</a><br>Drupal development, customization and consulting.