drupal allows the option of configuring $db_url as an array of database connections, which allows access to multiple databases within the same drupal installation. i'm using this with great success to integrate an outside CRM into drupal.

however, setting $db_url as an array breaks this module, as it's expecting it to be a string -- so the mysql test fails every time... :)

i spent some time working up a patch that not only supports the situation where $db_url is an array, but also allows you to selectively optimize any of the tables in any of the databases in the array. The approach of course still supports the common install where $db_url is just a connection string to the main Drupal database.

i spent a fair amount of time testing/debugging this model, and as far as i can tell, it works flawlessly.

this patch would also open the door to using this module to handle cron-based database optimizations for any and all databases you might manage, all from within one drupal installation. simply add any you want optimized to the $db_url array, and set the tables on the settings page. i'll grant you that we're not currently looking at the greatest UI to implement that (you have to edit settings.php to add databases), but at least it would be possible now -- which seems like a good positive step... :)

.install file to follow, which i'll explain there...

CommentFileSizeAuthor
#1 db_maintenance.install.txt267 byteshunmonk
multiple_db.patch4.97 KBhunmonk

Comments

hunmonk’s picture

hunmonk commented
StatusFileSize
new db_maintenance.install.txt267 bytes

the cleanest way to implement the patch was to always treat $db_url as an array in the code. in cases, where $db_url is a string, it becomes $databases['default'], as 'default' is the implied key in this case for the database connection. appending the database key to the variable for the tables listing was the easiest way to distinguish table listings from different databases, so it became necessary to switch the variable name for the main drupal table listing to match this approach. attached .install file handles the update for existing installations.

deekayen’s picture

deekayen commented

Just noting I did a preliminary review of the patch and it looks like it has merit.

deekayen’s picture

deekayen commented
Status: Needs review » Postponed

Went ahead and committed it to CVS DRUPAL-5 untested, so it's just going to be in the dev snapshots until I get some additional verification it works for someone else, too (I don't really have a setup for properly testing the new functionality). If I can get another reputable +1, I'll tag as version 1.1.

deekayen’s picture

deekayen commented
Version: » 5.x-1.x-dev
Status: Postponed » Fixed

Went ahead and tagged as 5.x-1.1. The original functionality worked fine on my production site. If this has to re-open for some reason, I assume I can tag an update as 5.x-1.1.1.

hunmonk’s picture

hunmonk commented

i think that would be 5.x-1.2

deekayen’s picture

deekayen commented

http://drupal.org/handbook/cvs/branches-and-tags/contributions led me to believe I could abuse the <-Extra> part to make a 5.x-1.1.1 if this new feature just needed a tiny bugfix before a new feature came along.

hunmonk’s picture

hunmonk commented

hm. my understanding was major new features would be a new branch, a la 5.x-1.0 then 5.x-2.0, and then bugfix releases would be 5.x-1.0 and 5.x-1.1

of course if you don't want a whole new branch, then the numbering scheme you laid out would make more sense. :)

deekayen’s picture

deekayen commented

If branching is the standard, I really screwed up then cause I only tagged 1.0 and 1.1 within the DRUPAL-5 branch. Either way, I'm happy with the way it is - not like this is a super complex module.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)