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...

#1 625866-1.uc_addresses_migrate.patch4.2 KBdww
Members fund testing for the Drupal project. Drupal Association Learn more


dww’s picture

Status: Active » Needs review
4.2 KB
freixas’s picture

Sounds 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!

dww’s picture

Have 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:

 * Implement hook_migrate_prepare_uc_addresses().
 * Fills in the appropriate UID based on the user migration map, sets
 * is_default properly, handles the address nickname, and maps the
 * country code into the {uc_countries} country_id.
function foo_migrate_prepare_uc_addresses(&$address, $tblinfo, $row) {
  // The map of legacy customers to Drupal users just happens to be map #4 on my site.
  // In general, this will be different for your site.
  $query = db_query("SELECT destid FROM {migrate_map_4} WHERE sourceid = %d", $address->uid);
  $address->uid = db_result($query);
  $address->is_default = ($row->address_book_id == $address->is_default);
  if ($address->is_default) {
    $address->address_name = 'default';
  else {
    $query = db_query("SELECT COUNT(*) FROM {uc_addresses} WHERE uid = %d", $address->uid);
    $address->address_name = $address->first_name . ' ' . $address->last_name . ' #' . db_result($query);

  $query = db_query("SELECT country_id FROM {uc_countries} WHERE country_iso_code_3 = '%s'", $address->country);
  $address->country = db_result($query);

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. ;)

freixas’s picture

Thanks 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).

dww’s picture

Right. 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)

iamjon’s picture


frankcarey’s picture

Status: Needs review » Needs work

The Migrate API has been updated. See: http://drupal.org/node/415190

freixas’s picture

Status: Needs work » Closed (fixed)

Closed due to apparent lack of interest.

dww’s picture

Status: Closed (fixed) » Needs work

There'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.

dww’s picture

Assigned: dww » Unassigned

Although, in fairness, I'm not working on this now, so unassigned is more accurate... ;)

freixas’s picture

Status: Needs work » Postponed

I 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".

No patch is attached to the issue. This is the default state of a new issue, but may also sometimes be used for 'resetting' an issue that has gotten off-course even if the issue has old patches attached.

Needs Work ["CNW"]
The patch needs additional work before it should be reviewed. The author of the patch may indicate that it is incomplete, or the patch has gone through the reviewing process and has received feedback about areas where it needs improvement.

May mean either 1) that the issue is valid and should be fixed, but other related issues (blockers) need to be dealt with first, or 2) that the issue is removed from current active work but the intent remains to return to it. In the first case, please tag the issue "blocked" and say what issue(s) it's blocked on in a comment.

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.