Am working on an update of a 4.7.11 site to 6.4.

Following update docs I disabled all custom modules etc, upgraded to 5.10 then from 5.10 to 6.4.

Have enabled and updated and got most modules working (several evenings work) - have just arrived at CCK.

Now I get:

content module can not be updated. Its schema version is 8. Updates up to and including 1008 have been removed in this release. In order to update content module, you will first need to upgrade to the last version in which these updates were available.

number module can not be updated. Its schema version is 4. Updates up to and including 5 have been removed in this release. In order to update number module, you will first need to upgrade to the last version in which these updates were available.

optionwidgets module can not be updated. Its schema version is 0. Updates up to and including 1 have been removed in this release. In order to update optionwidgets module, you will first need to upgrade to the last version in which these updates were available.

userreference module can not be updated. Its schema version is 3. Updates up to and including 4 have been removed in this release. In order to update userreference module, you will first need to upgrade to the last version in which these updates were available.

Now - perhaps it would have worked if I had enabled, upgraded then disabled the CCK module after updating the core site to 5.10 but before updating to 6.4. It may be that the old (and badly maintained) site I've taken on had an old CCK for 4.x - I don't really know.

I'd like to avoid having to re-do everything I've done so far - is there any way to find the correct CCK to update from (not sure which version includes the correct updates from the error messages here) and just run the updates even if the updates required are for 4.x or 5.x ?

Comments

chrissearle’s picture

chrissearle commented

Figured most of this. I copied in the missing updates to the current update files.

A couple of edits got most of them acceptable - the only thing I haven't figured is content_alter_db_field - in each case we have a field that has 

        $columns['value']['not null'] = FALSE;
        $columns['value']['default'] = NULL;

        $columns_old['value']['not null'] = TRUE;
        $columns_old['value']['default'] = 0;

Now - in the db - I believe this to be editing the content_node_field table global_settings column.

Here's an example:

a:1:{s:5:"value";a:3:{s:4:"type";s:3:"int";s:8:"not null";b:0;s:8:"sortable";b:1;}}

I believe it to be changing that not null bit - but I really struggle forming that syntax by hand. The a:3 - array of three bits - I think its saying:

  "type" -> "int"
  "not null" -> 0
  "sortable" -> 1

What I can't see here is how to set the "not null false default null" - where does the default get set?

yched’s picture

yched commented

Dur to its dynamic set of tables and its collection of contributed field modules, upgrade paths for CCK are a *real* pain to write and maintain.
We simply cannot take the additional burden of supporting straight Drupal [n-2] to Drupal [n] upgrades. As stated on the CCK project page, upgrades to CCK for D6 need be run from a recent (1.7+) and up-to-date CCK D5 install. CCK 4.7 is just too old.
If not clear enough, I just made that a little more explicit on the project page.

Sorry, but I won't endorse advising on this :-(

karens’s picture

karens commented

Also, just to clarify more why this was done, problems with those upgrades was consuming more of the maintainers' time than anything else. And problems with upgrades from older versions created more issues that needed to be fixed than anything other problem, hands down. The upgrade problems were so bad that it didn't look like we could get a D6 version out the door at all. It seemed wrong to have something that only happens once on any individual site keep us from being able to get out a working release.

Not only are the updates a problem to maintain, but CCK changed its database structure several times as it evolved, so there are almost an unlimited number of possibilities for the state of the database prior to the update, making it really really hard to figure out what got broken or how to fix it when things did go wrong. And these upgrades included changes that created conflicts with the core upgrades (when core started using a table that was originally created by CCK), so they could create real havoc.

By asking everyone to get current on the D5 release we can know exactly what people are upgrading from, and the upgrades almost always go better. And this plan worked, our 'upgrade failure' issues have almost disappeared.

chrissearle’s picture

chrissearle commented

Folks - I _do_ understand why you did this - and I _do_ realize that by not reading the page I made a mistake.

I'm _not_ asking you to backfix the upgrade path to d6.

Having sorted out most of it - this boils down to _just_ the question of what the representation of

a:1:{s:5:"value";a:3:{s:4:"type";s:3:"int";s:8:"not null";b:0;s:8:"sortable";b:1;}}

is - or rephrased - "how does the latest CCK represent field information and default values in the database?"

The rest of the issues due to screwing up the upgrade are my own responsibility :)

yched’s picture

yched commented

The elements you mention have no reason to leave in {content_node_field}.global_settings, not sure what they're doing there in your db.
content_update_6000 should have put them in {content_node_field}.db_columns

I'd suggest simply opening the 'configure' page for each one of your fields and resaving them as is. This should write the correct content in {content_node_field}.db_columns

chrissearle’s picture

chrissearle commented
Status: Active » Closed (fixed)

Yep - worked. So - all but one type now working - but thats a type that was manually converted from flexinode years back and has always been troublesome - so that I will probably end up by exporting data, recreating the type and then manually inputting the missing records :)

fnikola’s picture

fnikola commented

I'm receiving the same error 'userreference module can not be updated. Its schema version is 3. Updates up to and including 4 have been removed in this release. In order to update userreference module, you will first need to upgrade to the last version in which these updates were available." and was curious how you ran the userreference updates and how you found them.