Last week i checked admin/build/schema/report on some of our domains and found mismatches on those domains not apparent on our default domain:
*
locales_source
o indexes textgroup_location: missing in database
*
locales_target
o status: not in database
We are prefixing the i18n_strings schema (tables locales_source and locales_target) for all domains. The last two updates of i18n_strings schema look as follows:
function i18nstrings_update_6002() {
$ret = array();
db_add_index($ret, 'locales_source', 'textgroup_location', array(array('textgroup', 30), 'location'));
return $ret;
}
function i18nstrings_update_6003() {
$ret = array();
db_add_field($ret, 'locales_target', 'status', array('type' => 'int', 'not null' => TRUE, 'default' => 0));
return $ret;
}
Both updates are only executed on the default-domain's tables, but not any other domain's. db_change_field or variable settings propagate without flaws. I can do update.php on every domain, which solves the problem, but is an administration nightmare.
Now first of course i'm wondering if this is expected behavior. The generated SQL uses the {} syntax to enable the prefixing. I can't see any technical reason why adding a field or adding an index would be less robust/secure/viable/whatever than changing field settings.
I'm also aware that this is not particularly an issue with domain access but any multisite solution for drupal, but this probably is a good place to discuss it. Especially i would be interested (in case it is expected behavior) if anybody knows if there are any efforts made to:
a) make the propagation (and it's success) to other sites visible in update.php. i'm getting an "ok, everything went fine"-feedback now but this is true for the default domain only (we are hosting 20+ domains currently). if i do the update from the default domain again i get an error of course, which is also true for the default domain only.
b) how to handle multisite setups with very different prefix-settings for some of the domains.
Also i wanted to ask if it is normal that all of our prefix-tables are shown in the "Extra"-section of admin/build/schema/report and if not, if that could be the reason for the failing propagation?
Comments
Comment #1
agentrickardSee the documentation of Domain Prefix. THis is the expected behavior, for the reasons you describe, and so not a bug.
Patches welcome, but there is no easy fix for this. You probably need an external script.
The schema report, probably, since domain-2-tablename is not registered wth the Schema API.
Comment #2
agentrickard