回答編集履歴
1
補足です。
test
CHANGED
|
@@ -37,3 +37,43 @@
|
|
|
37
37
|
|
|
38
38
|
|
|
39
39
|
にしても、親の論理削除でエラーが発生することはないようです。
|
|
40
|
+
|
|
41
|
+
|
|
42
|
+
|
|
43
|
+
|
|
44
|
+
|
|
45
|
+
----
|
|
46
|
+
|
|
47
|
+
|
|
48
|
+
|
|
49
|
+
もしかしたら、語弊があるかもしれないので、補足を。。
|
|
50
|
+
|
|
51
|
+
|
|
52
|
+
|
|
53
|
+
> 単なる定義であって、削除処理は書く必要
|
|
54
|
+
|
|
55
|
+
|
|
56
|
+
|
|
57
|
+
は、今回のケースが
|
|
58
|
+
|
|
59
|
+
「親の論理削除」で、「子の物理削除」をしたい話なので、そうなります。
|
|
60
|
+
|
|
61
|
+
|
|
62
|
+
|
|
63
|
+
先にも説明しましたが、migrationファイルの設定で自動的に削除実行するのは「DB」なので、
|
|
64
|
+
|
|
65
|
+
【DBにとっての削除】＝データの有無が変化する「親の物理削除」が、子テーブルへ処理のきっかけとして必要になるのです。
|
|
66
|
+
|
|
67
|
+
論理削除は、データを残したまま無効にする。。という【プログラム上の仕様】なので、【DBにとっての削除】には該当しません。
|
|
68
|
+
|
|
69
|
+
|
|
70
|
+
|
|
71
|
+
つまり、今のままの設定でも、親を「完全削除（強制物理削除）```$post->forceDelete();``` 」すれば、子の削除処理を書かずともDBが自動的に子も削除してくれます。
|
|
72
|
+
|
|
73
|
+
|
|
74
|
+
|
|
75
|
+
なお、DBによっては、親の論理削除を条件に子の削除を実行するtriggerを付けるようなことも可能ではありますが、migrationファイルで簡単に定義は出来ないかも？（やったことないのでもしかしたら簡単かもしれませんが・・）
|
|
76
|
+
|
|
77
|
+
|
|
78
|
+
|
|
79
|
+
私の個人的な意見としては、migrationで複雑な設定をするよりも、コードで書いた方が簡単で早いかなぁと思ったりもします。。。
|