Problem/Motivation
The migration tests show that the wrong data is migrated on a D7 site.
In drupal7.php node 1 has the following in the "node" table:
->values(array(
'nid' => '1',
'vid' => '1',
'type' => 'test_content_type',
'language' => 'en',
'title' => 'A Node',
'uid' => '2',
'status' => '1',
'created' => '1421727515',
'changed' => '1441032132',
'comment' => '2',
'promote' => '1',
'sticky' => '0',
'tnid' => '0',
'translate' => '0',
))
The "node_revisions" record for the same node has the following:
->values(array(
'nid' => '1',
'vid' => '1',
'uid' => '1',
'title' => 'A Node',
'log' => '',
'timestamp' => '1441032132',
'status' => '1',
'comment' => '2',
'promote' => '1',
'sticky' => '0',
))
This data is consistent - the original creation was 1421727515, which corresponds to values in both "file_managed" and "taxonomy_index", and it was then updated at 1441032132.
However, after the migration runs the "created" and "changed" values are set to 1529615790, which come from "entity_translation" and "entity_translation_revision".
Why is the core migration not using the values taken from the "node" and "node_revision" tables?
Proposed resolution
Update the dates in the database, see #6.
Other options suggested:
Either:
1. Update the tests so that the "created" and "updated" values are consistent across all relevant tables.
2. Update the migration logic to use the "created" and "updated" values from the "node" and "node_revision" tables in preference to values obtainable elsewhere, e.g. in "entity_translation" and "entity_translation_revision".
Remaining tasks
Commit
User interface changes
n/a
API changes
n/a
Data model changes
n/a
Release notes snippet
TBD
| Comment | File | Size | Author |
|---|
Issue fork drupal-3303925
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3303925-d7-upgrade-migration
changes, plain diff MR !5339
Comments
Comment #2
damienmckennaComment #3
quietone commentedJust updating tags,
Comment #6
quietone commentedIf I understand this correctly I actually think this is an error in the database. The database fixture has not always been created via the UI and sometimes this are not quite right.
However, I think the logic is correct here. That node has been translated so getting the dates from the entity translation table seems to be correct. To verify this, I tested on Drupal 7 starting with the current test fixture. I then added a new node of the same content type (one that uses entity translation) and added a French translation. I then looked at the dates in the node/node_revision and entity/entity_revision tables. Sorry, I didn't output that data. I concluded that the values for created/changed in the entity/entity_revision tables should be the same as the English node in the node/node_revision tables.
I have made a patch that changes those dates and MigrateNodeCompleteTest.
Comment #7
quietone commentedComment #8
smustgrave commentedWhat's a good way to test this?
Comment #9
damienmckennaThen maybe we need test coverage for the data without translations? IMHO that's why the existing test coverage hasn't failed for the revision timestamp value.
Comment #10
quietone commentedI don't see how that will help. The incorrect data was in the entity_translation tables. And the node complete migration is designed to get everything. To run d7_node_complete without translations defeats its purpose.
@smustgrave, the only way I can think of to test this is to use a Drupal 7 site. Add entity_translation and i18n. Enable entity translation for a for a content type and another language. Then add a node of that content type and add a translation. Then examine the timestamps for the node in the node/node_revision and entity_translation/entity_translation_revision tables. You want to make sure that the pattern of changes matches what is in the patch and node tables for drupal7.php.
Comment #11
smustgrave commentedEnglish
Created - 1690313326
Changed - 1690313326
Spanish
Created - 1690313497
Changed - 1690313497
Ran the fixture DB dump to drupal7.php
Verified the nodes created and changed dates are matching.
Comment #13
quietone commentedThere was an unrelated failure.
I retested and tests are passing, so restoring RTBC.
Comment #14
smustgrave commentedRestoring to RTBC.
Comment #16
quietone commentedUnrelated fail, retesting.
Comment #17
quietone commentedTests passing again, back to rtbc
Comment #18
quietone commentedI'm triaging RTBC issues.
I've read the issue summary, comments and patch. All I see is that the proposed resolution does not match what is implemented. I have updated that now.
Comment #20
quietone commentedUnrelated failure, retesting
Comment #21
smustgrave commentedDoes seem to be random
Comment #23
smustgrave commentedSeems to be unrelated.
Comment #24
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue.
While you are making the above changes, we recommend that you convert this patch to a merge request. Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)
Comment #26
smustgrave commentedHiding files and converted #6 to an MR.
Please do not credit me if I did not other wise earn it as all I did was convert this.
Restoring status
Comment #27
damienmckennaI'm going to go back to the point that the problem is the "changed" value is not migrated correctly when translations are not used,
I've used d7_node_complete as a base for several migrations, none of them had translations. When you run "migrate:import --configure-only" it uses d7_node_complete, even if the source site didn't use translations.
Putting this back to "needs work" as I strongly feel the actual problem is not being fixed.
Comment #28
damienmckennaIn practice I find that using the "timestamp" source property gives the correct value migrations, not the "changed" value as it results in the wrong value if the migration is updated (via Drush and migrate_tools).
Comment #29
damienmckennaWhat's weird is that sometimes using changed:timestamp results in incorrect values, but running the migration again corrects it. Go figure.
Comment #30
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 #32
quietone commentedThe Migrate Drupal Module and Migrate Drupal UI are deprecated and they are not in Drupal 12.0.0.
Issues for these modules should now be on the 11.x branch. And the changes are limited to critical and major bug fixes. Other changes are allowed at the discretion of the core Release Managers in consultation with the Migrate subsystem maintainers.