When I updated from 6x-1.3 to 6x-1.6, I got the following Failed errors:

availability_calendars module
Update #6102
UPDATE {variable} SET name = 'availability_calendars_settings_system_nodeview' WHERE name = 'availability_calendars_display_nodeview'
UPDATE {variable} SET name = 'availability_calendars_settings_system_hideold' WHERE name = 'availability_calendars_display_hideallold'
UPDATE {variable} SET name = 'availability_calendars_settings_system_monthcount' WHERE name = 'availability_calendars_display_monthcount'
UPDATE {variable} SET name = 'availability_calendars_settings_system-type_poll' WHERE name = 'availability_calendars_poll'
UPDATE {variable} SET name = 'availability_calendars_settings_system-type_forum' WHERE name = 'availability_calendars_forum'
Failed: UPDATE {variable} SET name = 'availability_calendars_settings_system-type_availability' WHERE name = 'availability_calendars_availability'
UPDATE {variable} SET name = 'availability_calendars_settings_system-type_famcamp_reg' WHERE name = 'availability_calendars_famcamp_reg'
UPDATE {variable} SET name = 'availability_calendars_settings_system-type_memory' WHERE name = 'availability_calendars_memory'
UPDATE {variable} SET name = 'availability_calendars_settings_system-type_mens_retreat_photo' WHERE name = 'availability_calendars_mens_retreat_photo'
Failed: UPDATE {variable} SET name = 'availability_calendars_settings_system-type_page' WHERE name = 'availability_calendars_page'
Failed: UPDATE {variable} SET name = 'availability_calendars_settings_system-type_photo' WHERE name = 'availability_calendars_photo'
UPDATE {variable} SET name = 'availability_calendars_settings_system-type_profile' WHERE name = 'availability_calendars_profile'
Failed: UPDATE {variable} SET name = 'availability_calendars_settings_system-type_story' WHERE name = 'availability_calendars_story'
UPDATE {variable} SET name = 'availability_calendars_settings_system-type_webform' WHERE name = 'availability_calendars_webform'
Running the query: "UPDATE {variable} SET name = 'availability_calendars_settings_node_[nid]_%' WHERE name = 'availability_calendars_[nid]_%'" on the following nodes
Failed: UPDATE {variable} SET name = CASE WHEN (name = 'availability_calendars_277_startofweek') THEN 'availability_calendars_settings_node_277_startofweek' WHEN (name = 'availability_calendars_277_showkey') THEN 'availability_calendars_settings_node_277_showkey' WHEN (name = 'availability_calendars_277_firstletter') THEN 'availability_calendars_settings_node_277_firstletter' WHEN (name = 'availability_calendars_277_hideold') THEN 'availability_calendars_settings_node_277_hideold' WHEN (name = 'availability_calendars_277_defaultstatus') THEN 'availability_calendars_settings_node_277_defaultstatus' ELSE name END;
Fixed variables for 1 availability calendar variable settings.

Comments

fietserwin’s picture

fietserwin
Location Le Mont-Dore
commented
Status: Active » Postponed (maintainer needs more info)

I see 2 types of failure messages.

1) Failed: UPDATE {variable} SET name = 'availability_calendars_settings_system-type_[content_type]' WHERE name = 'availability_calendars_[content_type]'

This one happens for 4 content types (availability, page, photo, story). The only reason I can think of why this would 'fail', is if the variable does not exist (and thus support for availability calendars for these types is not enabled). Strictly speaking, I think that an UPDATE with 0 records affected should return success, but I guess that somewhere in the code (deep down in PHP) this is changed into failure. If you dive into the Drupal db drivers, you will see that each real error leads to an warning or notice. So, if you did not see any other messages in the message box or in the watchdog queue you may happily assume success on this.

2) Failed: UPDATE {variable} SET name = CASE ...

This complex query should have been replaced by a few easier queries. Unfortunately I did not change it in the 6.x-1.x branch, only in the 6.x-2.x branch.

I would suggest you install 6.x-2.0 and run the upgrade again. Please let us know the results (= why I changed the status). I will see if and when I will change the 6.x-1.x branch. For now I'm going to unpublish it.

David D’s picture

David D commented

I did end up disabling the module, uploaded the 2.x version, and reenabled, and there doesn't seem to be any issue remaining that I can see. The data also stayed intact, unlike what happened with some of my 1.3 > 1.x update attempts. All is well. And the split-day option is great! Very relevant to my situation. Thank you!

fietserwin’s picture

fietserwin
Location Le Mont-Dore
commented
Status: Postponed (maintainer needs more info) » Needs work

Thanks for reporting back and I am glad the conversion to the 2.x branch went well.

I keep this issue open as a reminder for us to copy the (apparently) working code from the appropriate update hooks from the 2.x branch to the 1.x branch (as well as to prevent the (harmless) failure messages from the first type).

fietserwin’s picture

fietserwin
Location Le Mont-Dore
commented
Version: 6.x-1.6 » 6.x-1.x-dev
Status: Needs work » Fixed

Back ported the update hooks from 6.x-2.x to in 6.x-1.7. Comment #2 indicates that this is the solution for the described problems. So closing this issue and marking it as fixed. Released 6.x-1.7 as last version for the 1.x branch.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

alansch’s picture

alansch commented
Title: Update failures 1.3 > 1.6 » Update failures >> 1.7 & 2.0 (update #6102)
Version: 6.x-1.x-dev » 6.x-2.0
Status: Closed (fixed) » Needs work

Further to this... I have just run the update from 6.x-1.2 to 6.x-2.0 and got the following error on update #6102 ...

Failed: UPDATE {variables} SET name = concat(substring(name from 1 for 23), 'settings_node_', substring(name from 24)) WHERE name LIKE 'availability\_calendars\_%\_%' AND position(substring(name from 24 for 1) in '123456789') > 0

As far as I can see, this is a simple typo on line 261 of availability_calendars.install for 6.x-2.0 ...

 $update_query = "UPDATE {variables} "
    . ($db_type === 'pgsql' // different string concatenation syntax for the supported databases
       ? "SET name = substring(name from 1 for 23) || 'settings_node_' || substring(name from 24) "  // Postgres
       : "SET name = concat(substring(name from 1 for 23), 'settings_node_', substring(name from 24)) ")	// MySql
    . "WHERE name LIKE 'availability\_calendars\_%\_%' "
    . "  AND position(substring(name from 24 for 1) in '123456789') > 0";

where the first line of this fragment should actually read "UPDATE {variable} " as there *is* no table "variables" in the database.

I successfully ran the corrected SQL query in phpMyAdmin, updating the names of 9 entries in the table "variable" to include the "settings_node_" substring.

In looking over the code, I found the same typo on line 161 of the 6.x-1.7 version and line 263 of 6.x-2.x-dev.

fietserwin’s picture

fietserwin
Location Le Mont-Dore
commented
Status: Needs work » Fixed

Committed and released in 1.8 respectively 2.1. Thanks for the good work alansch.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.