When following the procedure in Drupal core's UPGRADE.txt, and upgrading from the recommended release of uuid, 6.x-beta2, dated 2010-Sep-08, the upgrade fails when updatedb attempts to run the update uuid_6004. Starting the upgrade over, and fist advancing uuid to version uuid-6.x-dev, dated 2012-Feb-14 (effectively running update 6004 and 6005 on Drupal 6 prior to the Drupal 7 upgrade), then the upgrade succeeds.
Generally, users are expected to update contrib modules to the latest stable release prior to upgrade. Pushing out a Beta-3 release would make the upgrade process much smoother and more obvious for uuid users.
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | uuid-update-install-uuid-fields-13.patch | 1.73 KB | greg.1.anderson |
| #6 | uuid-update-install-uuid-fields-6.patch | 373 bytes | greg.1.anderson |
| #4 | uuid-update-install-uuid-fields-4.patch | 355 bytes | greg.1.anderson |
| #2 | uuid-update-install-uuid-fields.patch | 980 bytes | greg.1.anderson |
Comments
Comment #1
greg.1.anderson commentedI spoke too soon; although the procedure I described above did allow the updatedb to work, I am still having the problems with missing uuid columns described here: http://drupal.org/node/1255550
I could get the site back to a working state by doing this:
However, I would like this to work cleanly from Drush site upgrade. Any guidance on why these fields are not being added, and how this could be fixed in a more permanent way?
Comment #2
greg.1.anderson commentedInvestigating a little further, I discovered that the missing uuid fields in my upgrade were not some sort of unusual edge case; there simply isn't an update function that adds the fields that are put in by the uuid_install() function. The fix is therefore trivial; just duplicate the operations done by install in an update function. The attached patch worked great for me. However, I did not include the call to uuid_sync_all(); I am not sure if that too might be necessary.
Please also roll a 6.x-beta3 release from the current 6.x-dev branch; otherwise, uuid-6.x users upgrading to Drupal 7 won't get even this far (unless they know to update to 6.x-dev first).
Comment #4
greg.1.anderson commentedHeck, #2 shouldn't have failed testing. I guess the change wasn't so trivial after all. Here is a simpler change -- this is mostly for the test bot.
Comment #6
greg.1.anderson commentedOkay, test bot, this no-code-change patch is for you.
Comment #7
greg.1.anderson commentedAhem. Setting issue status.
Comment #9
greg.1.anderson commentedCould a human please help out here? It looks like uuid 7.x-dev HEAD is failing tests. Tests look okay by inspection; no time to work on this further right now. #2 is the preferred patch for this issue.
Comment #10
greg.1.anderson commentedI had the wrong version set; patches above are against 7.x-1.x-dev, not 7.x-1.0-alpha3.
Comment #11
greg.1.anderson commented#2: uuid-update-install-uuid-fields.patch queued for re-testing.
Comment #12
dixon_Awesome that we have someone that finally have time to test the upgrade path! Thanks very much Greg!
I've had some problems with the d.o test bot here as well. Locally all my tests pass though. I'll take a look at this shortly and commit and roll new releases for both 6.x and 7.x.
Comment #13
greg.1.anderson commentedAwesome -- thanks. I was thinking about it, and figured that the update function needs to call
uuid_sync_all(), just like install does. This patch adds that call. I also added a couple of perhaps-slightly-excessive comments about what to do on the next schema update, to reduce deep-thinking requirements should something change again after a period of time has elapsed. Feel free to trim these if you wish. ("If I had more time, I would have written a shorter comment." :> )Comment #14
dixon_I've tested the patch quite extensively and have now committed it to dev. I will probably roll a new release (the first beta) soon.
I changed one things though, and that was making sure the
uuid.modulefile is included during upgrade. It's needed for theuuid_schema_field_definition()which lives there. I ran into some issue doing the upgrade with UUID disabled.But I also found that the only way to upgrade from 6.x-1.x-dev to 7.x-1.x-dev without data loss is to first upgrade to 7.x-1.0-alpha1 and then upgrade the UUID module separately. The reason for this is because all sub-modules (that was removed for 7.x-1.0-alpha2) was responsible for data migrations from 6.x.
So it's just easiest to advice people to first upgrade to 7.x-1.0-alpha1 and then to following releases. I will probably adding an UPGRADE.txt explaining this.
Comment #15
dixon_I added some notes about upgrading between major and minor versions here: http://drupalcode.org/project/uuid.git/blob/refs/heads/7.x-1.x:/UPGRADE.txt
That documentation does not mention anything about the trickiness with
uuid_update_7102()and how we need to treat the next possible upgrade. That's developer documentation that sits fine in the comments made by greg.1.anderson in the patch from #13.Comment #16
greg.1.anderson commentedVery glad to see this committed; thanks. The added UPGRADE.txt was very helpful. I also added another issue #1482586: Upgrading from UUID 6.x to 7.x, and from 7.x-1.0-alpha1 to later versions to discuss the upgrade path.