Posted by beholder on September 11, 2008 at 9:17am
| Project: | DB Maintenance |
| Version: | 6.x-1.2 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | patch (to be ported) |
Issue Summary
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().
Comments
#1
Confirmed. There are two databases (the second one is from vBulletin), so lists
for choosing tables in DB Maintenance options are empty (attachment).
Szy.
#2
#3
I 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.
#4
@Charles Oertel, works fine for me, thank you.
Szy.
#5
Please 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()?
#6
Thanks 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?
#7
Further 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.
#8
Attached 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.
#9
Fixes 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 ...`
#10
That 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?
#11
subscribe
#12
#13
Same problem here.
#14
2+ years. Any chance of a fix for Drupal 6 being released to production before Drupal 7 goes live?
Note to self: az.org
#15
The 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.
#16
I've created patch to 6.x-1.2 that is very similary to #3. Works for me.