I installed this on a site which uses table prefixing and was surprised that the "Exclude the data from the following tables:" wasn't populated.

I tried to make it work but it didn't seem to. So, I provide this patch as a work in progress and in case someone else can provide ideas to make it better.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dgorton’s picture

Just so everyone tracks both threads - there's also a patch on this same issue at http://drupal.org/node/196936 for 5.x

ronan’s picture

This patch works for me so I commited it to the 5.x-1.x and 6.x-1.x branches, thanks greggles. If you have already submitted the form with the empty selections, that empty submission will be saved as default settings and you will have to clear the variables table for this to make any difference.

A note to prefix table users, this patch will not strip prefixes from your backup files, if you export a db with prefixes it will be imported with the same prefixes. A patch for removing prefixes is being worked on for version 2: #196936: Change database table prefix.

ronan’s picture

Status: Needs work » Fixed
Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

kriskd’s picture

I ran into this issue when transferring a db from a site without a prefix to a site with a prefix. I used the dev version of the mod and it didn't work. So, I just did some old fashioned text manipulation with Notepad++ and Excel to create the queries I need it and then ran it in PHPMyAdmin. Got my site up and running after that.

mrfelton’s picture

Status: Closed (fixed) » Active

I'm reopening this issue as it doesn't seem to be working in the latest -dev release... did the patch get applied to CVS? I have 2 sites in the same db, using database prefixes. The include/exclude fields were not prepopulated.

dman’s picture

I would really like to see this - I think tables from outside the current prefix set should not enter into the process at all. (over-ridable optionally if you feel the need to be running other data in a drupal site of course)
Is it worth me having a go at this? I'ts a bit of a killer for the multisite migration I was planning to use this on. Is there a patch to play with? Is dev stable?

ronan’s picture

The 1.x branch is stable, all new features are going into the 2.x branch which is a little more experimental. If you want to write a patch for this, be my guest, but if you want to do it on the 2.x branch let me know first and I'll get the code ready for it.

Thanks
Ronan

idflood’s picture

Status: Active » Needs work
FileSize
899 bytes

I made a little patch that only consider table with the correct prefix.
Do we really need to give the option to backup other tables?

idflood’s picture

Status: Needs work » Needs review
idflood’s picture

Version: 6.x-1.x-dev » 6.x-2.x-dev
idflood’s picture

Status: Needs review » Needs work
FileSize
1005 bytes

I fixed an issue that appeared with the latest patch if the current installation doesn't have table prefix. But this new patch make it clear that it won't work for unprefixed tables ( it will simply display all tables, with and without prefix ).

It's easy to check if a table name start with $db_prefix, but if $db_prefix is empty how to check that the table name doesn't have any prefix?

nickrice’s picture

#12 would suit my purposes where I only want to export for particular prefix. I also think that exporting everything where $db_prefix is empty is fair enough, as long as it's clear that's what will happen. As you say, @idflood, how can you check for a null prefix?

However, $db_prefix can also be an array - eg providing one prefix (a default one) for tables containing instance-specific data and another for shared tables.

The pre-dating issue (with patch) #728940: Support of db_prefix looks much more comprehensive though it appears to have atrophied since March - maybe due to lack of interest?

barobba’s picture

I didn't see a patch for entering the table prefix in the "Profile" form. I think the following solution would work well, though I haven't tested it thoroughly myself.

First, add the form element called "table_prefix" to the "backup_migrate/includes/destination.db.inc" file. No additional work is necessary for saving this data, since the crud.inc will handle the data storage.

...
  function backup_settings_form(&$form, $settings) {
    ...
    $form['database']['table_prefix'] = array(
      "#type" => "textfield",
      "#title" => t("Table prefix"),
      "#default_value" => ($settings['table_prefix'] ? $settings['table_prefix'] : ""),
      "#description" => t("Only tables with this prefix will be included in the backup."),
    );
    ...
  }
...

Next, when backing up the tables, filter out tables that are missing the table prefix. The function to modify is located in "backup_migrate/includes/destination.db.mysql.inc".

...
  function _backup_db_to_file($file, $settings) {
    ...
    $table_prefix = !empty($settings->filters['table_prefix']) ? trim($settings->filters['table_prefix']) : '';
    ...
    if ($file->open(TRUE)) {
      ...
      foreach ($alltables as $table) {
        ...
        $has_same_table_prefix = !empty($table_prefix) ? strpos($table['Name'], $table_prefix, 0) === 0 : true;
        $is_table_excluded = isset($exclude[$table['Name']]);
        if ($table['Name'] && $has_same_table_prefix && !$is_table_excluded) {
          ...
couturier’s picture

Issue summary: View changes
Status: Needs work » Closed (outdated)