外部キー制約のCASCADE指定における子テーブルのレコード自動削除について

実現したいこと

親テーブルのレコードを削除した際に、紐づく子テーブルのレコードも自動削除したい。

該当のソースコード

Post Model（親）

php
1class CreatePostsTable extends Migration
2{
3  public function up()
4  {
5    Schema::create('Posts', function (Blueprint $table) {
6      $table->bigIncrements('id');
7      $table->string('name');
8      $table->timestamps();
9      $table->softDeletes();
10    }
11  }
12}

php
1class Post extends Model
2{
3  use SoftDeletes; // 論理削除
4
5  public function users()
6  {
7    return $this->hasMany('App\User');
8  }
9}

User Model（子）

php
1class CreateUsersTable extends Migration
2{
3  public function up()
4  {
5    Schema::create('users', function (Blueprint $table) {
6      $table->bigIncrements('id');
7      $table->unsignedBigInteger('post_id');
8      $table->foreign('post_id')->references('id')->on('posts')->onDelete('cascade');
9      $table->string('name');
10      $table->timestamps();
11    }
12  }
13}

php
1class User extends Model
2{
3  // 物理削除
4
5  public function post()
6  {
7    return $this->belongsTo('App\Post');
8  }
9}

レコード削除処理

php
1class PostController extends Controller
2{
3  public function destroy(Post $post)
4  {
5    $post->delete(); // 親テーブルの指定レコードの削除
6  }
7}

発生した問題

削除対象の親テーブルのレコードに紐づく子テーブルのレコードは物理削除されない

試したこと

Post Model（親）

php
1class Post extends Model
2{
3  use SoftDeletes; // 論理削除
4
5  public function users()
6  {
7    return $this->hasMany('App\User');
8  }
9
10  /* 下記を追加 */
11  protected static function boot() 
12  {
13    parent::boot();
14    self::deleting(function ($post) {
15      $post->users()->delete();
16    });
17  }
18}

上記により削除されるようになりましたが、
「外部キー制約の設定さえすれば親テーブルの削除処理実行のみで紐づく子テーブルのレコードも自動削除される」と思っておりました。
私の認識が間違っていますでしょうか？

補足情報

Laravel 6.8

行動規範の内容に同意します

回答1件

ベストアンサー

migrationファイルのOnDleteの記述は、
laravelのModelがそれによって処理をうまいことやってくれる・・・とかいうヤツではなくて、
DBのテーブル定義の設定ですよね。

これはつまり、

DBのテーブルから実際にはデータが消えるわけではない「親の論理削除」によって、
外部キーを持つ子が自動的に物理削除されることはない

ということになります。

なので、仮に子テーブルの設定を

//子がいたら、親は削除できない設定
$table->foreign('post_id')->references('id')->on('posts')->onDelete('restrict');

にしても、親の論理削除でエラーが発生することはないようです。

もしかしたら、語弊があるかもしれないので、補足を。。

単なる定義であって、削除処理は書く必要

は、今回のケースが
「親の論理削除」で、「子の物理削除」をしたい話なので、そうなります。

先にも説明しましたが、migrationファイルの設定で自動的に削除実行するのは「DB」なので、
【DBにとっての削除】＝データの有無が変化する「親の物理削除」が、子テーブルへ処理のきっかけとして必要になるのです。
論理削除は、データを残したまま無効にする。。という【プログラム上の仕様】なので、【DBにとっての削除】には該当しません。

つまり、今のままの設定でも、親を「完全削除（強制物理削除）$post->forceDelete(); 」すれば、子の削除処理を書かずともDBが自動的に子も削除してくれます。

なお、DBによっては、親の論理削除を条件に子の削除を実行するtriggerを付けるようなことも可能ではありますが、migrationファイルで簡単に定義は出来ないかも？（やったことないのでもしかしたら簡単かもしれませんが・・）

私の個人的な意見としては、migrationで複雑な設定をするよりも、コードで書いた方が簡単で早いかなぁと思ったりもします。。。

投稿2020/06/26 07:47

編集2020/06/29 00:06