À quoi servent les mises à jour d'entités drush?

Après la mise à jour des modules Drupal 8, j'ai été averti sur la page d'état de Drupal 8 que:

Définitions d'entité / champ: Les modifications suivantes ont été détectées dans le type d'entité et les définitions de champ.

Après un peu de fouille par Google, il semble que la solution soit de s'exécuter drush entity-updates. Cependant, je trouve cela un peu étrange car il semble que ce soit une autre commande dont il faut se souvenir ou incorporer dans son flux de travail après la mise à jour de la base de données, sans oublier que cela ne semblait pas immédiatement évident sur la façon de traiter l'avertissement d'origine.

De plus, il arrive souvent qu'en développement, vous ayez une alerte pour d'autres actions dans la page d'état, ce qui signifie que vous ne saurez pas immédiatement si vous devez agir.

Quelqu'un peut-il expliquer à quoi sert cet avertissement - ou plutôt, pourquoi cette fonctionnalité a-t-elle été introduite dans D8, et pourquoi n'est-elle pas prise en compte dans l'opération de mise à jour de la base de données mais doit être exécutée séparément?

8 entities drush updating

— njp
source

drush entity-updatesest un outil de développement. Si vous modifiez les définitions d'entité / de champ dans votre module personnalisé, vous pouvez l'appliquer rapidement.

En production, cela ne devrait pas se produire. Si vous mettez à jour un module entre les versions officielles, le code de mise à jour du module doit gérer cela.

Mais dans votre cas, vous mentionnez que votre site est en développement. Il y a donc beaucoup de choses qui pourraient avoir causé cela. Soit dans votre propre code, soit dans les versions dev ou alpha des modules contrib.

J'ai trouvé cet exemple dans les fonctions de mise à jour CR Write pour les mises à jour du schéma d'entité, l'automatisation a été supprimée (où il y a d'autres exemples):

/**
 * 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);
}

— 4k4
source

Sauf que c'est en fait un mauvais exemple. si vous êtes un module, vous devez faire des mises à jour très spécifiques. Installez une nouvelle définition de champ, mettez à jour une définition de type d'entité. Cela peut très mal se passer si vous mettez à jour plusieurs modules ou si le module fera un autre changement à l'avenir et que vous mettez à jour à partir d'une ancienne version. node.install a un certain nombre de meilleurs exemples de mise à jour.

— Berdir

Initialement, cela a été fait automatiquement dans le cadre de updb / update.php. Mais cela ne fonctionne pas toujours, il ne prend pas en charge les mises à jour potentiellement destructrices quand il y a des données et cela a causé beaucoup de problèmes. Si vous avez des données dans un champ, vous ne pouvez pas simplement appeler cette méthode, vous devez la mettre à jour vous-même, ce qui peut être assez compliqué. Voir drupal.org/node/2554097 pour plus d'informations

— Berdir

Remarque concernant le commentaire de Berdir: j'ai supprimé le mauvais exemple et l'ai remplacé par un de l'enregistrement des modifications.

— Andy

Juste pour être clair, la raison pour laquelle c'est une mauvaise idée d'exécuter des mises à jour d'entités en production est qu'elle peut être destructrice. Par exemple, si vous modifiez un uuid de stockage de champ, importez la définition de stockage modifiée, exécutez cron, puis exécutez les mises à jour d'entité, il détruira tout contenu existant dans ce champ.

— Dane Powell

Les modules doivent être responsables de l'application de leurs propres mises à jour de schéma via des crochets de mise à jour ciblés. Personne ne devrait exécuter la entity-updatescommande régulièrement, sauf au début du processus de développement de sites avec des modules personnalisés où vous ne vous souciez pas de la destruction des données.

— Dane Powell

La commande "drush entity-updates" a été supprimée de la version 8.7.0

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

Depuis la version 8.7.0, Drupal core ne prend plus en charge les mises à jour automatiques des entités. Chaque fois qu'un type d'entité ou une définition de stockage de champ doit être créé, modifié ou supprimé, cela doit être fait avec une fonction de mise à jour explicite fournie par l'API de mise à jour et en utilisant l'API fournie par le gestionnaire de mise à jour de définition d'entité.

— Andriyun
source