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.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | migrate_d2d-support_for_legacy_uid-1854124-1.patch | 1.07 KB | JoshuaWynn |
Comments
Comment #1
JoshuaWynn commentedHere is the patch that adds in the feature as mentioned above.
Comment #2
ultimikeI just tested this patch on the latest version of Migrate D2D and it worked fine for me...
-mike
Comment #3
kristen polComment #4
mikeryanI'm a little skeptical that this is a generally worthwhile addition to the module.
OK, make your case;)!
Comment #5
mikeryanComment #6
mccrodp commentedHi 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".
Comment #7
mikeryanFor 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.