Update function changes the field id into a smallint

I have marked #680478: Update failing from 6x-1.8 to 6x-1.11 as duplicate of this report.

I have marked #681490: Update 6162 Fails When Upgrading Directly From 6.x-1.0 to 6.x-1.11 as duplicate of this report.

The code has been changed, and committed in CVS.

Thanks for the report, and the time took to investigate in the issue to Galiagante, and miketitsch.

I have created a new version, which is not made visible from the project that handles the module versions.

I know you hate issues being reopened, but there is nothing to let users to know what to do, so reopening with doco tag.

Should we manually update this field? Just ignore it till latter upgrades? Upgrade to a unreleased beta?

------------------------------------------------------------------------------------------------

As an aside, trying the update directly from this field 'id' from 6169 update code on 6.x-1.11 (which was the same code from 6162) fails. Is there something that is going to change the 'id' field between these two updates? If not, then this query will still fail here.

Failed: ALTER TABLE {nodewords} CHANGE `id` `id` INT unsigned NOT NULL DEFAULT 0

And the warning:
user warning: Incorrect integer value: '' for column 'id' at row 1 query: ALTER TABLE nodewords CHANGE `id` `id` INT unsigned NOT NULL DEFAULT 

The cause as you probably know, is that MySQL 5 (windows issue?) isn't casting from '' to 0

-- my version
select version();

version()
5.1.37-community

-- Raw update SQL to run to do what that update was trying to do in a single SQL statement

UPDATE nodewords set id = '0' WHERE id = '' OR id IS NULL;
ALTER TABLE nodewords CHANGE `id` `id` INT unsigned NOT NULL DEFAULT 0;

[edit: The MySQL server is running in strict mode - this is not an issue otherwise]

Good to hear, just apply the fix. I'll pass that onto the guy doing 25+ updates :)

Thanks

If still an issue just re-run the two queries above. Null & empty strings can not be in the new data set, and a redundant alter call should not should break anything (untested).

There is an error in this code:

  db_change_field($ret, 'nodewords', 'id', 'id',
    array(
      'type' => 'varchar',
      'length' => 255,
      'not null' => TRUE,
      'default' => '',
    ),
  );

on the next to last line there is a comma which in the dev version causes
Parse error: syntax error, unexpected ')' in /var/www/www.domain.com/htdocs/sites/all/modules/nodewords/nodewords.install on line 1075
Note the comma is on line 1074

And while I am on it, this commit in same set:

/**
 * Implements hook_update_N().
 */
function nodewords_tokens_update_6103() {
  $ret = array();

  variable_del('nodewords_remove_extra_whitespaces')

  $ret[] = array(
    'success' => TRUE,
    'query' => 'Removed obsolete persistent variables',
  );

  return $ret;
}

causes a
An error occurred. http://venus.astrocalc.com/update.php?id=4&op=do <br /> <b>Parse error</b>: syntax error, unexpected T_VARIABLE in <b>/var/www/www.domain.com/htdocs/sites/all/modules/nodewords/nodewords_tokens/nodewords_tokens.install</b> on line <b>76</b><br />

due to missing end semicolon for the 'variable_del' function.

oohh jeezz there is more, you also removed the opening comment tag for next function in that commit, so you have

/**
 * Implements hook_update_N().
 */
function nodewords_tokens_update_6103() {
  $ret = array();

  variable_del('nodewords_remove_extra_whitespaces');

  $ret[] = array(
    'success' => TRUE,
    'query' => 'Removed obsolete persistent variables',
  );

  return $ret;
}

 * Implements hook_uninstall().
 */

making it crashing badly. Ush what was you smoking that day? ;-)

so of course, it's not fixed ;-)

and huh even more, nodewords_admin.module also crashes from this commit as you left out a } somewhere, probably the one in the end closing up the function. Well well we all have our days and this surely wasn't yours - but that one of the occations it's great to belong to a community stepping in for ya! ;-)

this is how I think that last function should be

function nodewords_admin_mass_update($ids, $type, $operation = 'delete') {
  if ($operation == 'delete') {
    if (count($ids) <= 10) {
      db_query("DELETE FROM {nodewords} WHERE id IN (" . db_placeholders($ids, 'int') . ") AND type = %d",
        array_merge($ids, array($type))
      );

      if ($type == NODEWORDS_TYPE_PAGE) {
        db_query("DELETE FROM {nodewords_custom} WHERE pid IN (" . db_placeholders($ids, 'int') . ")", $ids);
      }

      drupal_set_message(t('The update has been performed.'));
    }
    
    else {
      $batch = array(
      'operations' => array(
        array('_nodewords_mass_delete_batch_process', array($ids, $type))
      ),
      'finished' => '_nodewords_admin_mass_update_batch_finished',
      'title' => t('Processing'),
      'progress_message' => '',
      'error_message' => t('The update has encountered an error.'),
      'file' => drupal_get_path('module', 'nodewords_admin') .'/nodewords_admin.admin.inc',
      );
      batch_set($batch);
    }
  }
}

So, this is first fixed in 1.12?

Is this ==> http://drupal.org/node/681080#comment-2463532 the 6x.1.11 Version without the smallint issue then? So should we update to this version? Maybe someone could give a hint how to patch the 6x.1.11 for all people who are using this module-version on production sites? Any help would be really appreciated.