The migration process from mysql 5.1 to postgresql 8.4 aborts with the message:
# drush dbtng-replicate default postgres
WD php: PDOException: SQLSTATE[42P01]: Undefined table: 7 ERROR: relation "locales_source" does not exist [error]
LINE 1: SELECT s.lid, t.translation, s.version FROM locales_source s...
^: SELECT s.lid, t.translation, s.version FROM {locales_source} s LEFT JOIN
{locales_target} t ON s.lid = t.lid AND t.language = :language WHERE s.source = :source AND s.context = :context AND s.textgroup =
'default'; Array
(
[:language] => de
[:source] => @table was successfully created.
[:context] =>
)
in locale() (line 676 of /opt/cms/modules/locale/locale.module).
PDOException: SQLSTATE[42P01]: Undefined table: 7 ERROR: relation "locales_source" does not exist
LINE 1: SELECT s.lid, t.translation, s.version FROM locales_source s...
^: SELECT s.lid, t.translation, s.version FROM {locales_source} s LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = :language WHERE s.source = :source AND s.context = :context AND s.textgroup = 'default'; Array
(
[:language] => de
[:source] => @table was successfully created.
[:context] =>
)
in locale() (Zeile 676 von /opt/cms/modules/locale/locale.module).
PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0
after two tables (block and block_bid_seq) have been created. locales_source exists in the source db and contains data.
Comments
Comment #1
josh waihi commentedJust tried to replicate the issue but couldn't. Could you please list the steps you took? Sounds like DBTNG didn't create locales_source but am unsure how to replicate this.
Comment #2
manitoba22 commented1. create postgres db
2. add it to settings.php
(this is different from your blog post, where $databases['default']['default'] and $databases['default']['pgsql'] was used, which I tried first, but with this, the second database entry did not show up in the Migrator database list)
3. several attempts with the gui (resetting the postgres db with dropdb/createdb after each)
4. run the drush command as given above to get a better readable output
(Perhaps I should mention that some days ago I migrated the mysql database from a host with 5.0 to the current with 5.1. With this I had an issue (http://drupal.org/node/998474), which I solved by truncating search_index and search_total tables.)
Comment #3
manitoba22 commentedAdditional info: Drupal version is 7.4. Enabled modules are:
Comment #4
manitoba22 commentedComment #5
josh waihi commentedI noticed your encoding for PostgreSQL is unicode. It should be UTF-8 as Drupal only supports PostgreSQL in UTF-8. Something the Drupal installer picks up but DBTNG Migrator doesn't.
Does this error also occur when you use the GUI? I used the batch GUI to do the migration and it worked for me. This and the encoding are the only differences I have other than the different modules enabled. Not that that should really matter as DBTNG just iterates through enabled modules, installs the schema then copies the contents across.
Comment #6
manitoba22 commentedAfter recreating the database with "encoding=UTF-8", I executed Migrator in GUI and got the errors below.
Again, only block and block_bid_seq where created. Maybe there occurs a problem after adding the sequence?
The postgres version is postgresql-8.4.7-1.el6_0.1.x86_64 on centos 6.0
An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: /cms/?q=batch&id=31&op=do StatusText: Service unavailable (with message) ResponseText: PDOException: SQLSTATE[42P01]: Undefined table: 7 ERROR: relation "locales_source" does not exist LINE 1: SELECT s.lid, t.translation, s.version FROM locales_source s... ^: SELECT s.lid, t.translation, s.version FROM {locales_source} s LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = :language WHERE s.source = :source AND s.context = :context AND s.textgroup = 'default'; Array ( [:language] => de [:source] => @table was successfully created. [:context] => ) in locale() (Zeile 676 von /opt/cms/modules/locale/locale.module).Uncaught exception thrown in shutdown function.PDOException: SQLSTATE[42P01]: Undefined table: 7 ERROR: relation "semaphore" does not exist LINE 1: DELETE FROM semaphore ^: DELETE FROM {semaphore} WHERE (value = :db_condition_placeholder_0) ; Array ( [:db_condition_placeholder_0] => 2175106754e3078d0638e87.84210880 ) in lock_release_all() (line 266 of /opt/cms/includes/lock.inc).Uncaught exception thrown in session handler.PDOException: SQLSTATE[42P01]: Undefined table: 7 ERROR: relation "sessions" does not exist LINE 3: sessions sessions ^: SELECT 1 AS expression FROM {sessions} sessions WHERE ( (sid = :db_condition_placeholder_0) AND (ssid = :db_condition_placeholder_1) ) FOR UPDATE; Array ( [:db_condition_placeholder_0] => ghssICYUU_FdNR8sc5NKJWsID9NGuIRQIV8DkNdzpGw [:db_condition_placeholder_1] => ) in _drupal_session_write() (line 203 of /opt/cms/includes/session.inc).
Comment #7
josh waihi commentedAh, ok. You have the locale module enabled which, when t() is called, calls locale() while connected to the PostgreSQL database.
I've pushed a commit to the 7.x-1.x branch of the git repository, if you can test it for me, I'll make a new release if it works.
Comment #8
manitoba22 commentedsorry for the stupid question - I don't know where to find git repository and the updated file (quit new to drupal, and to git, too).
Comment #9
rfay@manitoba22, you can actually grab the latest at http://drupalcode.org/project/dbtng_migrator.git/snapshot/refs/heads/7.x..., or you can wait for the next dev release which gets rolled every 12 hours.
Or spend some time with git - it's great. http://drupal.org/documentation/git
Comment #10
manitoba22 commentedok - figured it out (I really had to learn it).
The GUI migration went to 100%, and a lists of successfully updated modules was displayed, but at the end an error message occurs:
SQLSTATE[42703]: Undefined column: 7 ERROR: column "l10n_status" of relation "locales_target" does not exist LINE 1: ...target (lid, translation, language, plid, plural, l10n_statu... ^
Comment #11
manitoba22 commentedWith drush dbtng-replicate default postgres, the error message cited above comes first, and then the list of successfully created tables/modules.
Comment #12
josh waihi commentedl10n_status isn't a column in locales_target. Try clearing your cache before running the command again. Or maybe one of your modules is referencing a column that doesn't exists, in other words, it needs updating.
Comment #13
manitoba22 commentedlocales_target.l10n_status is indeed missing in the newly created postgres database. However, Drupal seems to work already fine with it - I can navigate, add new content, etc.!
I have gone through some database migrations, and it's unbelievable, that this one worked just on a mouse click!!
Comment #14
josh waihi commentedlocales_target.l10n_status is missing by design.
So assuming all is working fine. I'll make a 1.0 release. Thanks for reporting the bug.
Comment #15
manitoba22 commentedIt is in the mysql database:
Perhaps it was added by the l10n_update module.
Comment #16
josh waihi commentedIf it was added in an update hook or install hook, then dbtng wouldn't know how to migrate it. Schema changes need to be provided via hook_schema_alter.
Comment #17
manitoba22 commentedOk, I see. Uninstalling and reinstalling l10n_update fixed the missing column.
Thank you so much for your kind and immediate help. It's really amazing to work togesther across so many time zones.
And thanks again you for this uncredible module!
Comment #18
josh waihi commentedAwesome. And your welcome :)
Comment #20
manitoba22 commentedUnfortunately, the error described above shows up again.
As I could verify, the field locales_target.l10n_status is added by the current 7.x-1.0-beta2 version of Localization update module during l10n_update.install.
As a result of the error, the column is not copied.
Comment #21
josh waihi commentedDBTNG Migrator migrates a table in two phases. First it migrates the schema, then the data. This is the function for migrating the schema. As you can see it obtains the schema the same way drupal_get_schema does. So if DBTNG Migrator failed to get the full schema, then Drupal core must also be failing, in which case, this can't be a DBTNG Migrator bug.
Try flushing your schema cache as it may contain old cache that doesn't have the altered schema of locales_target.
Potentially, l10n_update_install should be clearing the schema cache so l10n_update_schema_alter gets called.
Comment #22
manitoba22 commentedHi Josh,
Thank you for looking into this once again!
I tried it today on a completely different Drupal installation (different purpose, different machines, different modules installed, different database server - so also postgresql, German as second language and l10n_update installed). To clear the schema cache, before "drush dbtng-replicate" I executed
drush php-eval "cache_clear_all('schema', 'cache');"
on the source (and also on the target) machine, but again got
SQLSTATE[42703]: Undefined column: 7 ERROR: column "l10n_status" of relation "locales_target" does not exist at character 71
I have no idea if this was caused by a flaw in l10n_upate (7.x-1.0-beta2), in dbtng_migrator (7.x-1.0) or drupal core (7.10) itself, or most likely by some mistake on my side (given my weak experience with drupal and php). Is there something I could do to make the problem reproduceable?
Comment #23
josh waihi commentedBefore you run dbtng's replicate command, what does this give you:
It should return an array describing the tables for that module and the locales_target table should then have a l10n_status column in it. If it doesn't, try this:
If it show up then, you should be able to migrate with dbtng no problems.
Also, the cache_clear call is:
I do notice the schema build seems to have changed in core from when I first wrote this module, so if this doesn't work, I'll relook at how the schema is built in DBTNG Migrator
Comment #24
manitoba22 commentedNeither
drush php-eval "print_r(drupal_get_schema('l10n_update'));"
nor
drush php-eval "print_r(drupal_get_schema('l10n_update', TRUE));"
give any results (drush php-eval "print_r(drupal_get_schema('node', TRUE));" does).
The database definitions in the source database are:
Comment #25
manitoba22 commentedcomment deleted (subject was i18n_status)
Comment #26
manitoba22 commentedWorkarround:
(recreates the required field)
Comment #27
chi commentedCan we invoke hook_schema_alter() from DBTNG Migrator module?
Comment #28
josh waihi commentedFixed in 7.x-1.4
Comment #30
rudam commentedHello, I tried everything you guys mentioned above and I still get using migrator database check gui:
SQLSTATE[42P01]: Undefined table: 7 ERROR: relation "locales_source" does not exist LINE 1: SELECT s.lid, t.translation, s.version FROM locales_source s... ^The database was created UTF8:
createdb --encoding=UTF8 -O drupal drupalTried drush -y pm-disable l10n_update, drush -y pm-uninstall l10n_update, drush -y en l10n_update and no game.
version 7.x-1.4
Comment #31
rudam commentedUpdate:
I went directly to the migration ignoring the check error and everything went smoothly. Thank you for this wonderful module!