Puncte:2

Nu ar trebui hook_update pentru a adăuga un câmp nou la o entitate să folosească definiția câmpului din clasa de entitate?

drapel hk

Scriam un cârlig de actualizare pentru a adăuga un câmp nou la o entitate personalizată și urmam modelul afișat aici

https://www.drupal.org/node/2554097

/**
 * Adăugați câmpul „revision_translation_affected” la entitățile „nod”.
 */
funcția node_update_8001() {
  // Instalează definiția în care a avut acest câmp
  // \Drupal\node\Entity\Node::baseFieldDefinitions()
  // la momentul în care a fost scrisă această funcție de actualizare. Dacă/când codul este
  // implementat care modifică acea definiție, modulul corespunzător trebuie
  // implementează o funcție de actualizare care invocă
  // \Drupal::entityDefinitionUpdateManager()->updateFieldStorageDefinition()
  // cu noua definiție.
  $storage_definition = BaseFieldDefinition::create('boolean')
      ->setLabel(t('Traducerea versiunii afectată'))
      ->setDescription(t('Indica daca ultima editare a unei traduceri apartine revizuirii curente.'))
      ->setReadOnly(TRUE)
      ->setRevisionable(TRUE)
      ->setTranslatable(TRUE);

  \Drupal::entityDefinitionUpdateManager()
    ->installFieldStorageDefinition('revision_translation_affected', 'node', 'node', $storage_definition);
}

Am simțit că dubleam BaseFieldDefinition atât în ​​clasa de entitate personalizată, cât și în fișierul de instalare. Nu ar trebui să pot folosi funcția statică

funcția publică statică baseFieldDefinitions(EntityTypeInterface $entity_type) 

din clasa de entitate pentru a încărca definiția câmpului și a o instala?

No Sssweat avatar
drapel ua
În scopuri istorice, cred că este cea mai bună practică să nu o faci.
4uk4 avatar
drapel cn
Da, istoric în sensul revizuirilor de cod. Actualizarea codului poate conține mai multe modificări simultan, în timp ce hook-urile de actualizare trebuie să proceseze modificările pas cu pas.
drapel hk
Mulțumiri. Am înţeles.
Puncte:3
drapel us

Folosind obiectul returnat de Drupal::entityDefinitionUpdateManager() este modalitatea corectă de a actualiza câmpurile unei entități, din același motiv și hook_update_N() implementarea nu va chema niciunul hook_schema() implementare pentru a actualiza un câmp de bază de date.

Imaginați-vă că mai târziu modificați entitatea și redenumiți câmpul respectiv revizuire_traducere_afectată la traducere_afectată. Dacă hook-ul de actualizare pe care l-ați scris acum folosește matricea din care a revenit baseFieldDefinitions() și o stochează în $câmpuri, nu va găsi nicio valoare pentru câmpuri['revision_translation_affected'], de cand baseFieldDefinitions() a fost deja actualizat pentru a returna câmpul redenumit.

Implementările cârligului de actualizare trebuie să funcționeze independent de a fi ultimul cârlig de actualizare adăugat sau nu.
În plus, codul folosit dintr-un cârlig de actualizare nu poate fi schimbat, odată ce acel cârlig a fost adăugat. Dacă un cârlig de actualizare creează un câmp de entitate care este eliminat ulterior (de exemplu), trebuie adăugat un nou cârlig de actualizare pentru a elimina acel câmp de entitate; cârligul de actualizare existent nu poate fi modificat pentru a nu mai adăuga acel câmp de entitate, sau site-urile care rulează deja acel cârlig de actualizare nu vor vedea câmpul de entitate eliminat. (Drupal rulează un cârlig de actualizare o singură dată.)

drapel hk
Mulțumesc pentru explicația detaliată @apaderno. Asta are un sens total.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.