In Drupal 6 and 7, entries in the book hierarchy were stored in the book table and also the menu_links table, with a unique mlid for each entry that was independent of the nid. However, in Drupal 8 there is only an entry in the book table, so the only identifier is the nid. Accordingly, the Book source plugin that comes with the Book module uses the mlid as its identifier, but the Book destination plugin uses the nid as its identifier.
As a result, when you roll back a book migration that uses the Book destination plugin (for example, while testing your migration), the referenced nodes will be silently deleted along with the book entries, preventing you from doing any future book imports until you re-import the nodes. This is undesirable because the rollback should only delete what the import has created, namely the book table entries and the migrate_map. It is also confusing, because the migration status for the deleted nodes does not give any indication that the nodes were deleted!
My quick & dirty solution to this is to run the following queries instead of rolling back the book migration:
db_query("DELETE book FROM book JOIN migrate_map_[my_book_migration] ON destid1 = nid");
db_query("DELETE FROM migrate_map_[my_book_migration]");
drupal_flush_all_caches();
Ideally these queries would be put in a rollback() function for the Book destination plugin, to override the rollback() function provided by EntityContentBase. However, db_query() is deprecated and Connection::delete() does not allow joins, so I'm not sure how to go about it. Thoughts?
Active
11.0 🔥
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
In my local testing with a copy of the d7_book.yml migration this does not happen, though I did run into a different problem ( 🐛 Rolling back book migration does not remove "books" records Closed: cannot reproduce ).