Was ist der Zweck von Drush-Entity-Updates?

Nach dem Update der Drupal 8-Module wurde ich auf der Drupal 8-Statusseite gewarnt, dass:

Entitäts- / Felddefinitionen: Die folgenden Änderungen wurden bei den Entitätstyp- und Felddefinitionen festgestellt.

Nach einigem Stöbern bei Google scheint es die Lösung dafür zu sein drush entity-updates. Ich finde dies jedoch etwas seltsam, da es sich um einen anderen Befehl zu handeln scheint, den man sich merken oder in den Workflow integrieren muss, nachdem die Datenbank aktualisiert wurde. Außerdem schien es nicht sofort offensichtlich, wie die ursprüngliche Warnung behandelt werden soll.

Außerdem wird in der Entwicklungsphase häufig eine Warnung für andere Aktionen auf der Statusseite angezeigt, sodass Sie nicht sofort wissen, ob Sie dies tun müssen.

Kann jemand erklären, wofür diese Warnung gedacht ist - oder warum diese Funktion in D8 eingeführt wurde und warum sie bei der Datenbankaktualisierung nicht berücksichtigt wird, sondern separat ausgeführt werden muss?

8 entities drush updating

— njp
quelle

drush entity-updatesist ein Entwicklertool. Wenn Sie Entitäts- / Felddefinitionen in Ihrem benutzerdefinierten Modul ändern, können Sie dies schnell anwenden.

In der Produktion sollte dies nicht passieren. Wenn Sie ein Modul zwischen offiziellen Releases aktualisieren, sollte der Aktualisierungscode im Modul dies verarbeiten.

In Ihrem Fall erwähnen Sie jedoch, dass sich Ihre Website in der Entwicklung befindet. Es gibt also eine Menge Dinge, die dies verursacht haben könnten. Entweder in Ihrem eigenen Code oder in Dev- oder Alpha-Versionen von Contrib-Modulen.

Ich habe dieses Beispiel aus den CR Write-Aktualisierungsfunktionen für Entitätsschema-Aktualisierungen gefunden, Automatisierung entfernt (wo es weitere Beispiele gibt):

/**
 * 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
quelle

Aber das ist eigentlich ein schlechtes Beispiel. Wenn Sie ein Modul sind, sollten Sie sehr spezifische Updates durchführen. Installieren Sie eine neue Felddefinition, und aktualisieren Sie eine Entitätstypdefinition. Dies kann sehr schlimm sein, wenn Sie mehrere Module aktualisieren oder wenn das Modul in Zukunft eine weitere Änderung vornimmt und Sie von einer alten Version aktualisieren. node.install enthält eine Reihe besserer Aktualisierungsbeispiele.

— Berdir

Anfänglich wurde dies automatisch im Rahmen von updb / update.php durchgeführt. Aber es funktioniert nicht immer, es unterstützt keine möglicherweise zerstörerischen Aktualisierungen, wenn Daten vorhanden sind und dies viele Probleme verursacht hat. Wenn Sie Daten in einem Feld haben, können Sie diese Methode nicht einfach aufrufen, sondern müssen sie selbst aktualisieren, was recht kompliziert sein kann. Siehe drupal.org/node/2554097 für weitere Informationen

— Berdir

Anmerkung zu Berdir's Kommentar: Ich habe das schlechte Beispiel entfernt und durch eines aus dem Änderungsprotokoll ersetzt.

— Andy

Der Grund, warum es eine schlechte Idee ist, Entity-Updates in der Produktion durchzuführen, ist, dass es destruktiv sein kann. Wenn Sie beispielsweise eine Feldspeicher-UUID ändern, die geänderte Speicherdefinition importieren, cron ausführen und dann Entity-Updates ausführen, werden alle vorhandenen Inhalte in diesem Feld zerstört.

— Dane Powell

Module sollten dafür verantwortlich sein, ihre eigenen Schema-Updates über gezielte Update-Hooks anzuwenden. Niemand sollte den entity-updatesBefehl regelmäßig ausführen, außer zu Beginn des Entwicklungsprozesses von Sites mit benutzerdefinierten Modulen, bei denen Sie sich nicht um die Datenvernichtung kümmern.

— Dane Powell

Der Befehl "drush entity-updates" wurde aus Version 8.7.0 entfernt

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

Ab 8.7.0 bietet Drupal Core keine Unterstützung mehr für automatische Entitätsupdates. Immer wenn ein Entitätstyp oder eine Feldspeicherdefinition erstellt, geändert oder gelöscht werden muss, muss dies mit einer expliziten Aktualisierungsfunktion erfolgen, die von der Aktualisierungs-API bereitgestellt wird, und die vom Aktualisierungs-Manager für Entitätsdefinitionen bereitgestellte API muss verwendet werden.

— Andriyun
quelle