Column locales_target.i18n_status is present in the source db, but after migration missing in the target db (verified on the database level).
The column was created in sites/all/modules/i18n/i18n_string/i18n_string.install.
An attempt to switch to the secondary language in the target-db-based Drupal installation results in:
PDOException: SQLSTATE[42703]: Undefined column: 7 ERROR: column t.i18n_status does not exist at character 43: SELECT s.*, t.translation AS translation, t.i18n_status AS i18n_status FROM {i18n_string} s LEFT OUTER JOIN {locales_target} t ON s.lid = t.lid WHERE (s.textgroup = :db_condition_placeholder_0) AND (s.context = :db_condition_placeholder_1) AND (t.language = :db_condition_placeholder_2) LIMIT 1 OFFSET 0; Array ( [:db_condition_placeholder_0] => views [:db_condition_placeholder_1] => project_list_simple_:default:title [:db_condition_placeholder_2] => de ) in i18n_string_textgroup_default::load_translation() (line 600 of /opt/drupal/sites/all/modules/i18n/i18n_string/i18n_string.
Comments
Comment #1
manitoba22 commentedWorkarround: Insert the missing field (does not migrate any data!) to eliminate the sql error
drush php-eval "$schema = drupal_get_schema('locales_target', TRUE); db_add_field('locales_target', 'i18n_status', $schema['fields']['i18n_status']);"
Comment #2
unkn0wn commentedAsi i understand, migration process had a problems. Today i try to migrate to postgresql, but i have an error:
PDOException: SQLSTATE[42703]: Undefined column: 7 ERROR: column "i18n_status" of relation "locales_target" does not exist LINE 1: ...target (lid, translation, language, plid, plural, i18n_statu... ^: INSERT INTO locales_target (lid, translation, language, plid, plural, i18n_status) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_ ....I check schema, but it's ok:
Also, target table locales_target is empty, and there is no column 'i18n_status', althought original DB has this column.
I try to disable/uninstall/enable modules - no success.
Enabled modules: Internationalization, Field Translation, String Translation.
Comment #3
josh waihi commentedPlease try the new 7.x-1.1 release (currently building as I write this!) or the HEAD from git. There is an alter schema fix that may also fix this issue. Please re open if new release doesn't fix the issue. Cheers.
Comment #4
unkn0wn commentedv.1.1 fix problem via drush, but when i try to migrate via web interface, error "column "i18n_status" of relation "locales_target" does not exist" is here.
Problem is in dbtng_migrator_batch_install_schema function, and it's very strange for me: function made call for rupal_alter('schema', $schema); , and module i18n_string must modify schema, but it's not true: when i patch dbtng_migrator_batch_install_schema like
i see:
Array ( [description] => Stores translated versions of strings. [fields] => Array ( [lid] => Array ( [type] => int [not null] => 1 [default] => 0 [description] => Source string ID. References {locales_source}.lid. ) [translation] => Array ( [type] => text [mysql_type] => blob [not null] => 1 [description] => Translation string value in this language. ) [language] => Array ( [type] => varchar [length] => 12 [not null] => 1 [default] => [description] => Language code. References {languages}.language. ) [plid] => Array ( [type] => int [not null] => 1 [default] => 0 [description] => Parent lid (lid of the previous string in the plural chain) in case of plural strings. References {locales_source}.lid. ) [plural] => Array ( [type] => int [not null] => 1 [default] => 0 [description] => Plural index number in case of plural strings. ) ) [primary key] => Array ( [0] => language [1] => lid [2] => plural ) [foreign keys] => Array ( [locales_source] => Array ( [table] => locales_source [columns] => Array ( [lid] => lid ) ) ) [indexes] => Array ( [lid] => Array ( [0] => lid ) [plid] => Array ( [0] => plid ) [plural] => Array ( [0] => plural ) ) [module] => locale [name] => locales_target )There is no i18n_status field. It twise strange for me, because migration via drush works ok.
Comment #5
josh waihi commentedDrush and the web interface use the same method for migration. I wonder if the issue was due to cache?
Comment #6
unkn0wn commentedBefore migration i clear cache twise. Also i disable eaccelerator, run update.php, run apache with mod_php instead of php_fpm - no success. If it's a cache problem - looks like it's a very sly cache.
May be something wrong with my configuration? FreeBSD 9.0, Apache 2.2.22, PHP 5.3.11, migration MySQL 5.5.23 -> PostgreSQL 9.1.2, Drupal 7.14, enabled modules:
# ./drush pml | grep Enabled
I admit the thought that my webserver may have a problems (because migration via drush is ok), so i'll change status to fixed. Please reopen issue if someone else have a problem with migration via web interface.