Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I have two databases in my config, so $db_url is something like this:
$db_url = array(
'default' => 'mysql://...',
'forum' => 'mysql://...'
);
Dut your module shows empty lists of tables on settings page. I have found that _db_maintenance_determine_software() function didn't respect that $db_url can be an array. It's assumed that this variable is string. You need some more testing before doing strpos().
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | db_maintenance-6.x-1.2.patch | 2.46 KB | vadym.kononenko |
Comments
Comment #1
szy commentedConfirmed. There are two databases (the second one is from vBulletin), so lists
for choosing tables in DB Maintenance options are empty (attachment).
Szy.
Comment #2
szy commentedComment #3
Charles Oertel commentedI am looking at this module on a site that uses two postgres databases and ran into the same problem. Attached is a patch of the code I used to fix it. This is my first ever contribution to a module, so forgive and give me feedback if there is a problem.
Comment #4
szy commented@Charles Oertel, works fine for me, thank you.
Szy.
Comment #5
deekayen commentedPlease run the code through coder.
I haven't tried the patch yet, but can you just type cast (array) or does this solution really require is_array()?
Comment #6
Charles Oertel commentedThanks for pointing me to coder - though it seems that my patch has little to do with the errors it generates. Perhaps you should log this as a separate issue.
I coded the patch to be easy to understand and maintain, and prefer to keep my variables as fixed types. If you prefer a different style or technique, please enlighten me. Is there a problem with using is_array?
Comment #7
Charles Oertel commentedFurther analysis reveals a number of places in the code where the assumption is made that there in only one database. I am working on fixing these, as well as allowing the multiple databases to be of any type (e.g. one mysql and one postgres say).
The settings also need to provide an option for the pg_dump path, which I will add.
Comment #8
Charles Oertel commentedAttached is my work to date - quite a lot of changes. I ended up using the backup_migrate module to do most of what I wanted, and it depends on some of the functions in this module to detect databases and parse dump parameters.
So, for a fuller solution, look at using the patched version of backup_migrate with the patched version of this module.
Comment #9
Charles Oertel commentedFixes to the patch to create a .pgpass file populated with the database logon credentials. This is needed because pg_dump does not allow passwords to be passed via the parameter line. The .pgpass file is created in the parent of the drupal instance. If this is not the home directory of the apache user, you need to tell pg_dump the path to this file as follows:
`PGPASSWORDFILE=../.pgpass; pgdump ...`
Comment #10
kakarot-1 commentedThat patch is for db_maintenance-6.x-2.0 which isn't available in the project download section... dou you have a db_maintenance-6.x-1.1 patch version?
I've tried to adapt the patch to 1.1 module version, but when i try to save database, the backup is empty :( obviously this shouldn't be so easy.
Any ideas?
Comment #11
jleinenbach commentedsubscribe
Comment #12
deekayen commentedComment #13
Alan.Guggenheim commentedSame problem here.
Comment #14
TallDavid commented2+ years. Any chance of a fix for Drupal 6 being released to production before Drupal 7 goes live?
Note to self: az.org
Comment #15
deekayen commentedThe problem is the patch is for the 6.x-2.x branch. The contributor that submitted all that backup and dump code is gone, so I unmaintained it back to the original featureset of OPTIMIZE and VACUUM. The patch doesn't apply.
Comment #16
vadym.kononenko commentedI've created patch to 6.x-1.2 that is very similary to #3. Works for me.
Comment #17
VicOnt commented