We've attempted to upgrade core from 8.6.15 to 8.7.1 (security update) but the file_entity module indicates the following error:
"Mismatched entity and/or field definitions"
"The File type field needs to be updated"

Our problem seems similar to issue 3033883 although that issue involves uninstalling the file_entity module and we are just trying to upgrade core.

Also, starting with 8.7 there is no support for automatic entity updates so we're at a loss as how to resolve this. Any help or suggestions would be appreciated.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dgilbert created an issue. See original summary.

joseph.olstad’s picture

joseph.olstad’s picture

dgilbert’s picture

Thanks for the info. Just to confirm, our options are to switch over to the core media entity or write a custom module and use hook_update_N to update/fix the schema? Or a third option would be to (temporarily) install the devel_entity_updates module on our prod environment.

Olarin’s picture

So on a technical level, if I'm understanding correctly, the issue is that after the D8.7 update, the type column in the file_managed table does not have NOT_NULL turned on, but the storage schema "file.field_schema_data.type" in the key_value table says it should. The workaround in https://www.drupal.org/project/file_entity/issues/2914935#comment-13110657 changes the configuration in the key_value table to reflect the current reality of the database table. I'm curious, though - is the more "correct" workaround to change the configuration described in key_value, or to change the database column settings? I'm hesitant to use the workaround without knowing anything about why the database settings apparently changed and what the "correct" / expected situation is.

jldust’s picture

Has their been any update on this issue? I saw a possible patch being worked on, but want to make the right call as to what is the best course of action.

joseph.olstad’s picture

joseph.olstad’s picture

until someone proposes a patch for file_entity with a better idea , the workaround hook_update is probably the way to go if you have your own custom module add that

mycustom_homer_j_simpsonmodule_update_8001() {
  $key_value = \Drupal::keyValue('entity.storage_schema.sql');
  $key_name = 'file.field_schema_data.type';
  $storage_schema = $key_value->get($key_name);
  $storage_schema['file_managed']['fields']['type']['not null'] = FALSE;
  $key_value->set($key_name, $storage_schema);
}

as mentioned in #2914935-73: Mismatched entity and/or field definitions for File 'type' field after updating to Drupal 8.4

Berdir’s picture

Version: 8.x-2.0-beta6 » 8.x-2.x-dev
Status: Active » Needs review
FileSize
790 bytes

That fix is backwards, it has to be not null, the problem is that we incorrectly expect the opposite, because the *current* schema is based on the last installed entity type definition apparently :)

This is the proper fix for that, unfortunately that means that sites who did such a custom update like that one above will need to redo and correct their last-installed definition back to the correct value.

Status: Needs review » Needs work

The last submitted patch, 9: file_entity-8.7-update-3056070-9.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

amateescu’s picture

The patch looks good, just a minor nit:

+++ b/file_entity.install
@@ -168,3 +168,16 @@ function file_entity_update_8004() {
+ * Fix flag last installed entity definitions.

"flag" -> "file" :)

Or better yet, I think it would make more sense like this:

Fix the last installed definition for the 'file' entity type.

Berdir’s picture

Status: Needs work » Fixed

Those test fails are unrelated, created #3067048: Convert FileEntityCacheTagsTest to phpunit for that.

  • Berdir committed ae43ab1 on 8.x-2.x
    Issue #3056070 by Berdir: Mismatched entity and/or field definitions...
Berdir’s picture

@amateescu: Oops, crosspost. Fixed.

  • Berdir committed 94aedf9 on 8.x-2.x
    Issue #3056070 by Berdir: Mismatched entity and/or field definitions...
joseph.olstad’s picture

Thanks @Berdir

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

edysmp’s picture

I did an update from 8.7.12 to 8.8.5 and i am still seeing the message on status report page.

8004 and 8005 updates ran without problems.

What could be causing this issue?

EDIT:
Current message: https://paste.pics/b5a46e32dcd21841a0bc46dc49744078

edysmp’s picture

Could devel_entity_updates module taken in account in this case? It resolve the issue.

websiteworkspace’s picture

... and this odd Drupal nightmare continues ...

When people, including myself, see bugs like this go for years without being properly addressed and properly fixed, we wonder whether we should laugh, cry, or be angry, that these sorts of circumstances occur with a software system such as Drupal.

This sort of circumstance, with this sort of problem, is all the more ironic for a software platform that is touted by its leaders as being by professionals for professionals.

The bug/problem still is NOT actually fixed!

joseph.olstad’s picture

Please re-read the file_entity project page

loopy1492’s picture

I came to this thread from a different specific issue, but the result is the same. Developers without the option of going in and messing with the database need to risk https://www.drupal.org/project/entity_update . I can 't think of any other way to do this.

kaipipek’s picture

How is this bug fixed? We are in the latest Drupal 9.3.2 and we still receive this error message. We have spent numerous hours reading through bug reports and comments related to this issue prior and after Drupal 8.4 version, but none of the workarounds work for us. For instance changing the "not null" setting of the file_managed table type field does not change anything and key_value table does not have a row with name field value "file.field_schema_data.type" that we could tweak.