FAQ
Currently I'm doing an experimental Oracle port, and for that need I've
done a quick travel in the drupal code...

Frankly, I don't think PDO could be a solution for a better database
portability, at least in drupal.

From what I've seen, the database usage is pretty plain (some "create"
in ".install" and mostly simple (only some table involved) "select",
"insert" and "update" - or, better, "upsert" in the code).

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.

The actual common usage of "db_fetch_object" may be left more or less
unchanged, simply creating queries asking what fields from what table
with what filters. The "join" case can be simplifyed using views.

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.

My 2cents...

Best Regards,
Gabriele Turchi

P.S.: I'm sorry, my english il alpha version...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6054 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20070407/701cb7c6/attachment.bin

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 15 of 18 | next ›
Discussion Overview
groupdevelopment @
categoriesdrupal
postedApr 4, '07 at 6:05a
activeApr 10, '07 at 7:20a
posts18
users10
websitedrupal.org
irc#drupal

People

Translate

site design / logo © 2022 Grokbase