Qual è lo scopo degli aggiornamenti delle entità drush?


14

Dopo aver aggiornato i moduli Drupal 8, nella pagina di stato Drupal 8 sono stato avvisato che:

Definizioni di entità / campo: sono state rilevate le seguenti modifiche nel tipo di entità e nelle definizioni di campo.

Dopo aver rovistato un po 'su Google, sembra che la soluzione sia eseguire drush entity-updates. Tuttavia lo trovo un po 'strano in quanto sembra essere un altro comando che è necessario ricordare o incorporare nel proprio flusso di lavoro dopo aver aggiornato il database, per non parlare del fatto che non sembrava immediatamente ovvio su come affrontare l'avviso originale.

Inoltre, spesso nello sviluppo avrai un avviso per altre azioni nella pagina Stato, il che significa che non saprai immediatamente se è necessario agire in questo modo.

Qualcuno può spiegare a cosa serve questo avviso - o meglio, perché questa funzione è stata introdotta in D8 e perché non viene presa in considerazione nell'operazione di aggiornamento del database ma deve essere eseguita separatamente?

Risposte:


19

drush entity-updatesè uno strumento di sviluppo. Se si modificano le definizioni di entità / campo nel modulo personalizzato, è possibile applicarlo rapidamente.

In produzione questo non dovrebbe accadere. Se aggiorni un modulo tra versioni ufficiali, il codice di aggiornamento nel modulo dovrebbe gestirlo.

Ma nel tuo caso stai menzionando che il tuo sito è in fase di sviluppo. Quindi ci sono molte cose che potrebbero aver causato questo. Nel tuo codice o nelle versioni dev o alpha dei moduli contrib.

Ho trovato questo esempio dalle funzioni di aggiornamento di CR Write per gli aggiornamenti dello schema di entità, l'automazione rimossa (dove ci sono altri esempi):

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

2
Solo che in realtà è un cattivo esempio. se sei un modulo, dovresti fare aggiornamenti molto specifici. Installa una nuova definizione di campo, aggiorna una definizione di tipo di entità. Questo può andare molto male se si aggiornano più moduli o se il modulo farà un'altra modifica in futuro e si aggiorna da una versione precedente. node.install ha una serie di esempi di aggiornamento migliori.
Berdir,

1
Inizialmente, questo è stato fatto automaticamente come parte di updb / update.php. Ma non sempre funziona, non supporta eventuali aggiornamenti distruttivi quando ci sono dati e questo ha causato molti problemi. Se disponi di dati in un campo, non puoi semplicemente chiamare questo metodo, devi aggiornarlo da solo, il che può essere abbastanza complicato. Vedi drupal.org/node/2554097 per ulteriori informazioni
Berdir,

2
Nota relativa al commento di Berdir: ho rimosso il cattivo esempio e l'ho sostituito con uno dal record delle modifiche.
Andy,

2
Giusto per essere chiari, il motivo per cui è una cattiva idea eseguire gli aggiornamenti delle entità in produzione è che può essere distruttivo. Ad esempio, se si modifica un uuid di archiviazione di campo, si importa la definizione di archiviazione modificata, si esegue cron e quindi si eseguono gli aggiornamenti delle entità, distruggerà qualsiasi contenuto esistente in quel campo.
Dane Powell,

2
I moduli dovrebbero essere responsabili dell'applicazione dei propri aggiornamenti dello schema tramite hook di aggiornamento mirati. Nessuno dovrebbe eseguire il entity-updatescomando su base regolare, tranne che all'inizio del processo di sviluppo di siti con moduli personalizzati in cui non ti interessa la distruzione dei dati.
Dane Powell,

1

Il comando "drush entity-updates" è stato rimosso dalla v 8.7.0

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

A partire da 8.7.0, il core Drupal non fornisce più supporto per gli aggiornamenti automatici delle entità. Ogni volta che un tipo di entità o una definizione di archiviazione dei campi deve essere creata, modificata o eliminata, deve essere eseguita con una funzione di aggiornamento esplicita fornita dall'API di aggiornamento e utilizzando l'API fornita dal gestore degli aggiornamenti delle definizioni delle entità.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.