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?
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.
Donate
