Fatals in make_menu_link_content_revisionable when combined with make_taxonomy_term_revisionable

This might be related to #2554235: Make the content entity storage and entity query use the last installed definitions instead of the ones living in code and or #2274017: Make SqlContentEntityStorage table mapping agnostic .

This looks like the same issue that I reported and @amateescu was working through with me a couple days ago #3039586: Cannot rename tmp_2362aemenu_link_content_revision to menu_link_content_revision He was working on trying "making the content entity storage use the last installed definitions instead of the ones from code"

Temporary work around was to comment out the event subscriber saving all views.
Commenting out $view->trustData()->save(); from core/modules/views/src/EventSubscriber/ViewsEntitySchemaSubscriber.php:202

I posted a patch in #2554235-19: Make the content entity storage and entity query use the last installed definitions instead of the ones living in code which should fix this issue.

I'm just posting the error output that I got from drush updb for this, because I didn't find this issue when I was search for an existing one.

SQLSTATE[42P01]: Undefined table: 7 ERROR: relation "taxonomy_term_revision" does not exist

[notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
[error] SQLSTATE[42P01]: Undefined table: 7 ERROR: relation "taxonomy_term_revision" does not exist
LINE 4: INNER JOIN taxonomy_term_revision revision ON revision.revis...
^: SELECT revision.revision_id AS revision_id, revision.langcode AS langcode, revision.revision_user AS revision_user, revision.revision_created AS revision_created, revision.revision_log_message AS revision_log_message, revision.revision_default AS revision_default, base.tid AS tid, base.vid AS vid, base.uuid AS uuid, CASE base.revision_id WHEN revision.revision_id THEN 1 ELSE 0 END AS "isDefaultRevision"
FROM
{taxonomy_term_data} base
INNER JOIN {taxonomy_term_revision} revision ON revision.revision_id = base.revision_id
WHERE base.tid IN (:db_condition_placeholder_0, :db_condition_placeholder_1); Array
(
[:db_condition_placeholder_0] => 4183
[:db_condition_placeholder_1] => 4184
)

[error] Update failed: menu_link_content_post_update_make_menu_link_content_revisionable 
[warning] Invalid json in modules/composer/matomo/composer.json
[error] Update aborted by: menu_link_content_post_update_make_menu_link_content_revisionable 
[error] Finished performing updates. 

Edit: this occurred for me during the update to 8.7 from 8.6.15

I experienced this same issue, after first dealing with the issue(s) mentioned in 3039586 (see @joelpittet's comment #6 above). As per @BrightBold's fix there (#13 in that issue):

I deleted the menu_link_content and menu_link_content_revisions tables before re-importing the database and then it ran successfully.

(note, I also deleted the "old" and "tmp" tables associated with that update)

After that, the update process proceeded to the issue detailed in this thread. @joelpittet's fix in #7 above resolved the issue for me as well.

[temporarily] Commenting out $view->trustData()->save(); from core/modules/views/src/EventSubscriber/ViewsEntitySchemaSubscriber.php:202

+1 for both of these assists, thank you all!

Trying to follow the advice in #11 above I encountered:

`[error] SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal.menu_link_content' doesn't exist`

Which then led to the abort/error message:

`Update aborted by: menu_link_content_post_update_make_menu_link_content_revisionable`

I have tried as well the advice from #11 but I got same error as explained in #12:

[error] SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal.menu_link_content' doesn't exist

2 days trying on fixing the update failure form 8.6.15 to 8.7.0 with more than 20 attempts all ended with failure...

The only solution worked for me was what mentioned in #7.

1. Revert back to your last previous Database before the 8.6.15 to 8.7.0 core update (hopefully you have a backed up DB somewhere)
2. Temporary comment in the $view->trustData()->save(); from core/modules/views/src/EventSubscriber/ViewsEntitySchemaSubscriber.php:202
3. Run the Database update.
4. Remove again the comment form the $view->trustData()->save();

Hope it will help somebody and thank you @joelpittet

#7 work for me

Thank you @joelpittet and @C.E.A

#7 works for me too.
Thank you very much

Confirming #7 as well.

Confirming #14.

#14 Worked but I had to perform the following changes on my install.

Perform steps 1 & 2 in #14, then perform these database changes

DROP TABLE menu_link_content_revision;
DROP TABLE menu_link_content_field_revision;

Then perform steps 3 & 4 from #14

Revert back to your last previous Database before the 8.6.15 to 8.7.0 core update (hopefully you have a backed up DB somewhere)

@watson.sm If you followed the #1 about reverting the db to your original one before doing any of the other points then their is no need to below steps:

DROP TABLE menu_link_content_revision;
DROP TABLE menu_link_content_field_revisio

because drupal 8.6.15 doesn't have the menu_link_content_revision

Just a note for the confusing of others...

Not sure this is exact issue as OP, but upon trying to install updates (non Drush) I'm getting the following error:

menu_link_content module

Update make_menu_link_content_revisionable

Failed: Drupal\Core\Entity\EntityStorageException: The entity update process failed while processing the entity type menu_link_content, ID: 5. in Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema->copyData() (line 216 of /home/xxx/public_html/core/lib/Drupal/Core/Entity/Sql/SqlFieldableEntityTypeListenerTrait.php).

I show neither (1) menu_link_content_revision nor (2) menu_link_content_field_revision tables, as mentioned throughout above. My closest table is menu_link_content, but I have 30-35 (!!!) tmp files with variations of 1-2. Can/should I delete these tmp files outright or export first (if importing again is possible?) Not really sure what I'm doing.

I'm trying to avoid reverting the database but starting to wonder if that's the only solution. I've tried everything else from this and other threads I can find.

The problem is that we've had a team of 4 people entering content into the site for the last 3 days since the drupal update was performed. The thought of losing that content is bad but it might be the only option. Any ideas?

Such a terrible update.

I tried twice to update the core when it was 8.7.2 and then 8.7.3, again the same issue !!!

it wasted a day of my time !!!

From what I'm seeing, it appears that the core update build out is either performing an entup which is causing the table to be created prior to the database update that requests the same thing, or there's not a flag/check informing the core processes that the table has already been built. When I encountered the issue, I dug into my DB to find that the table that updb was creating was already in existence, but empty. Being that I was working from a development instance when discovering this issue, I took a snapshot of my DB, then deleted the following empty tables: menu_link_content_field_revision, menu_link_content_revision, taxonomy_term_revision, taxonomy_term_field_revision, taxonomy_term_revision__parent. At that point, I re-ran my updb command and the process completed successfully. I'm wondering if this is just an order-of-operations issue that is causing the problem. Just my thoughts...

I have tried the steps in #14
and #19

But i still get an error after
> drush updb

I can post the full error output - but its pretty long, and I'm not sure if that's rude to do so.

>  [notice] Update started: system_post_update_add_expand_all_items_key_in_system_menu_block
> PHP Fatal error:  Declaration of Drupal\datetime\Plugin\views\argument\Date::buildOptionsForm(&$form, Drupal\datetime\Plugin\views\argument\FormStateInterface $form_state) must be compatible with Drupal\views\Plugin\views\argument\ArgumentPluginBase::buildOptionsForm(&$form, Drupal\Core\Form\FormStateInterface $form_state) in /home/.../web/core/modules/datetime/src/Plugin/views/argument/Date.php on line 27

Additionally:

it seems there are 2 declarations:
Date::buildOptionsForm(&$form, Drupal\datetime\Plugin\views\argument\FormStateInterface $form_state)
ArgumentPluginBase::buildOptionsForm(&$form, Drupal\Core\Form\FormStateInterface $form_state)

buildOptionsForm() function is using different parameters and during an upgrade, it causes a fatal error.

https://api.drupal.org/api/drupal/core%21modules%21views%21src%21Plugin%...
https://api.drupal.org/api/drupal/core%21modules%21views%21src%21Plugin%...
... both functions should have same arguments.

it looks like some component has a version mismatch, causing a fatal error during update.

can i use backtrace to find the mismatch? or change my php settings maybe?

I have applied a patch given in issue "https://www.drupal.org/project/drupal/issues/3052318"

When I perform "Drush updb", menu_link_content issue gets resolved.

But I got another error in taxonomy revision table.

Failed: Drupal\Core\Entity\EntityStorageException: Exception thrown while performing a schema update. Cannot rename                [error]
taxonomy_term_revision to old_034be4taxonomy_term_revision: table taxonomy_term_revision doesn't exist. in
Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (line 1607 of
/var/www/<docroot>/app/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Hi ravimane23 ,

Did you find solutions for your problem , even i am getting same issue

Hi nishantkumar155,

I have written an update hook in a custom module as below -

  // Skip update when entity is already revisionable.
  if (\Drupal::database()->schema()->tableExists('taxonomy_term_revision')) {
    \Drupal::database()->schema()->dropTable('taxonomy_term_revision');
    \Drupal::database()->schema()->dropTable('taxonomy_term_field_revision');
    \Drupal::database()->schema()->dropTable('taxonomy_term_revision__parent');
    \Drupal::database()->schema()->dropTable('taxonomy_term_revision__field_safe_name');
  }

After adding these lines my database update runs successfully.

Hi ravimane23

To which version are you updating? 8.7...?

After appling the patch: https://www.drupal.org/project/drupal/issues/3052318 i still have other issue: Base table or view not found: 1146 Table 'xxxxx.menu_link_content_revision' doesn't exist: SELECT t.revision_id AS revision_id

Cheers,

#7 didn't fix so followed davidalan at #24.
This did the trick, so thanks for sharing.

Hello,

I applied below changes in my update hook & successfully gets updated to 8.7.8.

 // Remove revision tables before the run update.
	  if (\Drupal::database()->schema()->tableExists('menu_link_content_revision')) {
        \Drupal::database()->schema()->dropTable('menu_link_content_revision');
        \Drupal::database()->schema()->dropTable('menu_link_content_field_revision');
      }

      // Skip update when entity is already revisionable.
      if (\Drupal::database()->schema()->tableExists('taxonomy_term_revision')) {
        \Drupal::database()->schema()->dropTable('taxonomy_term_field_revision');
        \Drupal::database()->schema()->dropTable('taxonomy_term_revision__parent');
        \Drupal::database()->schema()->dropTable('taxonomy_term_revision__field_safe_name');
        \Drupal::database()->schema()->dropTable('taxonomy_term_revision__field_online_store_link');
        \Drupal::database()->schema()->dropTable('taxonomy_term_revision__field_online_store_image');
      }

Thanks

confirming #24 worked also, thank you!

This worked for me, after having /update.php with an error (8.6 to 8.7):

1. Delete (PostgreSQL) database tables menu_link_content_revision and menu_link_content_field_revision IIRC.
2. Comment line 202 $view->trustData()->save(); in drupal/web/core/modules/views/src/EventSubscriber/ViewsEntitySchemaSubscriber.php
3. Run /update.php again.

#24 worked for me using the following Drush commands:

• drush sql-query "DROP TABLE menu_link_content_revision";
• drush sql-query "DROP TABLE menu_link_content_field_revision";
• drush sql-query "DROP TABLE taxonomy_term_revision";
• drush sql-query "DROP TABLE taxonomy_term_field_revision";
• drush sql-query "DROP TABLE taxonomy_term_revision__parent";
• drush sql-query "DROP TABLE taxonomy_term_revision__field_link_address";
• drush sql-query "DROP TABLE taxonomy_term_revision__field_display_title";
• drush sql-query "DROP TABLE taxonomy_term_revision__field_post_url";

Hello @ll, thanks for the effort and discussion so far. I have the joy of updateing an old Drupal 8.6.1, in times of Drupal 11, and also came to this issue, hopefully the last one ever, but just in case:
drupal/web/core/lib/Drupal/Core/Database/Driver/mysql/Schema.php -> renameTable()

  public function renameTable($table, $new_name) {
    if (!$this->tableExists($table)) {
      $this->connection->schema()->dropTable($table);
//      throw new SchemaObjectDoesNotExistException("Cannot rename '$table' to '$new_name': table '$table' doesn't exist.");
    }
    if ($this->tableExists($new_name)) {
      $this->connection->schema()->dropTable($new_name);
//      throw new SchemaObjectExistsException("Cannot rename '$table' to '$new_name': table '$new_name' already exists.");
    }

    $info = $this->getPrefixInfo($new_name);
    $this->connection->query('ALTER TABLE {' . $table . '} RENAME TO `' . $info['table'] . '`');
  }