Comments on: Doctrine Gotchas – delete cascade, SoftDelete and foreignType

By: timbee

timbee — Mon, 21 Feb 2011 18:15:33 +0000

By the way, you can also turn on DQL Callbacks in the database.yml file (repost from stackoverflow’s jwconsulting):

all:
doctrine:
class: sfDoctrineDatabase
param:
dsn: mysql:host=host;dbname=db
username: user
password: password
attributes:
use_dql_callbacks: true

By: logicrow

logicrow — Thu, 10 Feb 2011 11:00:50 +0000

eat your monkeydust yourself.

By: muqker

muqker — Fri, 27 Aug 2010 13:06:47 +0000

I think your example of cascade delete is misleading. In the first example, the “SQL foreign key” cascade deletion (onDelete: CASCADE) will trigger the SQL deletion of PhoneNumber when the parent User is deleted.
However, in the second example, the “doctrine model callback” cascade deletion (cascade: [delete]) will trigger the Doctrine deletion (preDelete(), postDelete(), additional cascading, etc., followed by SQL deletion or soft deletion) of User when any child PhoneNumber is deleted. So the direction of the cascade is now reversed!

By: benjamin

benjamin — Tue, 04 May 2010 14:12:52 +0000

second hit in google for “actAs SoftDelete symfony”
and worth reading it (-; – thx

By: Chris

Chris — Thu, 25 Feb 2010 15:51:35 +0000

@dirk Well, for me the “deleted_at” column in the DQL Queries works perfect. Are you shure that you have enabled dql callbacks correctly?

By: Darren

Darren — Sat, 06 Feb 2010 00:53:21 +0000

Thanks for this information, it helped our company. Was weird because I kept getting integrity constraint violations and wondering why things weren’t cascading.

By: dirk

dirk — Fri, 29 Jan 2010 11:27:22 +0000

I would be interested in the Symfony and Doctrine versions where SoftDelete really works (I assume it does, otherwise you would not do this report.)
In symfony 1.3.1 with Doctrine 1.2.1 with SoftDelete enabled and dql callbacks set to true doctrine marks deleted table entries correctly (deleted_ad column is filled with actual datetime)
but that does not help much. The problem is: Doctrine queries (DQL) ignore the “deleted_at” field which means that you have to do the filtering manually in an extra where clause.
So I do not see any reason why anyone should use this behaviour because you have to do the filtering on your own.

By: stephenrs

stephenrs — Thu, 28 Jan 2010 15:11:04 +0000

Ah, you’re right, sorry I missed that, and thanks for addressing it. Personally, I prefer to define Doctrine/yaml relations at the other end – for me it seems a little more intuitive and easier maintain, by reinforcing the idea that the child table is dependent on the parent, and not the other way around. Your mileage may vary.

By: Russ

Russ — Thu, 28 Jan 2010 10:49:10 +0000

Hmm, I did mention a little while back (if you read upwards) that I would fix that – it’s done now.

Suspicion is good – it makes better developers out of all of us.

By: stephenrs

stephenrs — Thu, 28 Jan 2010 02:47:07 +0000

Hmmm, I was with you until I got to the “user has many payments” part…putting a payment_id in the user table will never give you the expected result, whether you use Doctrine or not…unless you plan to duplicate the same user record over and over again with different payment_id’s…

The Payment table needs a foreign key to the User table: user_id. Relational DB design 101, no?

This makes the whole post a little suspicious in terms of its usefulness, but thanks anyway.