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.)
- 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?