Tested against a real-world D6 site with 38 vocabularies and 3774 total terms, some hierarchical.
Settings and vocabularies seem to have migrated fine.
Term migration fails with the following error message:
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'name'
cannot be null: INSERT INTO {taxonomy_term_data} (tid, vid, uuid,
langcode, name, description__value, description__format, weight,
changed) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1,
:db_insert_placeholder_2, :db_insert_placeholder_3,
:db_insert_placeholder_4, :db_insert_placeholder_5,
:db_insert_placeholder_6, :db_insert_placeholder_7,
:db_insert_placeholder_8); Array
(
[:db_insert_placeholder_0] => 91
[:db_insert_placeholder_1] => ad_groups
[:db_insert_placeholder_2] =>
d5165013-f69b-47fb-a800-ebe3b324ba44
[:db_insert_placeholder_3] => und
[:db_insert_placeholder_4] =>
[:db_insert_placeholder_5] =>
[:db_insert_placeholder_6] =>
[:db_insert_placeholder_7] => 0
[:db_insert_placeholder_8] => 1406812319
)
33 terms seem to have migrated fine, none of them have a parent term.
All terms in the D6 source database have a name value. The term with tid 91 is on the root level of a hierarchical vocabulary and has several child terms. It is not in a vocabulary called 'Ad groups' (which does exist).
In the results of an unordered SELECT * FROM term_hierarchy query to the D6 database 91 is the parent in the first row that has a parent value other than 0.
Comments
Comment #1
aleksipInvestigated this a bit more and it does seem that the error occurs when processing the first term that has a parent term.
A stub row is created for the parent term, but
$destination_plugin->import($stub_row)fails.Comment #2
aleksipAfter further testing with a fresh D6 install it seems that hierarchical term migration goes fine if parent terms have been migrated. But if they are not, migration fails as in the original issue description.
The cause seems to be a missing (dummy) name field value in the stub term entity. I have tried to search for the code where dummy field values are set, similar to
createStubin D7 migrate, but haven’t been successful so far.Comment #3
aleksipHere is a patch to
MigrateTaxonomyTermTestthat should show the bug.Comment #4
benjy commentedComment #6
aleksipHere is a patch containing a fix as instructed by chx (a new
EntityTaxonomyTermclass) and the modifications toMigrateTaxonomyTermTestin #3.With this patch applied the original real-world migration test mentioned in the issue description completed successfully.
Comment #7
benjy commentedGood work, set to "Needs review" so the bot can run the test suite.
Comment #8
dawehnerThe patch fixes the problem for me nicely! Great work!! Using a stub entry until the migration ran over the corresponding taxonomy term is a great idea!
Note: Just this single class is neeed, all other use statements can be removed.
Comment #9
benjy commentedRemoved use statements plus a few other minor changes.
Comment #10
penyaskitoPatch tests this casuistic, and #8 has been cleaned up. So RTBC.
Updated issue title.
We only need to specify a class with a plugin id and it overrides entity:*? I <3 this feature.
Comment #11
dawehnerYeah, indeed, this is really cool.
Comment #12
webchickThanks for testing the migrate path for D8!
Committed and pushed to 8.x. Thanks!
Comment #15
swathikris commentedTested against a real-world D6 site - 31 vocabularies ~4500 terms and some hierarchical with multiple parents
Get the same Integrity constraint violation, when it comes to migrating terms with multiple parents.
eg: in d6 term_hierarchy
|tid|parent|
|13|0|
|14|13|
|15|13|
|16|0|
|17|13|
|18|13|
|19|17|
|19|20|
|20|13|
Comment #16
bkeller commentedPreparing for a D6 to D8 migration and while the migration completes, taxonomy terms are not fully migrated. Vocabularies are migrated, and then a few (7) terms succeed before returning the following error:
I thought it might be a data issue, since this was marked as fixed in the latest release. I found one term missing a name, but it was not related to the above error, and deleting it from the DB had no affect.
Just to see what would happen, I modified the database tables to allow for NULL values:
At which point the taxonomy terms did migrate, the content types had the appropriate taxonomy term fields, but no taxonomy terms were applied to any content. I also received the following error:
This site has 5700+ nodes, 6 vocabularies, and 490 terms in term_data. I've posted in this issue because it seems to be the same problem, but will start a new bug report if needed.
Comment #17
scotwith1tLooks like this needs to be re-rolled against the current dev? /core/modules/migrate_drupal/src/Tests/Dump/Drupal6TaxonomyTerm.php doesn't exist in the current version, so this patch does not apply...
Comment #18
bkeller commentedIt looks as though my above issue was related to using the beta10 version rather than pulling the current dev version from git.
After rebuilding and re-running a migrate with the current dev version I no longer get this error, and taxonomy terms do migrate.
There are other issues, but we'll post those in the appropriate threads.
Sorry for the confusion.
Comment #19
drupali commentedMigration (Drupal 6 to Drupal-8.1.7) does not bring any taxonomy terms and content taxonomy fields. I get the error
Failed to lookup field type array ( 0 => 'content_taxonomy', 1 => 'default', ) in the static map.
Any help would be highly appreciated !