Right now, if you import a site that has a table prefix set in its configuration, it will be dropped when the settings.php file is regenerated and that will break the site.

Not sure what the proper solution is: Aegir doesn't need table prefixes, which are just a crude hack. Maybe we should just rename the tables on migrate...?

At least we should respect the variable in settings.php...

CommentFileSizeAuthor
#13 fix_prefix.txt1.09 KBcashwilliams

Comments

anarcat’s picture

We think this doesn't desserve our attention until the next release.

anarcat’s picture

Version: 6.x-0.2-rc1 »
Issue tags: +aegir-0.4

changing target release

anarcat’s picture

We should also make sure this works in migrations... #556598: $db_prefix not handled in migration

tiato’s picture

I wonder if this is related somehow http://drupal.org/node/195416

If so, seems to be more of a Drupal issue in the way it handles prefixes (sp?)

anarcat’s picture

@tiato - no, I don't think this is the problem here.

adrian’s picture

i think we should provide a script that renames tables, but not support this in aegir proper.

omega8cc’s picture

In any case, before going with renaming tables (which should be always recommended) you can import (and run) a site using prefixes by adding site specific code to global.inc - example:

<?php # global settings.php

if(!preg_match("/(standard)|(minimal)/", $conf['install_profile'])) { # avoid d7 warnings

  $thishost = $_SERVER[HTTP_HOST];
  if(preg_match("/(site-with-prefix)/", $thishost)) {
    $db_prefix = 'prefix_';
  }

}
adrian’s picture

Priority: Normal » Minor

what would a script to rename the tables look like?

omega8cc’s picture

Quick example of script for adding or removing a prefix on existing tables in mysql: http://drupal.org/node/403742

omega8cc’s picture

To keep it short:

  $old = "anyprefix_";
  $result = db_query("SHOW TABLES");
  while ($r = db_fetch_array($result)) {
    $table_old = current($r);
    $table_new = str_replace('^'.$old, '', $table_old);
    db_query("RENAME TABLE {$table_old} TO {$table_new}");
  }
adrian’s picture

the reason i distrust the prefix tables, is that the prefixing is often used to do many many kludgy things, such as sharing tables between sites (which we will never support) and having multiple sites in a single database (which we will never support).

So we can provide a mechanism to do this functionality manually, but we must document the hell of out of the fact that if you've done the above you need to do more than just unprefix your tables.

cashwilliams’s picture

Just an FYI, a site using table prefixes will also break every time a backup is run (as of beta2 which I tested). I've got nightly backups running via a drush script and every morning the site is down.

This is an old site imported from a shared host, so now I can rename the tables, but I think this issue is a little more serious then just breaking an import.

cashwilliams’s picture

StatusFileSize
new1.09 KB

Attached is a more elaborate version of #10 which doesn't delete existing tables without the prefix, but also drops the table if it exists before trying to rename it. My database was pretty dirty and had a fresh install amongst the prefixed tables.

Two variables should be configured at the top, one for the prefix of the current tables and one to just simulate the changes.

I've tested it and ran it against my site using:

drush php-script fix_prefix.php

Remove the $db_prefix from settings.php, then clear caches with

drush cc all
anarcat’s picture

Status: Active » Needs work

That script looks like a good start!

Could you make that into a complete drush command? I am sure others would find it useful, and then it could be included in drush or aegir...

steven jones’s picture

Version: » 6.x-1.x-dev
Status: Needs work » Closed (won't fix)

I feel like this could be it's own standalone Drush command and not really Aegir specific, and in the interests of making Aegir maintainable, I'm going to mark this as won't fix, but if someone wants to write the drush command we'd happily link to it from our migrating sites into Aegir documentation.