Cascade = { "remove" } VS orphanRemoval = true VS ondelete = "CASCADE

Я попытался собрать немного информации о следующих способах автоматического удаления дочернего объекта при удалении родительского объекта. Кажется, что наиболее распространенным способом является использование одной из трех аннотаций: cascade = { "remove" } ИЛИ orphanRemoval = true ИЛИ ondelete = "CASCADE" strong > .

Я немного озадачен третьим: ondelete = "CASCADE" , так как объяснение в доктрине официальной документации об этом очень мало), и мне было бы очень приятно, если бы кто-то смог подтвердить меня следующая информация Я собрал и понял из своих исследований в сети и опыте...

ЧТО ЭТО

каскадного = { "удалить" }
== > объект на обратной стороне удаляется, когда объект-владелец принадлежит. Даже если вы находитесь в многогосударстве с другим лицом, владеющим стороной.
- следует использовать для сбора (так в отношениях OneToMany или ManyToMany)
- реализация в ORM

orphanRemoval = истина
== > сущность на обратной стороне удаляется, когда объект-владеющая сторона И еще не подключен к какой-либо другой стороне, принадлежащей стороне. (ссылка doctrine official_doc - реализация в ORM
- может использоваться с OneToOne, OnetoMany или ManyToMany

OnDelete = "КАСКАД"
== > это добавит On Delete Cascade в столбец внешнего ключа в базе данных
- Эта стратегия немного сложна, чтобы получить право, но может быть очень мощной и быстрой. (ссылка doctrine official_doc... но не читайте больше объяснений)
- ORM должен делать меньше работы (по сравнению с двумя предыдущими способами) и поэтому должен иметь лучшую производительность.

другая информация
- все эти три способа выполнения реализованы на двунаправленных объектах связи (справа???)
- использование cascade = { "remove" } полностью обходит любой внешний ключ onDelete = CASCADE. (ссылка doctrine_official_doc)

ПРИМЕР КАК ИСПОЛЬЗОВАТЬ ЭТО В КОДЕЛЕ

  • orphanRemoval и cascade = { "remove" } определены в классе инвертированных сущностей.
  • ondelete = "CASCADE" определяется в объекте владельца
  • вы также можете просто написать @ORM\JoinColumn (onDelete = "CASCADE" ) и позволить доктрине обрабатывать имена столбцов

каскадного = { "удалить" }

/**
* @OneToMany(targetEntity="Phonenumber", mappedBy="contact", cascade={"remove"})
*/
protected $Phonenumbers

orphanRemoval = истина

/**
* @OneToMany(targetEntity="Phonenumber", mappedBy="contact", orphanRemoval=true)
*/
protected $Phonenumbers

OnDelete = "КАСКАД"

/** 
* @ManyToOne(targetEntity="Contact", inversedBy="phonenumbers")
* @JoinColumn(name="contact_id", referencedColumnName="contact_id", onDelete="CASCADE")
*/ 
protected $contact; 

Ответ 1

onDelete="CASCADE" управляется самой базой данных. cascade={"remove"} управляется доктриной.

onDelete="CASCADE" быстрее, потому что операции выполняются на уровне базы данных, а не на доктрине. Удаление выполняется сервером базы данных, а не Doctrine. С помощью cascade={"remove"} доктрина должна управлять самой сущностью и выполнять дополнительные проверки, чтобы убедиться, что у нее нет каких-либо других принадлежащих ей объектов. Когда другого не существует, он удалит объект. Но это создает накладные расходы.


каскадного = { "удалить" }

  • объект на обратной стороне удаляется, если объект-владелец принадлежит. Даже если вы находитесь во многих странах с другим лицом, владеющим стороной. Нет, если объект принадлежит другому. Он не будет удален.
  • следует использовать для сбора (так что в отношениях OneToMany или ManyToMany)
  • реализация в ORM

orphanRemoval = "истинный"

  • сущность на обратной стороне удаляется, когда объект-владеющая сторона И И еще не подключен к какой-либо другой стороне владельца. Не совсем, это ведет к тому, что доктрина ведет себя так, как будто она не принадлежит другому объекту и, следовательно, удаляет ее.
  • реализация в ORM
  • может использоваться с OneToOne, OnetoMany или ManyToMany

OnDelete = "КАСКАД"

  • это добавит On Delete Cascade в столбец внешнего ключа В БАЗЕ ДАННЫХ
  • Эта стратегия немного сложна, чтобы получить право, но может быть очень мощной и быстрой. (это цитата из официального учебника доктрины... но не видели больше объяснений)
  • ORM должен делать меньше работы (по сравнению с двумя предыдущими способами), и поэтому должен иметь лучшую производительность.