Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I've been converting an old osCommerce site to an UberCart site, making heavy use of migrate module. I added support to import uc_address records. There are a few rough spots regarding the uid field, at least until #610128: Can't add external and internal tables' columns to the same view is fully resolved. But, this is working great in my testing, and IMHO would be a lovely addition to the uc_addresses module. Stay tuned for a patch...
Comment | File | Size | Author |
---|---|---|---|
#1 | 625866-1.uc_addresses_migrate.patch | 4.2 KB | dww |
Comments
Comment #1
dwwComment #2
freixas CreditAttribution: freixas commentedSounds great! I did a migration by hand, so I know how useful an automated approach would be.
I would like to understand more about the "rough spots". What works, what doesn't?
I just did a 10-second review of the patch. If there are any instructions needed to use this patch (or any "gotchas") could you also patch the README.txt file to include those? Thanks!
Comment #3
dwwHave you used migrate.module at all? The problem with UIDs is as follows:
- Your legacy site probably has its own customer_id fields or whatever in its address book.
- Part of migrating from your old site to Drupal will convert the legacy customers into Drupal users. This will result in a {migrate_map_N} table that maps legacy.customer_id to drupal.uid values for all the migrated users.
- So, when you then go to import the address book records into Drupal, you want to import them using the Drupal UID, not the legacy customer_id.
However, until #610128: Can't add external and internal tables' columns to the same view is resolved, you can't actually add a relationship to one of your table wizard views so that your legacy {address_book} table can JOIN on the {migrate_map_N} table in your Drupal site to map the customer ids.
Therefore, to make this work, you need to do a bit of extra processing, define hook_migrate_prepare_uc_addresses(), and do a little query to map the legacy customer_id into the Drupal uid. Something like this:
This also handles smart nicknames for the imported addresses, and maps the source data country from ISO 3 country codes into the {uc_countries} integer code that {uc_addresses} expects... Mapping countries is somewhat complicated -- see #627866: Introduce concept of field formatters or conversion handlers? and #626380-1: Add migrate.module support for uc_order (orders, order product details, etc) for more...
Anyway, yeah, I can put a link to this issue into the README with instructions about using migrate.module, since this is now pretty decent documentation. ;)
Comment #4
freixas CreditAttribution: freixas commentedThanks for the explanation.
No, I haven't used the migrate module at all. At the time I needed it, I'm not sure it existed (at least, no one seemed to have a good migration strategy for osCommerce -> Ubercart).
Comment #5
dwwRight. I'm doing an osCommerce migration now. There didn't exist a great migration strategy as of a week ago, either, but I'm writing it ;)
#620812: Support importing UberCart product fields with migrate.module
#626380: Add migrate.module support for uc_order (orders, order product details, etc)
...
Comment #6
iamjon CreditAttribution: iamjon commentedSubscribing
Comment #7
frankcarey CreditAttribution: frankcarey commentedThe Migrate API has been updated. See: http://drupal.org/node/415190
Comment #8
freixas CreditAttribution: freixas commentedClosed due to apparent lack of interest.
Comment #9
dwwThere's interest, see #850180: Ubercart + Migrate Module - Working module attached. for example. I'd appreciate it if you didn't close things that aren't actually done. ;) Thanks.
Comment #10
dwwAlthough, in fairness, I'm not working on this now, so unassigned is more accurate... ;)
Comment #11
freixas CreditAttribution: freixas commentedI just reviewed the Status definitions at http://drupal.org/node/156119 and you are correct: I should not have set this issue to "Closed". However, neither "Active" nor "Needs work" is correct. I am setting it to "Postponed".
I have no intent to return to this (as described for "Postponed"). Do you? If so, then we can leave this as "postponed". If there is no realistic hope that you will return to this, then "Won't Fix" would be more appropriate. It's easy enough to open a new issue (or re-open this one, as people seem to like to do) once someone appears with the intent.