I've inherited a large, enterprise Drupal 8 site in which we have many "Mismatched entity and/or field definitions" warnings reported in the status report. The site is currently running on Drupal 8.9.13, and we'd like to get these issues addressed before upgrading to Drupal 9 (not least of which because they seem to cause problems after the upgrade when I attempt to run database updates).

I know these issues were introduced during - or at least before - the update from Drupal 8.6 to 8.7 - long before I was responsible for the site. I'm a little uncertain if database updates were skipped at some point - but those continue working during site updates to both modules and core. But "drush entup" back then was clearly not run while it was still available. (And I understand why that's been deprecated for production sites since 8.7.)

Important points:

  • I've attempted both devel_entity_updates and the entity_update modules to see if these would help us in a development environment, but neither will perform the changes due to "The SQL storage cannot change the schema for an existing field with data." So those modules have not been a solution for us unfortunately.
  • The site has a few alphas, a few betas, and a few RCs installed - not many, but a few. (More than I would have chosen to install for a production site.) In my update attempt to Drupal 9, many of these were uninstalled and pulled out. This did not make these mismatch messages go away.
  • I'm comfortable with massaging the underlying field tables directly in SQL: I did so in a case where I needed only to add two columns just so I could uninstall a module. If I must, I can use this brute-force method on other fields.
  • I've read through numerous Stack Exchange questions about this - including how to write update hooks to alter the schema of these fields, and I'm happy to do that if I can determine what actually differs.
  • I know how to roll back and re-run the DB updates for specific modules, but my attempts at doing so (for one or two modules that I thought might be the culprits) didn't solve the problem. (Yet.) I may try more of this - going further back - if that seems a way to determine where these issues arose.

And that's my main question:

What is the best way to determine what differs between the definitions and the schema for a given entity or field?

I know how to look at the field definitions themselves using a SQL command similar to this (on a node-based field in this example):

SELECT value FROM key_value WHERE collection='entity.storage_schema.sql' AND name='node.field_schema_data.field_name_of_my_field';

I can then take that value, make it readable (i.e. indent it), and then compare it to the actual field table in the database directly to see what might be different.

BUT - is this the best way to determine what differs? Am I barking up the wrong tree, or is there something else I'm missing? Or ... is this in fact the best way to figure the differences out?

Many thanks for any insight that can be provided. I'd love to know if there's an easier way before I launch myself down this path in full. (Dealing with troubled data is no fun.) :-)


Further investigation has revealed that the fields exhibiting the "Mismatched" error come in two types:

The first type are those that have no definition defined in the key_value table for the entity.storage_schema.sql collection. That is, their names don't even appear in the listing produced by this query:

select name from key_value WHERE collection='entity.storage_schema.sql';

The collection of fields that lack a definition includes fields of type text, text (formatted), entity reference (taxonomies), entity reference revision (paragraph), and one viewfield. There are 11 of these fields. They all have tables associated with them, and all but a few are populated with data.

The second type are all of type "viewfield" from the Viewfield module. There are 25 of those. These all have storage definitions in the key_value table. That particular module has been troubled since I arrived - and is still running at back level (beta1). I was able to upgrade it to its latest version during a practice run to Drupal9 (to beta6) - but the Mismatch warnings still existed for those fields after the upgrade.

So it seems I have two directions to examine this issue. But why might I end up with fields that have no definitions at all (type one)? And what does this say about our data?

  • But "drush entup" back then was clearly not run while it was still available ... this is good news, this was never recommended on a production Drupal 8 install. Core and common contrib modules provided update hooks since the first Drupal 8 release, so those update hooks exist, you don't need to write them yourself. Running "drush entup" would probably make the update hooks unusuable. When an update hook fails and results in "Mismatched entity and/or field definitions" warnings it's a better idea to restore the site and try again after the issue is fixed. – 4k4 Mar 10 at 12:49
  • Good point 4k4! It seems all recent update hooks apply - for core and for numerous modules that have been updated since I arrived. But the "Mismatched" message persists. Is it likely that the issue arose with a module that has not yet had an update, and that likely failed on a "drush updb" prior to my arrival? (If that seems a likely hypothesis, it would certainly narrow down the number of modules I need to investigate. :-) – Spartanicus Mar 10 at 13:49
  • You can't update schema while there is data stored in the table. This is why the entity-updates command is not working. You'll need to delete all the data for the given field first. Or, write an update hook that pulls the data, restructures the table, then inserts the data back into the new table structure. – Jaypan Mar 10 at 18:43
  • Thanks, @Jaypan - I think my problem may largely be down to the Viewfield module. It doesn't appear that it does this process when restructuring tables between its betas - that is, it doesn't write the data off into a temporary table, restructure things and then copy the data back. I'm investigating. (At the moment when attempting to update from Viewfield beta1 to beta6, I get the "The SQL storage cannot change the schema for an existing field with data" message. To which I say, right... but isn't that module supposed to handle that? More soon... – Spartanicus Mar 11 at 14:56
  • You're likely right that the module doesn't do that if it's in beta. Beta versions should be expected to change at any time, and require a good bit of programming knowledge if used on a live site. – Jaypan Mar 11 at 17:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.