I've been working on a set of custom continuous migration scripts (D6 to D7) using/extending the base migrate module. I discovered this module well after having already performed several migrations of users and content. The comment migration classes that are included in this migrate D2D module saved me a lot of time. However, I found that I couldn't migrate the original D6 source comment UIDs--essentially making the author for every comment 'admin' or another default user of my choosing.

I ended up replacing the following code in the base comment.inc file to add in a feature that allows direct 1:1 mapping of the source to destination comment UID. This option assumes that you already have users imported in (with 1:1 UIDs assigned) from the same D6 source database.

Before:

    if (isset($user_migration)) {
      $this->addFieldMapping('uid', 'uid')
           ->sourceMigration($user_migration)
           ->defaultValue($default_uid);
    }
    else {
      $this->addFieldMapping('uid')
           ->defaultValue($default_uid);
    }

After:

    if (isset($arguments['legacy_uid'])) {
      $legacy_uid = $arguments['legacy_uid'];
    }
    else {
      $legacy_uid = FALSE;
    }

    if ($legacy_uid === TRUE) {
      $this->addFieldMapping('uid', 'uid');
    }
    elseif (isset($user_migration)) {
      $this->addFieldMapping('uid', 'uid')
           ->sourceMigration($user_migration)
           ->defaultValue($default_uid);
    }
    else {
      $this->addFieldMapping('uid')
           ->defaultValue($default_uid);
    }

The new argument legacy_uid is set in the custom extended module *.module file.

My situation is likely a one-off case, but, I imagine there are others out there that could benefit from this option. I'll attach a patch in a subsequent comment for others to review.

Comments

JoshuaWynn’s picture

Here is the patch that adds in the feature as mentioned above.

ultimike’s picture

I just tested this patch on the latest version of Migrate D2D and it worked fine for me...

-mike

kristen pol’s picture

Status: Active » Reviewed & tested by the community
mikeryan’s picture

I'm a little skeptical that this is a generally worthwhile addition to the module.

  1. The use case seems pretty narrow - it requires migrating comments into a D7 environment where the users have been migrated by some other means with uids preserved, this doesn't seem like a common occurrence to me. And if it is - what about nodes, or any other kind of entity with references to uids?
  2. Even for that use case, it's simple enough to override the mapping in a derived class. Is a new option to do this really necessary?

OK, make your case;)!

mikeryan’s picture

Status: Reviewed & tested by the community » Postponed (maintainer needs more info)
mccrodp’s picture

Hi Mike,

Would this be the method you would recommend to preserve uids in general when migrating users: "override the mapping in a derived class"?

I did an import of users yesterday, first time to use this module and I noticed it didn't preserve uids. I would have thought that preserving uids is a very common migration requirement, maybe a (simple) override is fine, but I'd argue that some simple flag or UI option could be handy for this use case too?!

Many thanks,
Paul.

EDIT: Moved my specific issue to #1350324: "first parameter must either be an object or the name of an existing class" on line 552 of "user.module".

mikeryan’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)

For the original request, the use case is narrow enough and easily enough obtained by overriding the class that I'm not willing to add a new feature just for that, closing.