Closed (fixed)
Project:
Migrate
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
17 Jul 2012 at 20:44 UTC
Updated:
10 Aug 2012 at 20:21 UTC
Jump to comment: Most recent file
Term migration is no-doubt a cool feature that helps to automatically migrate nodes that has term reference fields.
A site usually has more than just contents, and views and panels are the most common building blocks. They may rely on taxonomy, and use certain term IDs as settings. Occasional rollback of term migration(s) will invalidate all the views and panels
that use previously migrated terms. A fool-protection is strongly required here.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | migrate-rollback_action-1690092-7.patch | 10.42 KB | mikeryan |
| #2 | term-rollback-protection-1690092-2.patch | 1.66 KB | lex0r |
Comments
Comment #1
mikeryanIs this meant for migrate_d2d, or do you consider it a general Migrate issue?
Can you explain a bit more about the situation? How would you visualize Migrate protecting you if you build things like views and panels on migrated data then rollback that data?
Comment #2
lex0r commentedMy explanation is inside the patch ;)
It allows to protect a term migration from occasional rollback that will break the site.
Comment #3
lex0r commentedOkay, a use case:
Bob who did migration didn't warn John not to rollback term migration, though some of the views used certain term IDs as filter values, and some of the panels used term IDs as context.
John decides to re-migrate everything, and he ends up with views/panels not working since they rely on non-existent terms.
My idea is an option to term migration that prevents it from rollback (we don't really need to remigrate taxonomy so many times, especially when there's something already built on top of it!).
Comment #4
mikeryanThis is rather narrow - only terms, and only for migrate_d2d. In the meantime, I'm seeing other scenarios where I'd like to protect particular rows from rollback - see the role_mappings support in migrate_d2d, where we want to be sure we don't delete any pre-existing roles we've mapped to. This calls for a more general solution in Migrate itself.
I think what we need is a new map table column for rollback behavior - default value of 0 for normal rollback, 1 to not delete the destination item. Maybe we could also use this with file migrations for the preserve_files option - a 2 would mean delete the DB tracking of the item, but not the underlying resource (file).
Comment #5
q11q11 commentedAny use of resetting auto-increment column in particular tables (in delicate situations) ?
As example - source taxonomy data changed, but we already protect destination from re-migration and we must preserve TIDs.
Comment #6
mikeryanI would not mess around with the auto-increments - I take it you're imagining if you reset it and remigrate you'll get exactly the same tids, but that's not going to be reliable - the order of migration might not be deterministic, if source data has been deleted or added in the middle it will throw the count off, if someone manually creates terms, etc.
The goal of this issue is to let you simply preserve the tids, there shouldn't be any need to hack the increments.
Comment #7
mikeryanOK, here's a patch - @lex0r, can you try this? To prevent rolling back of all content in a given migration, add to your migration constructor:
To prevent particular rows from being rolled back, add this to prepareRow():
Comment #8
mikeryanCommitted for D6 and D7.