#2302307: Support shared configuration between migrate groups is introducing full-featured migration groups to the migrate module - entities that hold shared configuration among related migrations and provide a canonical grouping of migrations for use by contrib migration tools. There is currently a "migration_groups" key in the migrate schema which serves a slightly different purpose - the migrate module itself implements no semantics around this, and migrate_drupal currently uses it like a tag to indicate which Drupal version(s) a given migration is applicable to. The name of this key is confusing already, and will be all the more so when proper groups are committed.
Rename the key to something that does not contain the word "group".
N/A
Is a configuration schema change considered an API change?
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | rename_migration_groups-2466797-1.patch | 50.42 KB | mikeryan |
Comments
Comment #1
mikeryanRenaming migration_groups to migration_tags.
Comment #4
mikeryanBump... Any feedback on the key name? I'm not wedded to migration_tags, if someone else prefers just 'tags' or has another thought... Or, should we take this out of migrate and give migrate_drupal a specific 'drupal_version' setting?
Should we try to commit this before (or at the same time as) #2429085: Track current state of migrations, to avoid an interim where there are both 'migration_group' and 'migration_groups' keys?
Comment #5
benjy commentedI like migration tags, maybe lets do this first to avoid any naming confusion.
Comment #6
alexpottThe problem I have with this is that as this code shows we're not using them for anything. Given that why even have them?
Comment #7
benjy commentedThey're used by the UI for running all D6/D7 migrations, I think the Drush runner will also need these tags. The may also be handy for custom migrations as a way to associate migrations together, although Groups might be solving most of that use case.
Comment #8
mikeryanRight, the way drush or the UI will use this is to determine the Drupal version, then load and run the migrations with e.g. migration_tags='Drupal 6'. This is implemented now using the migration_groups key in the migrate_upgrade module (to be added to core).
Comment #9
benjy commentedComment #10
alexpottI'm still not convinced by the usage of tags to contain the information about what the source of the migration applies to. Because using the word tags and thinking about a migrate UI to me it implies that you could remove this tag but that is not the case.
Comment #11
mikeryanYou could remove the tag, though - a quick-and-easy way to omit particular migrations from your D6 upgrade would be to remove the Drupal 6 tag.
Comment #12
xjmAssigning to @alexpott for his followup per his request.
Comment #16
mikeryanTestbot seems flaky, at least #2357997: Add test coverage for tablesort header link titles seems to have the same problem. Let's try again...
Comment #18
mikeryantestbot seems to be over its little meltdown, restoring status.
Comment #19
xjmJust a note, when retesting patches, it's a good idea to document what the specific test failures were on the issue. This information is lost when retest is clicked, and that means we lose some indication of whether a patch might be introducing random fails or whether there is a bug in HEAD.
Comment #20
alexpottMigrate is not frozen in beta. Committed 9e11c08 and pushed to 8.0.x. Thanks!
We agreed in a recent meeting that migration's should also have an additional key in the source data about about the source is. This is because tags will be editable in a UI but the fact that the source plugin works for Drupal 6, or Wordpress 3, or whatever is not.