I'm setting up a script for a client that turns a table full of hierarchically related tables into a set of nodes, linked by node references. the node and user reference import handling can automatically map old values to newly created users and nodes if titles and names are used to do the matching, but not if IDs are used.

The attached patch (unless I'm misunderstanding things) fixes that: it runs noderef and userref values through _migrate_xlat_get_new_id() before they're saved, allowing one set of nodes to be created, then the nodes that reference them to be created with proper translation of the old foreign keys to the new node ids.

CommentFileSizeAuthor
#6 599120.patch932 bytesstella
cckref-mapping.patch1.22 KBeaton

Comments

moshe weitzman’s picture

Status: Needs review » Needs work

eaton mentioned in IRC that he would work on this a little more. i think the line $value = intval($value);
has to be removed. otherwise, this patch looks good to me.

eaton’s picture

Status: Needs work » Needs review

Actually after taking a second look at it, I think the patch should be okay. The context for those changes is:

              if (intval($value) > 0) {
                $value = intval($value);
                if ($newvalue = _migrate_xlat_get_new_id('node', $value)) {
                  $value = $newvalue;
                }
              }

What this means is that $value=intval($value); will only ever be called if the value should, in fact, be an int. That line was there before this patch, and shouldn't cause any problems. We just add an extra case to see whether the resulting integer is also mapped to a new key value.

moshe weitzman’s picture

I should elaborate. The problem with this code as I see it is that if you get a miss for some reason in _migrate_xlat_get_new_id(), you still get a node ref recorded for an id that is presumed to be a node. Thats kinda chaotic behavior, IMO. I think there should be no node reference in this case. thats why i suggested to remove: $value = intval($value);.

mikeryan’s picture

Component: Code » Contrib module support
Status: Needs review » Needs work

I think a better approach would be to allow mapping explicitly by old ID, Drupal nid/uid, or title/username. See as an example the comment support for migrating authors.

mikeryan’s picture

Project: Migrate » Migrate Extras
Version: 6.x-1.x-dev » master
Component: Contrib module support » Code

CCK support has been moved to the migrate_extras module.

stella’s picture

Component: Code » Migrate Extras Features
Status: Needs work » Needs review
StatusFileSize
new932 bytes

Here's a patch re-roll against the 'migrate extras' module.

I agree with @mikeryan, that longer term, a better approach might be something like that of the 'node authoring' fields, just wasn't quite sure how best to approach it within the current structure.

stella’s picture

Component: Migrate Extras Features » CCK
thekenshow’s picture

I applied and tested this patch on 6.x-1.0-beta1 and ran into an issue because my referenced node titles begin with digits. This causes intval($value) to convert the title to an integer by truncating after the opening digits (e.g., "89584333-c1ea-4f7d-a819-e13e05baa2ae" becomes the integer 89584333) and then assigning that as a nid. I played with combining an is_string() check, but that errs in the other direction ("89584333" is identified as a string). So for the time being, perhaps add a warning that imported titles cannot begin with a digit or they'll be converted to int and evaluated as nid.

mikeryan’s picture

Status: Needs review » Closed (won't fix)

Migrate and Migrate Extras V1 are no longer supported. Migrate V2 natively supports mapping referenced IDs.