save()を使った１レコードの値の更新について

Question

前提・実現したいこと

現在、スマートフォン向けのアプリを作成中です。
webのリクエストからDB内のデータを変更するプログラムを作成しています。

Laravelのコントローラ内の処理で、
テーブルからレコードを取得し、
その中の値を変更するプログラムを記述しました。

しかし、挙動が望ましくありません。

発生している問題・エラーメッセージ

・求めている結果
取得した1レコードのみ更新

・実際の結果
user_idに紐づいたstatusカラムの全ての値が
変更されている。

更新前

更新後

１．
ドキュメントによると、save()という挙動が、
「モデルの更新をする」という説明になっています。
https://readouble.com/laravel/6.x/ja/eloquent.html

私の考えの
取得したレコードを変数として与え、
その「1レコード部分の更新」という使い方は
できないものなのでしょうか。

２．
この1レコードを更新することを実現するには、
どのようなアプローチをすればよろしいでしょうか。

参考文献や、
知見がありましたら、

ご教授いただけますと幸いです。
よろしくお願いいたします。

該当のソースコード

---ソース（コントローラ）---

public function Foo(Request $request){

	$user_id = $request->user_id;
	$quest_id = $request->quest_id;

	//user_questからクエスト取得
    $user_quest = UserQuest::where('user_id', $user_id)->where('quest_id', $quest_id)->first();
    if (!$user_quest){
        return config('error.ERROR_INVALID_DATA');
    }
	
	//値の変更
	$user_quest->status = 3;

	//DBの更新
	try{
	   　$user_quest->save();
	} catch (\PDOException $e){
		return config('error.ERROR_DB_UPDATE');
	}
	
	~~
}

---モデル---------

class UserQuest extends Model
{
                //
    protected $table = 'user_quest';
    public $incrementing = false;
    protected $primaryKey = 'user_id'; //複数未対応
    public $timestamps = false;
}

---マイグレーション---

   public function up()
    {
        Schema::create('user_quest', function (Blueprint $table) {
            $table->string('user_id', 37)->charset('utf8');
            $table->unsignedInteger('quest_id')->default(0);
            $table->unsignedTinyInteger('status')->default(0);
            $table->boolean('clear')->default(0);
            $table->timestamp('created_at')->default(DB::raw('CURRENT_TIMESTAMP'));
            $table->timestamp('updated_at')->default(DB::raw('CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP'));
            $table->primary(array('user_id', 'quest_id'));

        });
    }

試したこと

ドキュメントやブログを参考に
saveやupdateの挙動などを調べました。
問題を解決する根本の原因が特定できておりません。

補足情報（FW/ツールのバージョンなど）

####各種バージョン

・PHP
7.2.27

・Laravel
6.16.0

・MySQL
5.7.29

####参考書籍
「スタートアップ・個人で作れるスマホ向け Unityソーシャルゲーム開発ガイド」
https://www.shuwasystem.co.jp/book/9784798059389.html

###全体の処理の流れや、構成について

処理の流れは、
下記のようになっています。

---

①user側のテーブルからユーザidを取得し、
クライアント側に保持
(user_profileテーブル)後述

②取得したユーザidにクエストidの情報をつけて
quest(ユーザ側)のテーブルを更新 ←今回ご質問していた箇所
(user_questテーブル)

③quest（マスターデータ）側はJSONで取得し、
クライアント側で保持
（特に上記のサーバ側の箇所に干渉しない）

---

◆user側
利用するユーザ情報を定義しています。
・ユーザid
・ユーザ名

quest(ユーザ)側の「user_quest」テーブルと共通するユーザid(user_id)のカラムを持っていますが、
現状、サーバー側で「user_profile」テーブルと、「user_quest」テーブルを複合して
参照する処理はまだ追加していません。

テーブル名：user_profile

〇user_profileテーブル
---------マイグレーション----------
Schema::create('user_profile', function (Blueprint $table) {
$table->string('user_id',37)->charset('utf8');
$table->string('user_name',32)->charset('utf8');
$table->timestamp('created_at')->default(DB::raw('CURRENT_TIMESTAMP'));
$table->timestamp('updated_at')->default(DB::raw('CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP'));
});

---

◆quest（ユーザ）側
ユーザが持つ変動的なゲーム情報を定義しています。
・クエストクリア（未or済）
・クエスト状態（スタート、リタイア、クリア）　など

テーブル名：user_quest
(↑今回ご質問したテーブル)

〇user_questテーブル
---------マイグレーション----------
Schema::create('user_quest', function (Blueprint $table) {
$table->string('user_id', 37)->charset('utf8');
$table->unsignedInteger('quest_id')->default(0);
$table->unsignedTinyInteger('status')->default(0);
$table->boolean('clear')->default(0);
$table->timestamp('created_at')->default(DB::raw('CURRENT_TIMESTAMP'));
$table->timestamp('updated_at')->default(DB::raw('CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP'));
$table->primary(array('user_id', 'quest_id'));

    });

---

◆quest（マスターデータ）側
固定的なゲーム情報を定義しています。
（クエスト情報）
こちらはJSON形式で別に管理しています。

quest側の構成
・クエストid
・クエスト名　　　など

Comments

[退会済みユーザー]

データベースのカラムを拝見すると、user と quest を多対多で結ぶための中間テーブルに見受けられますが、その辺りの説明が足りていませんので、説明ください。

[kyoya0819]

これどこを参考に書かれていますか？

[m.ts10806]

>[Laravel][PHP][MySQL]
タイトルに含まなくてもタグで対応可能です。タイトルが冗長になるだけなので、タグで対応できるものはタグのみで対応してください。

[fromtasky]

>m.ts10806 さん
タイトルの件対応いたしました。

[fromtasky]

>asuchi0819　さん
下記書籍を参考にしています。
「スタートアップ・個人で作れるスマホ向け Unityソーシャルゲーム開発ガイド」
https://www.shuwasystem.co.jp/book/9784798059389.html

[fromtasky]

>Kosuke_Shibuya さん
ご質問の意図に沿っていなかったら、すみません。
下記、説明を記載いたします。

〇そのあたりの全体の構成や流れについて

（↑質問本文に記載しました）

[kyoya0819]

Unityの本にLaravelが書かれているのでしょうか？

[fromtasky]

>asuchi0819 さん
はい、こちらの参考書籍は、サーバー側(AWSで作成したlinux上にLAMP環境を構築し、Laravelを使用したサーバー側）と、Unityを使用したクライアント側のやりとりについて記述されています。(本の内容としては、必要最低限の説明があり、細かくは調べてね・・というスタイルの本です)
本だったので、参考元のソースコードをペタっと張ることができませんでした。

[m.ts10806]

様々な情報をこちらのコメント欄に書かれていますが、デフォルト非表示であるため目につきにくいしまとめて確認が難しいのです。
質問本文に記載してください。

[fromtasky]

> m.ts10806　さん
不慣れですみませんでした。記載箇所移行します。

Answer 1

UserQuestモデルでuser_idを主キーとして設定していますが、user_questテーブルのマイグレーションを見たところではuser_idとquest_idの複合主キーで定義されています。ここが一致していないのが根本原因です。

Eloquentモデルは主キーとして設定されたカラムでレコードを一意に識別できるということを前提にしていますので、user_idのような一意に識別できないカラムを指定した場合は正しい動作は保証されません。おかしな設定でも特にエラーの検出はしてくれませんのでなんとなく実行されますが、同じuser_idでquest_idが異なるカラムがある場合は全てが更新されてしまいます。(update ... where user_id = xxのようなsqlが実行されますので)

対処としてはEloquentモデルは複合主キーは扱えませんので、user_questテーブルについて別に自動インクリメントする整数のカラムを主キーとして用意し、user_idとquest_idについてunique indexを作成するのがいいでしょう。

Comments

[fromtasky]

ご回答ありがとうございます。
再度マイグレーション作成を行い、検証してみます。

[fromtasky]

ひとまず、いただいたアドバイスを参考に、
再度マイグレーションを作成し、やり直したところ、
１レコードの更新ができました。ありがとうございます。
解決方法、後ほど記載いたします。

[fromtasky]

ありがとうございました。解決後の変更点を記載します。
おっしゃる通り、主キーの設定が原因でした。
もう少し、テーブル設計を検討・調整してみます。
---------
主にuser_questテーブルの構成の以下を変更しました。
・主キー:id 自動インクリメント ←新規に追加
・user_id index付与
・quest_id index付与

----変更後のマイグレーション---

Schema::create('user_quest', function (Blueprint $table) {
$table->increments('id');
$table->string('user_id', 37)->charset('utf8');
$table->unsignedInteger('quest_id')->default(0);
$table->unsignedTinyInteger('status')->default(0);
$table->boolean('clear')->default(0);
$table->timestamp('created_at')->default(DB::raw('CURRENT_TIMESTAMP'));
$table->timestamp('updated_at')->default(DB::raw('CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP'));
$table->index('user_id');
$table->index('quest_id');
});

[crhg]

user_idとquest_idの同じ組み合わせは複数存在してはいけないから複合主キーにしていたのではないのでしょうか? その場合は組み合わせで複合uniqueインデックスにする必要があります。

$table->unique(['user_id', 'quest_id']);

[fromtasky]

失礼いたしました。indexを指定していた前に、単体にuniqueを付与していたため、完全に複合とするところを間違えていました。
ご指摘の通り、複合uniqueインデックスにて、動作確認いたしました。
ありがとうございました。

---削除---
$table->index('user_id');
$table->index('quest_id');
---追記---
$table->unique(['user_id', 'quest_id']);