This patch lets Drupal handle multiple database layers. I think this closes the "TODO: Allow more than one database API to be present", so I've deleted that line.

CommentFileSizeAuthor
#8 database.inc_1.patch672 byteschx
database.inc_0.patch647 byteschx
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

moshe weitzman’s picture

nice simple patch... i suggest explaining to the user what to do to fix his problem. For example, change your $dbtype URL in your includes/conf.php file

chx’s picture

Thanks. But I do not really understand -- what shall I explain to who and where? I found the two examples (for mysql and pgsql) in conf.php pretty self-explaining, and if things go well, there will be a third soon: sqlite://database/sqlite/drupal.db -- as I have written, I already have an alpha-quality sqlite database layer.

tostinni’s picture

Well, regarding these patches, I have to mention a few point I faced when I try to add my Oracle database...
First of all, I don't think it's possible to include this patch without changing th structure of the files database.*.inc. The big problem is that the functions have the same name, so if you include more than one DB handler, you will got this error
Fatal error: Cannot redeclare db_connect() (previously declared in c:\archivos de programa\easyphp1-7\www\drupal2\includes\database.mysql.inc:23) in c:\archivos de programa\easyphp1-7\www\drupal2\includes\database.pgsql.inc on line 23
when you will activate second DB because all functions are already declared in previous database.inc.

Then you don't mention pear connector. And for those who use oracle, you use a connector DB (pear librairy) like "oci8://" or "oracle://"...

chx’s picture

It's not about including several include files at once. It's about introducing new database.*.inc files. So, you have oci8:// in $db_url? My code will try to include database.oci8.inc and nothing else. The original version would try to include database.pgsql.inc in this case -- actually in any case, when it's not mysql://

tostinni’s picture

It's not about including several include files at once. It's about introducing new database.*.inc files.

Hum, but your first post mention the TODO :

"TODO: Allow more than one database API to be present"

So I think this TODO is exactly what this deals about : "more than one".

Regarding of my problem for oracle, normally you have to deal with the database.pear.inc, so I suggest this code :

    if ($db_type == 'mysql') {
      include_once 'includes/database.mysql.inc';
    }
    elseif ($db_type == 'pgsql') {
      include_once 'includes/database.pgsql.inc';
    }
    else {
      include_once 'includes/database.pear.inc';
    }

But it won't solve the problem with multiple declarations and it doesn't activate database too...

chx’s picture

Maybe I misunderstood that TODO then. But still, this patch is needed to use pear:// or sqlite:// or whatever anyone will write a database.whatever.inc .

adrian’s picture

I have a more complete patch (for CVS) that I am working on, which allows you to use a postgresql and mysql (and oracle and sqllite) connection in the same site.

The problem is currently that the database.*.inc files specify db_* functions. Which conflict with each other when more than one is loaded.

I added the db_* functions to database.inc , and use a new function db_invoke($function, $args, ...) which calls the functions in the format of db_$dbtype_$function.

I still need to clean the patch up some more, but the previous item was also assigned to me.

chx’s picture

Title: Handle multiple database layers » Handle any type of database
FileSize
672 bytes

I resubmit, I changed the title, and kept that TODO in database.inc 'cos there was a misunderstaning what it "multiple". I thought "multiple" was "mysq, pgsql, sqlite and whatever" while others thought "multiple at the same time". I am not that ambitous to face the second challenge, all I need is this patch to get into core to be able to move forward with sqlite.

nmarci’s picture

Title: Handle any type of database » Re: #7, Why don't we use classes?

We could use classes for each database driver, so there would be no namespace problem.

e.g.: the file includes/database.mysql.inc would contain

class database_mysql {
function db_connect($url) {
...
}

...
}

and the database.inc could be a wrapper:

function db_connect($url) {
$db_conns['name']['conn']->db_connect($url);
}

This would result the same as comment #7 would, but using the php's class feature.

Gábor Hojtsy’s picture

Title: Re: #7, Why don't we use classes? » Handle any type of database

Please do not hijack the issue title... Drupal tries to stay away from using classes, to look simple, and to be generally faster.

Dries’s picture

Committed to HEAD.

Anonymous’s picture