Add capability of disabling hooks (and events?) during migration

We don't have anything like this right now, i'm not sure if its something we'd put in core, but it could easily be achieved in contrib.

Whether this is doable is irrelevant. There's this crazy notion of "make it fast via code no matter what!" instead of throwing more hardware to it. Unless everything you migrate is a complex tree, migrations are highly parallelizable and it's much , much cheaper to rent a real lot of hardware for the duration of the actual migration than trying to code the fix to the mess left without hooks and QA the results. Hardware is cheap. People are expensive.

Also, someone does this, years pass and then whoever ends with the pile of subtly broken data comes to the core queue complaining how the update / migrate path is broken. Thanks, but no thanks.

If it's to be done, contrib is the place to do it.

Note that in the D7 world it's not just useful for performance - it's handy for turning off behavior that's undesirable during migration (most notably email notifications).

Then blackhole emails but blackholing hooks and events (even if easily doable) is something I very strongly recommend against because you. will. corrupt. your. database.

It is common for site owners to wait until all of the insertions during a nightly cron run of new data is finished for various reason. A common use case is for Solr index updates. Due to the nature of data migration and running multiple passes at it to add in new field collections, paragraphs, etc... a lot of times disabling the entity update hooks makes sense. Then in the "final" pass at the nodes, you just re-enable the hooks and everything gets fired and your solr index gets its updates.

I should be clearer. Saving a field collection or paragraph also fires off an entity save on its parent. Disabling the entity hooks when you are going to just update the entity again in a few seconds is a /potential/ valid reason. I'm sure there are others. Used with care, disabling hooks can greatly improve migration performance.

Edit: nevermind, I am out of this discussion.

Current use case: Pathauto is has gone off the rails, no clear reason why, and my second taxonomy term in a migration is indefinitely looping over itself to recompute it's path alias. While fixing this would be ideal, it has become an urgent launch blocker. I'd much prefer to suppress pathauto from firing during the migration then bulk generate the aliases when I am done.

Because of module dependencies, uninstallation of pathauto would be tricky, and much more likely to lead to errors from hidden dependencies than the lack of up-to-date aliases.

It'd be useful to be able to disable geocoding during import.

Just to provide another use case here -- we have a custom hook that makes external API calls on user create actions. We don't have any control over the hardware/usage limits of the API services and with the number of users we have to migrate, it will be necessary to manually remove the code during import (it also executed on login, which is much more practical in our use case). It would be nice to have an easy way to white/blacklist hooks during an import.

A way I have commonly suggested to implement this feature is to add a fake destination field, let's call it "do not run hooks'. With a name like that, it won't get saved to the destination, but we can check for its existence and then respond accordingly. If its solr indexing or geoip-ing or anything we can confirm the insert/update/whatever is happening from a migration, and act accordingly.

+1

There is a sandbox project that supports this functionality, see Migrate booster https://www.drupal.org/sandbox/onkeltem/2828817

I created a full project here: https://www.drupal.org/project/migrate_boost