While testing #2746541: Migrate D6 and D7 node revision translations to D8 there were problems in the revisions tab after the migration. When rerunning the migration without translation enabled the problem persisted. This issue is to resolve fix whatever is wrong with the revisions.
The following is the problem description from Comment #86 in #2746541: Migrate D6 and D7 node revision translations to D8
The d6 fixture has node 1 with 3 revisions and post migration only the latest one shows up on the revisions tab, node/1/revisions.
Screenshots:
Drupal 6, node/1/revisions
Drupal8, node/1/revisions
For both d6 and d7 more testing of the revision migration is needed.
The d6 fixture appears to be broken in regard to node 1 and it's 3 revisions. Adjusting that seems to help, however, maybe a revert action should be done on node 1? Not sure about that.
The d7 fixture needs a new node with revisions.
The migration of the revisions, that is d6_node_revision and d7_node_revision work correctly. That is good news.
The remaining problem is that d6_term_node_revision adds the revision log entry of the current revision to the first revision of node 1. Maybe another node can be added to the fixture to confirm that.
Screenshots:
Drupal 6, node/1/revisions
Drupal8, node/1/revisions
The D7 results are ok
Drupal 7
Drupal 8 d7 migration
Add more tests of the node revisions for D6 and D7
Modify the d7 fixture by adding a new node, with revisions but without translations
Modify the d6 test fixture to correct the vids.
Find out why the revision log is incorrect for story node nid=1, vid=1 when the migration is done via the UI. Or maybe a followup.
| Comment | File | Size | Author |
|---|---|---|---|
| #22 | 3073088-21.patch | 25.73 KB | quietone |
| #22 | interdiff-18-21.txt | 625 bytes | quietone |
| #20 | 3073088-20.patch | 25.73 KB | quietone |
| #20 | interdiff-18-20.patch | 625 bytes | quietone |
| #18 | 3073088-18.patch | 25.12 KB | quietone |
Comments
Comment #2
quietone commentedThis adds tests for more revisions in D6 and a new test for revisions in D7.
Comment #3
quietone commentedAh, the revision ids for node 1 in the drupal6 test fixture are wonky.
Comment #4
quietone commentedMade some adjustments to the d6 source fixture and the migration is a little bit better. However, the 1st revision has the revision log entry for the latest (3rd) revision. If I rollback the node revision and node migrations for this content type, story, and re-migrate that does not happen. That is, the revision log is correct. I am puzzled.
Screenshots:
Drupal 6, node/1/revisions
Drupal8, node/1/revisions
Comment #6
quietone commentedSpent a long time trying to find out why 01/10/2015 revision has a log of 'modified rev 3' after the migration. This happens when running the migration from the UI. Once the migration was complete I attempted to rollback the revisions and import one row at a time. I then discovered that rollback of node revisions does not clear the revisions at all, they are still there an accessible via the UI. The only thing that was done was to clear the map table.
Another thing I tried was to delete d6_node_revision.yml and run the migration from the UI. Then I used drush to 'drush mim d6_node:story' to bring in the revisions. This time the revision log entry was correct.
Can anyone explain this?
Comment #7
dpiCheck and compare values of the 'revision_translation_affected' column in node_field_data
Comment #8
quietone commentedrevision_translation_affected is true for all nodes and it is a field not set by the migrations.
Comment #9
dpiI should have said {node_field_revision}, but you may be aware that field in particular can have odd results, especially if you rely on default behaviour.
Comment #10
quietone commentedI've run into it only when working on #2746541: Migrate D6 and D7 node revision translations to D8 but I admit I yet to really grasp how it works. And if the default behaviour can have odd results, it seems even more difficult to figure out.
Comment #11
mikelutzOh dear.. The EntityRevision destination doesn't implement its own rollback method, it just uses the default from EntityContentBase which assumes either a nid or nid-langcode destination identifier. EntityRevision uses a vid or vid-langcode identifiers, and from reading the code, I suspect attempting a rollback of a node_revision migration could result in deleting the node who's nid matches the vid you are actually trying to delete, which makes that a critical issue that needs to be filed.Thankfully I was wrong. The revisions count as an entity update, which by default are preserved on rollback. It's buggy and wrong, but no data loss issues, thankfully.
Comment #12
mikelutzComment #13
gábor hojtsyDoes this mean the migrated revisions data is also broken or we don't know?
Comment #14
xjmComment #15
quietone commentedChanged the d6 test fixture so that the node 1, which has revisions, 1, 5 and 2001, has revision 2001 as the current hoping that would help find out why the first revision has the log entry of the last revision. It doesn't but leaving it for now. The d7 fixture has changed as well, to add a new node with 3 revisions, similar to d6. Post migration the revision tab for that node matches the d7 version so whatever is wrong is with d6 and I am just not seeing it.
Drupal 7
Drupal 8 d7 migration
Comment #17
quietone commentedFound out it is the d6_term_node_revision migration that is altering the log field.
Comment #18
quietone commentedFix the upload test.
Comment #20
quietone commentedFix Upgrade7Test, increase node count by 1 since I added a new node to the fixture.
Still need to find out why the comment count changed for D6.
Comment #21
dpiNeed summary and title update. If it’s a problem with migration then Revisions page has little to do with the issue.
Comment #22
quietone commentedOops, let's try that again.
Comment #23
quietone commented@dpi, yes it does. Was planning on doing that this morning.
Comment #25
plach@Gábor Hojtsy asked me to chime in here.
I could not figure out what's wrong by looking at the IS, but I just want to point out that in D8 we are filtering the revisions list by affected translation language. This means that in D8 only revisions that have changes in translations matching the current (content) language will be listed in the page. This is tracked via the
revision_translation_affectedflag.I assume that the D6 screenshot is displaying revisions for a single (node) translation, so it's correct to expect that they should all be displayed in D8 as well. Maybe the
revision_translation_affectedflag is not being populated correctly?Comment #26
quietone commentedI wonder if this help fix the problem with the revision log, #2597650: Term references should be incorporated into D6 node migration
Comment #27
quietone commentedI wonder if this is related. #2754787: d6_term_node migration overwrites node changed timestamps
Comment #28
quietone commentedI wonder if the 'wonky' rev ids in D6 were because of a revert? I really don't know. It would be worth adding explicits tests of that for d6 an d7.
Comment #37
quietone commentedThe Migrate Drupal Module was approved for removal in #3371229: [Policy] Migrate Drupal and Migrate Drupal UI after Drupal 7 EOL.
This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.
The deprecation work is in #3522602: [meta] Tasks to remove Migrate Drupal module and the removal work in #3522602: [meta] Tasks to remove Migrate Drupal module.
Migrate Drupal will not be moved to a contributed project. It will be removed from core after the Drupal 12.x branch is open.
Comment #39
quietone commentedMigrate Drupal is removed from the Drupal 12 branch. Only necessary tasks, or critical or major bug fixes will be make on the Drupal 11 branch. There has been no interest in fixing this for 7 years.
Therefore, this is closed as won't fix.