We need an upgrade path for phone-7.x-1.x and cck_phone-7.x-*. Migrate would be a good option here.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Nephele’s picture

The approach I took was:

  • Drupal 6 migrations (phone-6.x and cck_phone-6.x) are done via the CCK content_migrate module, used to migrate all Drupal 6 fields to Drupal 7.
  • Drupal 7 phone (phone-7.x-1.x) migration is handled by the standard module update mechanism, i.e., by running update.php after installing the latest module version. That process includes altering all database schemas as necessary, updating the field_config and field_config_instance information, as well as the basic data migration.
  • Drupal 7 cck_phone (cck_phone-7.x-1.x) migration is handled by a CCK Phone Converter (phone_cck_convert) sub-module that I included as part of my phone module code. It can be enabled to do the migration, then disabled/uninstalled. Once run, the cck_phone module can also be disabled/uninstalled.

I've tested both my phone-7.x-1.x and cck_phone-7.x-1.x migrations, at least with some basic tests. I haven't done any tests of the drupal6 migrations (since I'd have to set up a whole drupal6 installation as a starting point), but the content_migrate module allows most of the complications to be handled much more easily, and many of the details of the migration share helper functions with the 7.x-1.x migrations. So I think the drupal6 migrations are pretty close to functional.

However, it's going to take more than just cutting-and-pasting the functions into cdale's code to merge them into the current code....

cdale’s picture

Sorry about stepping on your toes! I needed something quick and it just kind of came together.

If you can put up what you've got, I'm sure it won't take too much to adapt.

Nephele’s picture

I'm attaching a "patch" that simply adds all my upgrade-related functions and files unaltered into your code, to at least identify what functions, files, etc. are going to be added.

However, making this actually be a functional patch immediately starts to run into chicken-and-egg problems. For example, in phone.install I'm moving the current schema into a version-specific function at _phone_field_schema_7200(), to address problems mentioned in http://drupal.org/node/150220. But there are already at least two patches posted that also alter the schema (in #1928688: Coding details in the 7.x-2.x branch and #1928382: Rename "comment" field). So what version of the schema should get put into _phone_field_schema_7200()?

Any ideas on how to not get paralyzed by conflicting patches?

cweagans’s picture

Any ideas on how to not get paralyzed by conflicting patches?

Most of the time, just don't worry about it. Patches will likely need rerolled over time, but I'll try to keep that necessity to a minimum.

Nephele’s picture

Oops, I left out all the helper functions in that last patch. None of the helper functions will work because they're calling my libphonenumber functions -- on top of all the other little tweaks that need to be done to make this patch remotely useful.

cdale’s picture

cdale’s picture

The above issue is probably most likely caused because there is currently no upgrade path.

cdale’s picture

How's the upgrade stuff coming. I've noticed Nephele has made a few commits since I last looked. Is it at a point where setting up some D6 & 7 installs might be worthwhile to give upgrading a test?