Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
orm cascade delete order
  • I just want to confirm if there is a better approach in way to control cascade delete order. I see that by default way orm works is delete parent and then  delete child. Checked relationships classes like hasmany.php and found:

    public function delete($model_from, $models_to, $parent_deleted, $cascade)
        {
            if (! $parent_deleted)
            {

    Workaround I found was to change above if statement and take out the not to force child to be deleted before parent.

    Is there a way to control this without changing orm code, maybe variable in model or something else?

    Thanks in advance
  • The delete() method on the relation objects is called twice, once before the parent is deleted, and once after. Some relations use this, but not all, like hasmany.

    The question is: why would you want to change it? What is the issue you are trying to solve?
  • I did see the same logic was executed before and after as you mentioned, but I did not see how to make it execute before... without changing code in relation class... it seemed to me the code before was never going to be executed unless I changed the code in the relation class as I mentioned before.

    Answers:

    What is the issue you are trying to solve?

    Cant access parent table information from within on delete trigger of a child table. Due parent row is already deleted beforehand
    I cant access parent information within trigger of child table. 

    Why would you want to change it?

    To be able to access parent data information within triggers.

    Changing hasmany.php code from:

    public function delete($model_from, $models_to, $parent_deleted, $cascade)
        {
            if (! $parent_deleted)
            {

    to:
    public function delete($model_from, $models_to, $parent_deleted, $cascade)
        {
            if ($parent_deleted)
            {

    did solve the problem as all childs were deleted before parent. Hence I was able to access parent table information within triggers.

  • HarroHarro
    Accepted Answer
    The same logic isn't executed before and after, the delete() method is called twice, once before, and once after the parent has been deleted.

    Ideally, you delete children before the parent, I don't know why Jelmer has chosen to do it the other way around.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion