Errors when upgrading from 6.x.1.0 to 6.x.1.2

BS"D

Got the same, also broke my update.php and I cannot access metatags and descriptions that were created with the prior version.

Had the same problem on update.php. Also meta description and meta keywords fields simply vanished.

What i did was this (according to the README.txt on the module folder):
1. Completely deleted the "nodewords" folder from the modules folder
2. Pasted the new folder (from the 6.x-1.2 zip file) in the modules folder
3. Disabled all nodewords modules (Nodewords, Basic meta tags etc) at "admin/build/modules/list" but DONT uninstall them
4. Run update.php
5. Enable all modules needed (Nodewords, Basic meta tags etc is what I needed).
6. Re run update.php

All my meta description and meta titles appeared again, no data was lost!

Hope this helps...

@pipicom: great, you also have the issue reported at #587142: update_6113: No rows written to nodewords_tmp and therefore all data lost. I hope you have a good backup!

BS"D

All fine and good except that it also breaks my update.

@pipicom: thank you - that saved my neck! Or my evening, at least.

The table cache_nodewords is created by two different update functions, in the case it doesn't exist. If the first function (#6114) fails on creating it, then the second function (#6123) should create it.

@recidive: How many rows do you have in the table nodewords?

My update to 6.12 resulted in the loss of an admin link to meta tags and the meta tags in all pages even after enabling all 4 mods. I tried the suggestion in #2 with no change. I was able to access the settings page using an old link, but there were some empty configuration field sets (titles only) and no options available on any node edit pages. When I moved the new NW folder out and replaced the old 6.10 folder, everything returned to normal, including the original tags in the source code...

Wow, when I re-switched the old/new folders to see which fieldsets (above) were empty, now they are filled and the node edit page has the original description and keywords in the text areas/fields but they are not displaying in source code. I'm going back to 6.10 until this is resolved...

Now the settings page of 6.10 has the tabs only with no page below, but the orig meta tags are in the page source and node edit.

What a hassle! I wish I hadn't updated it.

When is this module going to stabilize? There seems to be a radical update every day!

Please tell us what info you need.

@recidive: How many rows do you have in the table nodewords?

When is this module going to stabilize? There seems to be a radical update every day!

The only code that is being code is the development snapshot, which is defined Nightly development snapshot in the page that lists all the page that lists all the releases available. It is not a surprise it can change on a daily basis. The changes are not radical at all, anyway.

@pipicom : Thanks, you saved my life !

I didn't get it, especially because you added Please tell us what info you need (probably I read that sentence, and didn't notice the number you reported); I apologize for misunderstanding.

I was thinking it could be an error caused by the update functions that were trying to update the database table, and caused PHP timeout, or memory allocation errors. With 22 rows that is not surely the case.

As the code to create the cache table is already present in an update function, I could not imagine what would cause such error.

I can verify that I had this issue when upgrading from 6.x.1.0 to 6.x.1.2. Fortunately I had a backup. I disabled, uninstalled then enabled version 6.x.1.2 and it seems to work so it's just the upgrade bit that's causing the issues. I've attached my update log if it's any help. Obviously this bug will be causing many users upgrading a big problem.

I have a similar problem on one of my sites, with less than 100 metatag rows... The update gets stuck for hours on basic_metatags_update_6103

Looked at your update code and seems like you are running UPDATE statements on a table that is being read via SELECT in the loop. Updating the table could be resetting MySQL cursor, screwing up how result set is read.. You should try reading the table into memory OR running a SELECT into a temporary table, that you can iterate on, while safely updating the original one. I do not have time to debug this further, but here are just a few suggestions for you.

Probably temp table solution would be better to deal with upgrading very large data sets, but you have to watch what happens if it fails in between.

Thanks for the analysis, and the help.
I think the best solution is to use a temporary table, which is then renamed when the loop is done, and the old table is deleted.

Temp tables are often not available on inexpensive hosting environments. Do not use them, please! D6 Core removed temp table reqirements for this reason…

I should be clearer with what I mean by temporary table.
I mean that the code should create a table, populate it, and rename it after the old table is deleted.

It is not possible to use UPDATE, or the update function would go in circle for the eternity (as already reported by two persons).

You may also create a normal table that holds temp data and remove it afterwards... but real temp tables causes issues on inexpensive hosting plans

That is what I meant.

Does anybody else confirm that executing an update query could cause any problem with the SQL that loops on the rows of the table?

I noticed the executed query was not correct; while the code counted the number of the rows containing the meta tag Revisit-After, the other query looped through all the database rows. Maybe that was the only cause of the hangup.

I am not 100% sure SELECT cursor and UPDATE statements will conflict, but mixing them is still risky. There could be subtle differences in how this is implemented in different versions of different databases (we are supporting pgsql too, right?), so I would not take chances.

Another way to handle this would be to create a clean new table, populate it with INSERTs and then once they all succeed move it in place of the original one with RENAME TABLE statements. Renaming can be done on multiple tables atomically.

The only thing I am concerned with is that in that way the code should insert all the table rows in the new table, while the current code just updates the meta tag Revisit-After content.
As it is more important to be compatible with all the database engines (and with different versions of the database engine), I will change the code as suggested.

The code has been changed, and committed in CVS. I hope this resolves all the problems.
I have also changed another update function which is copying table rows from a table to another.

Works like magic