回答編集履歴
1
補足です。
answer
CHANGED
|
@@ -17,4 +17,24 @@
|
|
|
17
17
|
$table->foreign('post_id')->references('id')->on('posts')->onDelete('restrict');
|
|
18
18
|
```
|
|
19
19
|
|
|
20
|
-
にしても、親の論理削除でエラーが発生することはないようです。
|
|
20
|
+
にしても、親の論理削除でエラーが発生することはないようです。
|
|
21
|
+
|
|
22
|
+
|
|
23
|
+
----
|
|
24
|
+
|
|
25
|
+
もしかしたら、語弊があるかもしれないので、補足を。。
|
|
26
|
+
|
|
27
|
+
> 単なる定義であって、削除処理は書く必要
|
|
28
|
+
|
|
29
|
+
は、今回のケースが
|
|
30
|
+
「親の論理削除」で、「子の物理削除」をしたい話なので、そうなります。
|
|
31
|
+
|
|
32
|
+
先にも説明しましたが、migrationファイルの設定で自動的に削除実行するのは「DB」なので、
|
|
33
|
+
【DBにとっての削除】＝データの有無が変化する「親の物理削除」が、子テーブルへ処理のきっかけとして必要になるのです。
|
|
34
|
+
論理削除は、データを残したまま無効にする。。という【プログラム上の仕様】なので、【DBにとっての削除】には該当しません。
|
|
35
|
+
|
|
36
|
+
つまり、今のままの設定でも、親を「完全削除（強制物理削除）```$post->forceDelete();``` 」すれば、子の削除処理を書かずともDBが自動的に子も削除してくれます。
|
|
37
|
+
|
|
38
|
+
なお、DBによっては、親の論理削除を条件に子の削除を実行するtriggerを付けるようなことも可能ではありますが、migrationファイルで簡単に定義は出来ないかも？（やったことないのでもしかしたら簡単かもしれませんが・・）
|
|
39
|
+
|
|
40
|
+
私の個人的な意見としては、migrationで複雑な設定をするよりも、コードで書いた方が簡単で早いかなぁと思ったりもします。。。
|