I searched but found no relevant issue.

On some rare occasions, the update SQL is run twice on the same table.
In settings.php, we have for most web sites something like:

  $db_prefix = "drupal_";

But for some multisite setups, we sometimes have something like:

    $db_prefix = array(
      'default'   => 'subsite_',
      'users'     => 'main_',
      'sessions'  => 'main_',
      'sequences' => 'main_',
    );

i.e. tables like {users} is shared among several sites.
Now, if an update is ALTERing the TABLE {user}, the same SQL will be run several times on the same table, i.e. once per site being updated and sharing this same table.

When updating the main site, running update will be ok:
ALTER TABLE main_users ADD KEY created (created)
but when updating the subsite, the same query will throw an error.
ALTER TABLE subsite_users ADD KEY created (created)

Solution?

Maybe the update function should check that $db_prefix is an array or not. If it is, then run the query only for those tables where the prefix is NOT explicitly defined, i.e. where $db_prefix['default'] is used.
But that would be a problem with complex queries.

Or else, this scenario should be consciously considered when creating update_N() functions, and use a different API for some selected queries like the one above, i.e. instead of using update_query(), we'd use update_query_check_multisite_setup()...

This issue exists in D5, and I'm not aware that this has been fixed in D6. A fix would necessarily involve an API change, so I bump straight away to D7.

Comments

R.Muilwijk’s picture

When using Drupal the way you do it can't detect or the table is shared among other instances and so it's not possible to find out for sure or it should behave the way you suggest.

The best solution would be to check the database against the schema and only run updates on differences.