Problem/Motivation
While working on
#2897114: Products migrated to both nodes and products →
, we discovered it would be awful nice to change the migration definition very early on in its life. Basically, the derived definition for a node migration needs to be changed to point to a destination of commerce product, instead of node. In more complicated use cases, we need to alter field and field instance config migrations to point to a product as well.
Some description of what a deriver is and why it is important:
Derivers are run when dynamically discovering and registering a plugin. It provides a way to provide a template of the configuration of the plugin. After the deriver runs (one time), it never gets executed again for that plugin. Deriver could also be called a generator.
This is important, because for migrations, we only want to modify the default template of the derived migration a single time. If the migration is run via the core migrate_drupal_ui, there is no difference. Because we never store the migration configuration for any later use. But if you are running a custom migration, this becomes important. Because the migration configuration gets altered every. single. time. the. migration. config. is. read.
Case in point:
#2937366: alterations to migrations in commerce_migrate_ubercart_migration_plugins_alter() are too far-reaching →
In this issue, a consumer of the commerce_migrate contrib module wants to alter the definition of the commerce migration that was created. But commerce_migrate only had the option of plugin_alter. The definition alters from commerce_migrate are too heavy handed. Because they run every single time. When really we only want the alter to run during discovery/derivation/generation. But there's no other option, so we do it any way.
More cases in point where this is blocking things are being daily added to contrib. Field collections and ECK would all like to use this. Commerce too. Anything that has a custom entity-like thing would benefit from this feature.
Proposed resolution
Add a base migration deriver class that allows us to change the generated/derived migration definitions.
Another question was hooks vs. events. Events are better DX because they are more testable. The main consumers of this alter event are envisioned to be contrib modules. These consumers already know how to write code. The majority prefer to write OO. And they want to be able to run unit and other types of tests. Using an event, testing is easier than using a hook.
Remaining tasks
- (link to detailed steps on how to create one).
The use of an event is questioned in
#68
📌
Alter derived migration definition early in life
Needs work
. There needs to be a decision of hook or event.
User interface changes
n/a
API changes
Adds an event and a test for subscribing to and builds a base derive for migration derivers (not to be confused with source, process or destination derivers).
Data model changes
n/a