Update 6162 Fails When Upgrading Directly From 6.x-1.0 to 6.x-1.11

See #681080: Update function changes the field id into a smallint.

I have the same problem, it has to do with one node type where the key is duplicate but the description is referring to different pages.

Any solutions? Or ideas as to a module that is incompatible or update that makes something incompatible?

I upgraded from 6.x-1.2 to 6.x-1.11.

Nothing seems to be broken but the "ALTER TABLE nodewords ADD UNIQUE KEY nodewords_type_id_name (type, id, name)" index was not created.

Thanks for any suggestions or should I back out of it?

this is not the same as the other issue, theres a different failure because of duplicates that get created.. well the ID before the update is string, like "providers", its probably a SEO path.. after the update it gets converted to an integer and its 0, it happens when updating from .8 to .9
ive checked the url_alias table for a dst parameter == to that id column and i got 0 results, so i guess this is why duplicates get created
to fix it, i update manually (with drush actually) to .8, remove those problematic entries, then do the rest of the upgrades.. and i get no errors and the index gets created.. i guess you can create it manually to recover from a broken upgrade, but delete those conflicting IDs before

also, the duplicates the poster got, '5-65535-keywords', mine were more like '10-0-something'.. i think there might be something to this

Tag.

Does anyone happen to have a backup or .sql file of their metatag tables from before you updated? If they don't contain any sensitive data, please attach them to this issue so we can test.

I don't think a backup is really necessary to see what went wrong here. That update sets the size of the "id" column to a smallint. So if you have more than 65535 nodes, all NIDs higher than 65535 (the maximum for a smallint) were converted to that number, causing duplicate IDs (and data loss).

There's nothing we can do to un-damage any sites that ran that update, but we can prevent this problem in the future and ensure database consistency by removing the offending size property (thus preventing the data loss) and adding another update just like it to ensure database consistency (converting people back from the "small" size to normal).

This was also "fixed" in #681080: Update function changes the field id into a smallint, but I definitely think my approach is more sane than that issue. There's no reason why we need to convert the field to a varchar and then back to an integer to change its size.

Here's a new version of the patch that takes into account AlexisWilke's suggestion in #888042: Update 6162 potentially destroys data. In addition to converting the "id" column into a smallint, the "id" column also had an issue of not being able to caste an empty string into a zero in PostGRES. So one more additional fix is needed in that update to simply update empty strings to a "0" string before doing the type conversion.

Re-applied the patch, added a CHANGELOG line, changed to the 6.x-1.x-dev version. Should work.

Rerolled.

The 6162 update no longer exists in the current 6.x-1.x codebase and both nodewords_update_6164() & nodewords_update_6168() are wildly different to what's referenced here - anyone want to have another look through this?

Could someone remove the 1.11 release or at least post a big warning on the project page about the 65535 limit as this causes data corruption resulting in loss of data when upgrading large sites.

I added a note about the issue, doing anything with the existing releases will just cause untold problems.

Does this patch apply to 1.11 solving the critical smallint issue?

I've reviewed this error. The problem has been completely resolved in the current 6.x-1.x-dev codebase. Unfortunately, due to the database structures that were changed, this could have definitely caused data loss with IDs (nid, tid, uid) higher than 65,536 and there is no way to recover the lost data, it has to be manually restored & fixed from a backup.