Drupal is moving towards supporting more database back-ends. Currently, each database back-end requires a dedicated file in the includes directory (database.*.inc). This approach makes it very difficult for new database back-ends to be developed by non-core developers.

Drupal's module system is excellent and provides many advantages. We should apply those advantages to database support. Therefore, I suggest that we re-organize the database support in database.*.inc so that there is one module per supported database back-end, in the "Database" package. So there would be a MySQL module and a PostgresSQL module in core for D6. One database module will be enabled during DRUPAL_BOOTSTRAP_DATABASE based on the database type specified in $db_url.

The big advantage for this change is that it makes is possible to have additional databases supported as contrib modules. A non-core developer could release (e.g.) an Oracle module in contrib. It could be used and mature outside the core release cycle, just like CCK has, and when it is ready the core maintainers can later decide whether to incorporate it into core or leave it in contrib.

This will require very little work. We basically just move each current database.*.inc file into a module. We then rename the functions so instead of every database.*.inc file defining (e.g.) db_query() the MySQL module defines (e.g.) db_mysql_query. The one db_query() function in database.inc would then just dispatch to the appropriate function defined by the currently-active database module. So we're doing nothing but renaming some functions and we get a large benefit of making it much easier to develop additional database back-ends.

Comments

moshe weitzman’s picture

moshe weitzman commented

This is an excellent proposal.

The db_query() as dispatcher has already been written once and can be lifted from http://drupal.org/node/19522 by whomever implements this. I think we should resubmit it in this issue. The benefits are more clearly articulated here.

sedave@groups.drupal.org’s picture

sedave@groups.drupal.org commented

This is a good idea. However the stated benefit: making it much easier to develop additional database back-ends is probably an exaggeration.

Dropping a database.*.inc file into the includes directory is not the problematic part of creating a database back end. Having to hack the DB API and fixing up the MySQL/Postgres specific db_query statements littered all over core is. And of course there's also those create table scripts...

It is still good idea, just might have to revise the benefit to be: making it a little easier to develop additional database back-ends.

Frando’s picture

Frando commented

Big +1 on the idea. http://drupal.org/node/19522 is the first step towards this.

moshe weitzman’s picture

moshe weitzman commented

Or better - a little easier to deploy contributed database backends

Each DB has a install..inc file as well, which is troublesome. So this feature request is quite worthy.

sedave@groups.drupal.org’s picture

sedave@groups.drupal.org commented

Yes I agree this feature request is quite worthy. I was simply contending the degree to which this allows core independence for the maintenance of database modules. I still think this is probably the smallest part of the core/db implementation overlap that needs to be addressed. The largest problem is being addressed by the awesome work with the schema stuff. The next largest thing I think would be figuring out what needs to be changed in the database API itself in order to support other databases while keeping support for the current ones.

bjaspan’s picture

bjaspan commented
Version: 6.x-dev » 7.x-dev
Crell’s picture

Crell commented
Status: Active » Closed (won't fix)

It's not modules, but the new DB API does support more "drop-in-able" drivers since nothing gets hard coded. Each driver lives in its own directory inside /includes/database and gets discovered by the installer when appropriate. I think that's good enough, and avoids having to deal with modules being in 5 different places. :-)

moshe weitzman’s picture

moshe weitzman commented
Status: Closed (won't fix) » Active

@Crell - It is great that you made the installer work with pluggable backends. But I still think it is a worthwhile feature request to have new Contrib backends live in sites/ instead of includes/. At one time we had a hush hush feature where you could override core include files with sites/all/includes or sites/]foo]/includes. But I don't think thats working anymore. If it did work, I'd say this is much less needed.

Crell’s picture

Crell commented
Status: Active » Closed (won't fix)

Never did materialize, I'm not convinced it's a good idea anyway.