Problem/Motivation
During an upgrade from 8.6.16 to 8.7.3, I ran into an issue with taxonomy_post_update_make_taxonomy_term_revisionable()
.
The following error is thrown during processing of the update.
Base table or view not found: 1146 Table 'drupal.tmp_ed8154taxonomy_term_r__ff793441e7' doesn't exist: ...
.
Through some debugging, I determined that the temporary table, tmp_ed8154taxonomy_term_r__ff793441e7
was related to a custom field, field_default_access
, an entity reference field on my Vocabulary. The default tempary table name, tmp__taxonomy_term_revision__field_default_access, turns out to be 49 characters, and is replaced with the hash format tmp table name, see DefaultTableMapping::generateFieldTableName()
. While tracing the code for the EntityDefinitionUpdateManager::updateFieldableEntityType()
, I discovered that this table was actually being created, but with a different sha255 has, resulting in the table name tmp_ed8154taxonomy_term_r__d348111e42
.
Further discovery determined that SQLContentEntityStorage::saveToDedicatedTables()
doesn't use the "$field_storage_definitions" used through out the update code, but calls $field_definition->getFieldStorageDefinition();
, which results in a different instance of the storage definition, with a different ( getUniqueStorageIdentifier()
), and as a result the table name isn't mapped correctly.
The issue here may be related to
#3056539: Updating an entity type from non-revisionable to revisionable fails if it has non-revisionable fields stored in dedicated tables β
, however it doesn't appear the missing table in that issue is the result of the incorrect hashed table id, but it may be the result of not using the current table mapping correctly.
Proposed resolution
Changes the entity storage to use its internal definitions instead of the ones provided by the entity field manager.
Remaining tasks
#26.2
Review
Commit
User interface changes
None
API changes
None
Data model changes
None
Release notes snippet