WD php: PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'l10n_status' in 'field list': SELECT lid, l10n_status FROM {locales_target} WHERE lid = :lid AND language = :language; Array ( [:lid] => 657 [:language] => fr ) in _l10n_update_locale_import_one_string_db() (line 394 of /srv/www/aegir/platforms/cforge-7.20/sites/all/modules/l10n_update/l10n_update.locale.inc).

Comments

sutharsan’s picture

sutharsan commented
Status: Active » Postponed (maintainer needs more info)

This has been reported before, but we have not been able to reproduce it. Can you describe all steps that lead to this error?

Anders Kallin’s picture

Anders Kallin commented
Status: Postponed (maintainer needs more info) » Needs work

I'm not sure what triggered the problem in matslats case, but I got into a lot of problems with l10n_update yesterday whilst trying to migrate from MySQL to sqlite.

I finally figured out why 'l10n_status' wasn't found, and it's because the hook_schema_alter is in l10n_update.install instead of l10n_update.module.

I was using project dbtng which does the following:
1. Extracts the schema of all active modules from the source database
2. Calls hook_schema_alter to get all the changes
3. Switches to the destination database and creates the tables according to schema.

The second phase failed for l10n_update since hook_schema_alter was in l10n_update.install instead of l10n_update.module.

I think that moving the function will solve most problems with "unknown column 'l10n_status'", but I don't know enough about the intrinsics to spot any drawbacks.

Regards
/Anders

sutharsan’s picture

sutharsan commented

@Anders Kallin, What were you exact problems? Have you tried to move the code to .module? and did it solve the problems? If I provide you with code, could you test it? If I can't reproduce it, I can't fix it.

I find that hook_schema_alter() is used in both .install and .module files in different modules. Perhaps that the order in which module updates are run may or may not cause the problem. I found an issue about improving the documentation hook_schema_alter(): #1309302: Improve hook_schema_alter() documentation. And even they don't seem to agree.

Anders Kallin’s picture

Anders Kallin commented

Hi,

Yes I fixed the issue moving the function to .module. I've been busy a couple of days but I could probably write you a test case. Or you could try installing the dbtng module (use the development version) and try to copy a database.

cconrad’s picture

cconrad commented

I got the same error as matslats, but Anders' solution (moving the hook_schema_alter from .install to .module) didn't fix it for me. Not sure if this is relevant, I am using PHP 5.5 and Drush to run l10n-update. I assume something went wrong during the module's initial installation, leaving the schema in an inconsistent state? Anyway, I had to do the following steps to get it resolved:

  • drush pm-disable -y l10n_update (OK)
  • drush pm-uninstall -y l10n_update (failed with "module not installed")
  • delete from system where name = 'l10n_update';
  • drop table l10n_update_project;
  • drop table l10n_update_file;
  • drop table cache_l10n_update;
  • drush pm-enable -y l10n_update

// Claus

sutharsan’s picture

sutharsan commented
Issue summary: View changes
Status: Needs work » Closed (won't fix)

I'm not convinced that this should be fixed in l10n_update module. Many other modules implement hook_schema_alter in their .install file.

milos.kroulik’s picture

milos.kroulik commented
Component: Code » Documentation
Priority: Major » Normal

I also have the same problem as #5 in almost same circumstances (PHP 5.6, drush). I've got the problems after disabling the module and enabling it again. Maybe this module doesn't support this workflow? Then this should be mentioned on the module page. I will try to duplicate this issue, so it could be reopened.