Drupal 8 Migrate in Core weekly meeting

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
ultimike's picture
Posted by ultimike on May 19, 2015 at 8:27pm
Start: 
2015-05-20 21:30 - 22:00 America/New_York
Organizers: 
ultimike
Event type: 
User group meeting

https://plus.google.com/b/106269343178096590461/events/cn1fu7qa9th381t7o...

Join our Google Hangout on Air weekly meeting.

This week we'll be focusing on the discussion of this issue: https://www.drupal.org/node/2463909

Ping ultimike on #drupal-migrate if you'd like to participate.

Thanks,
-mike

Comments

Pardon any syntax errors

Posted by ultimike on May 21, 2015 at 2:12am
ultimike's picture

Pardon any syntax errors below - written quickly as notes during the call. Please correct in comments.

  • Adam is deep into https://www.drupal.org/node/2487568 - he feels this is a major issue. This involves using the Entity Validation system. Despite the fact that we're using entity->save(), that doesn't necessarily mean that entity->validate() has been called and passed. The way the Migrate tests are written, it seems that the data in the tests may not be complete enough to pass validation tests. Adam is finding that to fix this (ensure Migration destination plugins call entity->validate()) he's modifying a lot of tests - specifically in the test setups to ensure dependencies are run.
  • Moving migration configurations into a templating system (https://www.drupal.org/node/2462233 and https://www.drupal.org/node/2463909) - we all agreed this is probably the most reasonable solution. We discussed making it generic enough so that if it is not just a migrate thing, but can be use by another part of core, then it could become not-migrate specific. Mike Ryan started working on this, he said he had trouble discovering templates based on a tag in the .yml. Benjy feels we can make them queryable (based on some work he started in https://www.drupal.org/node/2462233). With the templating system, only those configurations that the user is actually using will go into the active config store. Without the templating system, even is a contrib module only needs a single class out of migrate_drupal, all of the migrate_drupal configs will end up in the active store. With templating contrib modules can dictate which migrations are active. Config entities get us discoverability and a much easier path to using the UI to configure migrations.
  • About moving some source, configuration, process, and destination plugins into their associated core modules (move taxonomy-related migrations into core/modules/taxonomy). We'd have to figure out what, exactly we want to move (source, config, process, destination). The downside of this is that migrations will remain in the active store as long as the core module is enabled.
  • Migration Groups - Mike Ryan has things RTBC, waiting for alex to commit at this time...
  • Dumps - https://www.drupal.org/node/2469623 - RTBC - waiting on alex.

-mike