During development on a new project, I created a Migration class to import some terms. As it turned out, the architecture changed and we no longer needed the terms. I removed the PHP code that created the Migration class for these terms, but drush migrate-status kept tracking the class. I found that the only way to clean things up was to:

* delete the record in the migrate_status table
* drop the two tables related to the migration class: migrate_map_[name] and migrate_message_[name]

It would be great if there was a drush migrate-delete-migration that helped with this process.

1. Did I miss anything when it comes to removing the data associated with a specific Migration class?

Comments

drewish’s picture

drewish commented

As far as removing old migrations from the migrate-status list, a cache clear (drush cc all) will refresh the class list and handle that. I don't think that'll clean up the tables though. I think the rationale for leaving them is you might disable a migration module, re-enable it and want the map tables to still be there.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented

It is nice to be able to disable your migration module after you've done a bulk migration, but still be able to refer to the mappings, so things aren't cleared out by default. But, if you really want to clean the old stuff out, it's reasonable to give you a simple way to do that.

The migrate_log table would be the only other thing to worry about.

drewish’s picture

drewish commented

Okay, actually seeing the value in this. I had some wacky migrations that got wedged that I needed to delete without doing the full uninstall/re-install of the module.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented

OK, doing a lot of migration refactoring lately, and zombie migrations are starting to really annoy me... So, I'm thinking

drush migrate-deregister ExampleNode

Will perform a Migration::deregisterMigration() - remove ExampleNode from migrate_status, and drop its map and message tables.

drush migrate-deregister --orphans

Will remove anything in the migrate_status table whose class no longer exists... And any migrate_map and migrate_message tables who match the machine_name? Recall (if you ever knew;) that while migrate_map_[machine_name] is the default, migrations can customize the map/message table names, and if the class is gone we can't go back and find out what they were. As a practical matter, though, the odds of anything destructive happening by making an educated guess that they have the default names is pretty slim, so I think we can go ahead and do that.

Feedback welcome, but given that I'm about to go ahead and implement this approach your window is limited;).

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Status: Active » Fixed

Committed for D6 and D7.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Title: drush migrate-delete-migration » drush migrate-deregister

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

drzraf’s picture

drzraf commented
Issue summary: View changes

What the D8-equivalent is?
Use case: I would like to ignore d6_block before running drush mi --all