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 должен делать меньше работы (по сравнению с двумя предыдущими способами), и поэтому должен иметь лучшую производительность.