This isn't a big issue, but it's been slightly confusing for me. Basically, to duplicate this, you need one content type that has two nodereference fields being filled in from the node_map table "nodeid" field. I'll try to describe steps to duplicate what I'm seeing:

  1. Do a standard migration (example content type: course)
  2. Add the "node_map" table into Table Wizard and make the foreign key available
  3. Repeat steps 1 and 2 for another table (example: vendor)
  4. Add another related table into Table Wizard that needs to reference both of the content types (example: material. A material needs to be associated with the vendor (who sells it) and a course (in which the material is used)).
  5. Add a relationship between the table from step 4 and the foreign key from step 2
  6. Also add a relationship between the table from step 4 and the foreign key from step 3
  7. Edit the view for the table in step 4
  8. Add both relationships to the view
  9. Add the nodeids from both of the node_map table as fields in the view (be sure to give them custom names such as "Course nodeid" and "Vendor nodeid"
  10. Create a content set based on the view
  11. When filling out the mappings into the two nodereference fields, the first nodeid field name is the correct custom name, but invariably, the second custom name is incorrect and is just the same field name as the first nodeid field name (see screenshots)

Comments

mikeryan’s picture

OK, I'll look into this when I have a chance (which may not be for a little while, plenty of higher-priority issues to deal with...). I assume that when selecting the 2nd duplicate name, you do get the correct (misnamed) field migrated? If the actual migration is broken, I would bump this up to critical...

Thanks.

attheshow’s picture

Yeah, it still migrates just fine as long as you pick the right one. :)

mikeryan’s picture

Status: Active » Fixed

Finally got to this, thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.