Duplicate column name 'status' when both I18n Strings and L10n Update are installed

Renamed the column to l10n_status

I have a lot of errors installing the last dev version on a clean drupal install.

I had to manually make the 6002 update after installation to fix the bug.

@DuaelFr

"lot of errors" is not very helpful. Would you please be more specific and post the errors?

I think I know which errors he means. I had the same on a clean install. The Problem is, that during installation/deinstallation the modules still tries to create the column 'status', so the new column 'l10n_status' is missing.
If you just create it by yourself in 'locales_target' it works fine

this patch worked for me.

in the hook_install, the alter table adds a column named status, but in the hook_unistall, it removes one named l10n_status, and in everywhere in the module, the queries selects the l10n_status column...

Right (and fixed), see #915676: no l10n_status field in locales_target tables

added test on the existence of the fields and the absence of i18nstrings

sorry for the duplicate issue http://drupal.org/node/950100 ; i did not caught immediatly these two have the same root.

The patch looks good. But it brings up the interesting case that due to this issue l10n_update is incompatible with the I18n Stings module. Introducing a l10n_status column in this way was not such a good idea. Can both modules share the same 'status' column? If so, we should revert this change and add the column in the proper way and add checks to i18nstrings update process too.

i agree.

As far as I can read the code of i18n the status column in i18nstrings has a different use and is not compatible with the current column l10n_status for l10n_update module. Therefore using a different column is logical and is required to avoid any conflicts between the modules. The problem however occured in l10n_update_update_6002() where the 'status' column is renamed to 'l10n_status' which is logical from a l10n_update data history perspective, but causes a problem when i118nstrings exist. So, my conclusion is that the patch is correct, but can use a little comment to explain this case.

I found two more (edge) cases:
1. I18n Strings module is disabled but not uninstalled when update.php runs The column gets renamed which breaks I18n Strings module and causes data loss.
2. I18n strings is installed when update.php runs. No l10n_status column gets created.
To prevent the first I changed the check to the existence of i18n_strings table. And to solve the second I added an extra db_add_field() function call.

Updated patch attached.

Sutharsan,

your patch looks good!

Patch committed.

hook_uninstall
function l10n_update_uninstall() {
$ret = array();
drupal_uninstall_schema('l10n_update');
db_drop_field($ret, 'locales_target', 'l10n_status');

i suppose, that in case l10n_update is uninstalled, while i18n_strings is still installed, then i18n_stings loses this field?

so there should be checked if i18n_strings is still installed and the same logic for i18n_strings_unistall()…

is my assumption right?

They definitely should not use the same field IMHO.

i18nstrings module uses field 'status', l10n_update module used 'l10n_status', both modules create and delete their "own" field. I don't see the problem. What am I missing?

Change of status.

Sorry for confusing people here in the issue queue - with the actual versions every case is covered imho.

(so the issue status can set as fixed)

And so be it.