cascading deletes are not supported in Eloquent of Laravel 4

[hansmbakker]

Eloquent items can be deleted by calling item->delete();

However, items can have relationships. For one-to-many relationships, the children of a parent object belong to that parent object and might be useless without it.

Therefore it would be convenient if those children would be automatically deleted in a cascading (recursive) way.

The delete() method in Model.php could be changed so that it looks at the hasMany relations of the current object first, calls ->delete($deleteChildren=true) on each of them and after that deletes itself.

[JoostK]

Cascaded deletion should really be done by the database engine, by setting proper foreign keys.

I'm aware of the fact that many frameworks do support cascaded deletion but I don't think it's a task of the framework.

Also, how do you know which relations are defined? How do you find out which methods return a relation object? (You will now tell me to add a $cascade property to every model and that would not be nice)

[hansmbakker]

Well - I think the relations are defined in the model definitions. Maybe (the information from) those migrations and models could be merged somehow?

Symfony / Doctrine2 creates its database schemes based on the annotations in the Model files for example.

Besides, Laravel has a property 'relations' and could look there which relations are one-to-many.

Op 17 feb. 2013, om 23:14 heeft Joost Koehoorn notifications@github.com het volgende geschreven:

Cascaded deletion should really be done by the database engine, by setting proper foreign keys.

I'm aware of the fact that many frameworks do support cascaded deletion but I don't think it's a task of the framework.

Also, how do you know which relations are defined? How do you find out which methods return a relation object?

—
Reply to this email directly or view it on GitHub.

[alexrussell]

Actually it looks like the $relations property of a Model is lazily-loaded with the results of a call to a relationship-based method (see the Model->getAttribute method).

So just doing $user = User::find(1) won't fill the User's relations property until you call $user->posts or similar. Obviously, eager loading results probably also fills this, but either way you are having to manually get the relations before calling Model->delete(), which is a pain and very unreliable.

[robclancy]

My opinion: should be done with the database

However, Taylor has said he wants to do what you want anyway, for some reason.

[karptonite]

While cascading deletes in simple cases work well with the database engine, sometimes you have events that you want to trigger on delete of an item. In the site I work on, for example, when a post is deleted from a forum (in a MySQL table), we also remove it from a collection of subscription events (in a MongoDB collection). Of course, there is no way that could be done with a foreign key constraint. And even if you are just on one database, a delete cascade can be very problematic with polymorphic relations.

[robclancy]

In which case I would just overwrite the delete method on the model. Hell you could make an abstract model and define pre and post events for delete and save, I know I will be in the future.

[hansmbakker]

in another issue, @JoostK pointed me at the following possibility:

$table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');

This is not documented yet - please add it to the schema builder documentation.

[robclancy]

Oh that's what I meant with my first reply here. I didn't know there wasn't documentation for it as it is how I always do it.

[JonoB]

Another option right now would be to use the Event system to fire off a custom eloquent.deleted: modelName event.

[taylorotwell]

You can hook into the Model::deleting or Model::deleted events to take care of this.

[lkodx]

How can I be transaction-safe when hooking into the Model::deleting event for cascading deletion?

[sourcegr]

talking about constraints is not a fix at all, since there is the soft_delete option. If soft_delete is true, then bye-bye constrains...