17

After updating Drupal 8 modules, I have been warned on the Drupal 8 status page that:

Entity/field definitions: The following changes were detected in the entity type and field definitions.

After a bit of Google rummaging, it seems the solution to this is to run drush entity-updates. However I find this a bit strange as it seems to be another command that one needs to remember or incorporate into one's workflow after updating the database, not to mention it didn't seem immediately obvious about how to address the original warning.

What's more, it's often the case that in development you'll have an alert for other actions in the Status page which will mean you won't immediately know if you need to action this.

Can anybody explain what is this warning is for - or rather, why has this feature been introduced into D8, and why isn't it factored into the database update operation but must be run seperately?

3 Answers 3

19

drush entity-updates is a developer tool. If you change entity/field definitions in your custom module you can quickly apply this.

In production this should not happen. If you update a module between official releases, then the update code in the module should handle this.

But in your case you are mentioning that your site is in developing. So there are a lot of things, which could have caused this. Either in your own code or in dev or alpha versions of contrib modules.

I found this example from the CR Write update functions for entity schema updates, automation removed (where there are further examples):

/**
 * Add 'revision_translation_affected' field to 'node' entities.
 */
function node_update_8001() {
  // Install the definition that this field had in
  // \Drupal\node\Entity\Node::baseFieldDefinitions()
  // at the time that this update function was written. If/when code is
  // deployed that changes that definition, the corresponding module must
  // implement an update function that invokes
  // \Drupal::entityDefinitionUpdateManager()->updateFieldStorageDefinition()
  // with the new definition.
  $storage_definition = BaseFieldDefinition::create('boolean')
      ->setLabel(t('Revision translation affected'))
      ->setDescription(t('Indicates if the last edit of a translation belongs to current revision.'))
      ->setReadOnly(TRUE)
      ->setRevisionable(TRUE)
      ->setTranslatable(TRUE);

  \Drupal::entityDefinitionUpdateManager()
    ->installFieldStorageDefinition('revision_translation_affected', 'node', 'node', $storage_definition);
}
7
  • 2
    Except that is actually a bad example. if you are a module, you should do very specific updates. Install a new field definition, update an entity type definition. This can go very badly if you update multiple modules or if the module will make another change in the future and you update from an old version. node.install has a number of better update examples.
    – Berdir
    Commented Nov 23, 2016 at 20:03
  • 1
    Initially, this was done automatically as part of updb/update.php. But it doesn't always work, it doesn't support possibly destructive updates when there is data and that caused a lot of problems. If you have data in a field, you can't just call this method, you need to update it yourself, which can be quite complicated. See drupal.org/node/2554097 for more information
    – Berdir
    Commented Nov 23, 2016 at 20:06
  • 2
    Note regarding Berdir's comment: I've removed the bad example and replaced it with one from the change record.
    – Andy
    Commented Apr 7, 2017 at 13:04
  • 2
    Just to be clear, the reason that it's a Bad Idea to run entity-updates in production is that it can be destructive. For instance, if you change a field storage uuid, import the changed storage definition, run cron, and then run entity-updates, it will destroy any existing content in that field. Commented May 9, 2017 at 0:44
  • 2
    Modules should be responsible for applying their own schema updates via targeted update hooks. No one should be running the entity-updates command on a regular basis, except for early in the development process of sites with custom modules where you don't care about data destruction. Commented Mar 22, 2018 at 15:11
1

Command "drush entity-updates" has been removed from v 8.7.0

See https://www.drupal.org/node/3034742

Starting with 8.7.0, Drupal core no longer provides support for automatic entity updates. Whenever an entity type or field storage definition needs to be created, changed or deleted, it has to be done with an explicit update function as provided by the Update API, and using the API provided by the entity definition update manager.

0

There is a contrib module that takes the place of the original command.

You can install it with

composer require drupal/devel_entity_updates

Enable it with

drush en devel_entity_updates

and run it with

drush entup

https://www.drupal.org/project/devel_entity_updates

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.