Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
M
migrate_plus
Manage
Activity
Members
Labels
Plan
Wiki
Custom issue tracker
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Locked files
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Model registry
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Code review analytics
Insights
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Terms and privacy
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
project
migrate_plus
Commits
d6734760
Commit
d6734760
authored
8 years ago
by
Mike Ryan
Committed by
Mike Ryan
8 years ago
Browse files
Options
Downloads
Patches
Plain Diff
Issue
#2744203
by mikeryan: Implement the favbeers field migration
parent
ec47b1e4
No related branches found
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
migrate_example/config/install/migrate_plus.migration.beer_user.yml
+5
-8
5 additions, 8 deletions
...ample/config/install/migrate_plus.migration.beer_user.yml
with
5 additions
and
8 deletions
migrate_example/config/install/migrate_plus.migration.beer_user.yml
+
5
−
8
View file @
d6734760
...
@@ -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
:
{}
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment