Migrate had a vision. This module pisses on that vision and makes a mess out of it.

http://cgit.drupalcode.org/migrate_plus/tree/src/Plugin/migrate/process/...

what is this? I have no words. Write two migrations. Process plugins have absolutely no business writing the database.

Comments

chx created an issue. See original summary.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Status: Active » Closed (won't fix)

I do encourage people, where practical, to implement separate migrations for related entities like terms and files. Of course it's optimal to separate concerns and deal with each entity on its own terms, as well as having each stage of the pipeline focus on its particular purpose.

However, data does not always come cleanly separated into logical bins corresponding one-to-one with Drupal entities. Things are jumbled together, or embedded within other things. To be able to migrate such "things" in a separate migration, providing each unique thing as a distinct row from a source plugin, often requires implementing some sort of preprocessing step (say, to explode each comma-separated tag field and dedupe the results across the data set). entity_generate provides a tool to accomplish in minutes (and a couple lines of YAML) what may take hours (and dozens or hundreds of lines of PHP) otherwise. The disadvantages of using entity_generate:

  1. The generated entities are not tracked in map tables. The main practical problem with this is that they cannot be rolled back.
  2. The migration implementation does not fit the Platonic ideal of how a migration should be implemented.

Since rollback is primarily a development tool, rarely used on production sites, #1 is usually not a significant drawback.

#2 of course is the objection here. There are trade-offs to be made between strict adherence to an architectural vision and pragmatism. A tool is provided here that sacrifices a pure approach to process plugins for development time and effort. Each developer (and their clients) can choose whether that trade-off makes sense in any given project. I will not remove that choice.

chx’s picture

chx commented
Status: Closed (won't fix) » Active

If you can make up an entity during process it doesn't take at all more effort to get it to an entity destination. If it's jumbled together, well, you need to get the data into the entity_generate plugin just as well.

Do you have an example where this plugin is significantly simpler than writing a second migration?

Footnote:

 *   type:
 *     plugin: default_value
 *     default_value: page

This can be done with a source constant much simpler, using default value on its own has not been used for years. https://www.drupal.org/node/2171833

chx’s picture

chx commented
Title: Remote entity_generate, the very idea is abhorrent » Remote entity_generate
chx’s picture

chx commented
Status: Active » Closed (won't fix)