Cascade

What is the difference between the 2 options above? When is it preferable to choose each option? Serge Kvashnin The basic difference between them is: When using the orphanRemoval=true option Doctrine makes the assumption that the entities are privately owned and will NOT be reused by other entities. If you neglect this assumption your entities will get deleted by Doctrine even if you assigned the orphaned entity to another one. Say your User has one-to-many relation to Comment . If you are using cascade="remove" , you can remove the reference for Comment from one User , and then attach that

I want to check my understanding of cascade operations on Doctrine associations. For the purpose of this question, I have two models: Customer and Insuree . If I define a many to many relationship between a Customer and Insuree and set cascade{"all"} , I understand that this will: Adding a new insuree to a customer will persist this insuree and create an association in the join table. Removing an insuree from the collection will detach the insuree from the customer and detach the customer from the insuree. Deleting the customer will delete all insurees associated with the customer. This is the

I tried to gather few information about those following way to delete automatically child entity when a parent entity is deleted. Seems that the most common way is to use one those three annotation: cascade={"remove"} OR orphanRemoval=true OR ondelete="CASCADE" . I am a bit confuse about the third one: ondelete="CASCADE" , as explanation in doctrine official documentation about this one are very scarce) and I would love if someone could confirm me the following information I gathered and understand from my research on the net and experience... WHAT IT DOES cascade={"remove"} ==> the entity on

In MSSQL 2005 I just struck the infamous error message: Introducing FOREIGN KEY constraint XXX on table YYY may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints. Now, StackOverflow has several topics about this error message, so I've already got the solution (in my case I'll have to use triggers), but I'm curious as to why there is such a problem at all. As I understand it, there are basically two scenarios that they want to avoid - a cycle and multiple paths. A cycle would be where two tables have cascading

Duplicate of: When/Why to use Cascading in SQL Server? I've always been too scared to use DELETE CASCADE, but as I get more confident (lazy :D), I'm thinking how bad can it be, is it best practise to use it or should I avoid it and clean up my foreign keys etc the old fashioned way (with stored procedures)? ON DELETE CASCADE is fine, but only when the dependent rows are really a logical extension of the row being deleted. For example, it's OK for DELETE ORDERS to delete the associated ORDER_LINES because clearly you want to delete this order, which consists of a header and some lines. On the

I am wondering about this test question. I prepared the example myself and tested it but I still feel unsure of the answer. With the following: CREATE TABLE foo ( id INT PRIMARY KEY AUTO_INCREMENT, name INT ) CREATE TABLE foo2 ( id INT PRIMARY KEY AUTO_INCREMENT, foo_id INT REFERENCES foo(id) ON DELETE CASCADE ) As far as I can see the answer is: a. Two tables are created Although there are also: b. If a row in table foo2, with a foo_id of 2 is deleted, then the row with id=2 in the table foo is automatically deleted d.If a row with id = 2 in table foo is deleted, all rows with foo_id = 2 in