Skip to content
Snippets Groups Projects
Commit d6734760 authored by Mike Ryan's avatar Mike Ryan Committed by Mike Ryan
Browse files

Issue #2744203 by mikeryan: Implement the favbeers field migration

parent ec47b1e4
No related branches found
No related tags found
No related merge requests found
...@@ -76,26 +76,23 @@ process: ...@@ -76,26 +76,23 @@ process:
# entirely. # entirely.
bypass: true bypass: true
field_migrate_example_favbeers: beers
# The following is blocked on https://www.drupal.org/node/2590993.
# This looks like a simple migration process plugin, but there's magic # This looks like a simple migration process plugin, but there's magic
# happening here. We import nodes after terms and users, because they have # happening here. We import nodes after terms and users, because they have
# references to terms and users, so of course the terms and users must be # references to terms and users, so of course the terms and users must be
# migrated first - right? However, the favbeers field is a reference to the # migrated first - right? However, the favbeers field is a reference to the
# beer nodes which haven't yet been migrated - we have a circular relationship # beer nodes which haven't yet been migrated - we have a circular relationship
# between users and nodes. The way the migration system resolves this # between users and nodes. The way the migration system resolves this
# situation is by creating stubs. In this case, because no beer nodes have # situation is by creating "stubs". In this case, because no beer nodes have
# been created, each time a beer is looked up against the beer_node migration # been created, each time a beer is looked up against the beer_node migration
# nothing is found, and by default the migration process plugin creates an # nothing is found, and by default the migration process plugin creates an
# empty stub node as a placeholder so the favbeers reference field has # empty stub node as a placeholder so the favbeers reference field has
# something to point to. The stub is recorded in the beer_node map table, so # something to point to. The stub is recorded in the beer_node map table, so
# when that migration runs it knows that each incoming beer should overwrite # when that migration runs it knows that each incoming beer should overwrite
# its stub instead of creating a new node. # its stub instead of creating a new node.
# field_migrate_example_favbeers: field_migrate_example_favbeers:
# plugin: migration plugin: migration
# source: beers source: beers
# migration: beer_node migration: beer_node
migration_dependencies: {} migration_dependencies: {}
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment