[development] External database handling

Chris Johnson cxjohnson at gmail.com
Fri Aug 22 03:21:37 UTC 2008

Is it generally desirable that contributed modules use the Drupal
database abstraction whenever possible when accessing external
databases?  That is, is it generally preferable to use db_query() and
friends, instead of mysql_connect(), mysql_query(), etc. whenever

I personally think so at the moment, but would certainly like to hear
any arguments to the contrary.  An argument that it doesn't really
matter is an argument against generally using Drupal's DB layer.

If one agrees it is generally better to use the Drupal DB layer, there
is a significant problem to doing so.  The code which supports
multiple databases (of which I admit to being partially the author),
such as db_set_active(), requires the additional databases to be
listed in an array version of the global $db_url variable (up to and
including Drupal 6) and $databases (Drupal 7).  This array is set in
the settings.php file.

When using the Drupal 6 installer, this file can be written for the
user doing the install.  One can assume that most installations will
thus likely not involve someone hand editing that file.  Yet, except
for some ugly kludges involving overwriting the $db_url or $databases
variable (a scalar by default) with an array form including the extra
external database(s), the only way to add an external database is to
hand edit that file.

If one wants to write a contrib module which has all the ease of
installation which D6 and D7 core have, and which uses an external
database, one is rather stuck.  One can either (1) kludge up the
$db_url or $databases variable by overwriting it, (2) require the user
to expertly hand-edit the settings.php file or (3) not use the Drupal
DB abstraction layer.

Or so it seems.  The contrib modules I've looked at so far mostly
resort to #3, not using the DB abstraction.

I'd especially like to chat with the folks working on the DB layer for
D7.  It would be nice to provide an interface to allow adding an
additional DB programmatically from the contrib module.


More information about the development mailing list