デッキ編集ログ保存方法変更 #2306

概要

以下の問題への対応用のPR
https://git.dev.d-es.co.jp/gitbucket/jolly/jr-cs-issue/issues/109

テスト方法、確認した内容

以下をテストしてlog_deck_card_change_detailにデータが問題なく入るか確認

• デッキのカードを変更・追加
• 通常デッキ
• 戦争デッキ

• デッキのカードの配置変更
• 通常デッキ
• 戦争デッキ

• デッキのカードを外す
• 通常デッキ
• 戦争デッキ

• デッキをコピーする
• 通常デッキ
• 戦争デッキ

• デッキをリセットする
• 通常デッキ
• 戦争デッキ

• おすすめデッキ編成
• 通常デッキ

テーブル用クエリ

CREATE TABLE `log_deck_card_change_detail` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_no` bigint(20) NOT NULL,
  `is_war_deck` tinyint(4) NOT NULL,
  `change_type` tinyint(4) NOT NULL,
  `deck_no` tinyint(4) NOT NULL,
  `position_no` tinyint(4) NOT NULL,
  `set_card_holder_no` int(11) NOT NULL,
  `set_card_no` int(11) NOT NULL,
  `reg_date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`,`reg_date`),
  KEY `reg_date` (`user_no`,`is_war_deck`,`deck_no`,`reg_date`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8mb4;

TODO

• 懸念点

何度もリセットやおすすめデッキ編集を実行されると無駄データが溜まってしまう可能性

• 一定期間過ぎたデータの削除

@wada
レビューお願いいたします

@kouho
パーティションは作成しますか？

このテーブルに対してどのようなsqlを実行しますか？
予めsqlを想定してくことで、テーブル構造を最適にしておきたいです。

関数内でS_db_connectする場合は、存在チェック後に実施お願いします。

@wada
確認とご指摘ありがとうございます。
指摘を受けてCREATEクエリの変更を行いました。

> 関数内でS_db_connectする場合は、存在チェック後に実施お願いします。

存在チェックを追加しました。

> パーティションは作成しますか？

以下のパーティションを貼る予定です。
パーティションを貼るためにreg_dateをPRIMARY KEYに設定変更しようと思います。

#パーティション化
ALTER TABLE log_deck_card_change_detail
PARTITION BY RANGE ( UNIX_TIMESTAMP(reg_date) ) (
  PARTITION p202209 VALUES LESS THAN ( UNIX_TIMESTAMP('2022-10-01 00:00:00') ),
  PARTITION p202210 VALUES LESS THAN ( UNIX_TIMESTAMP('2022-11-01 00:00:00') ),
  PARTITION p202211 VALUES LESS THAN ( UNIX_TIMESTAMP('2022-12-01 00:00:00') ),
  PARTITION p202212 VALUES LESS THAN ( UNIX_TIMESTAMP('2023-01-01 00:00:00') ),
  PARTITION p202301 VALUES LESS THAN ( UNIX_TIMESTAMP('2023-02-01 00:00:00') ),
  PARTITION p202302 VALUES LESS THAN ( UNIX_TIMESTAMP('2023-03-01 00:00:00') ),
  PARTITION p202303 VALUES LESS THAN ( UNIX_TIMESTAMP('2023-04-01 00:00:00') ),
  PARTITION p202304 VALUES LESS THAN ( UNIX_TIMESTAMP('2023-05-01 00:00:00') ),
  PARTITION p202305 VALUES LESS THAN ( UNIX_TIMESTAMP('2023-06-01 00:00:00') ),
  PARTITION p202306 VALUES LESS THAN ( UNIX_TIMESTAMP('2023-07-01 00:00:00') ),
  PARTITION p202307 VALUES LESS THAN ( UNIX_TIMESTAMP('2023-08-01 00:00:00') ),
  PARTITION p202308 VALUES LESS THAN ( UNIX_TIMESTAMP('2023-09-01 00:00:00') ),
  PARTITION p202309 VALUES LESS THAN ( UNIX_TIMESTAMP('2023-10-01 00:00:00') ),
  PARTITION p202310 VALUES LESS THAN ( UNIX_TIMESTAMP('2023-11-01 00:00:00') ),
  PARTITION p202311 VALUES LESS THAN ( UNIX_TIMESTAMP('2023-12-01 00:00:00') ),
  PARTITION p202312 VALUES LESS THAN ( UNIX_TIMESTAMP('2024-01-01 00:00:00') ),
  PARTITION p202401 VALUES LESS THAN ( UNIX_TIMESTAMP('2024-02-01 00:00:00') ),
  PARTITION p202402 VALUES LESS THAN ( UNIX_TIMESTAMP('2024-03-01 00:00:00') ),
  PARTITION p202403 VALUES LESS THAN ( UNIX_TIMESTAMP('2024-04-01 00:00:00') ),
  PARTITION p202404 VALUES LESS THAN ( UNIX_TIMESTAMP('2024-05-01 00:00:00') ),
  PARTITION p202405 VALUES LESS THAN ( UNIX_TIMESTAMP('2024-06-01 00:00:00') ),
  PARTITION p202406 VALUES LESS THAN ( UNIX_TIMESTAMP('2024-07-01 00:00:00') ),
  PARTITION p202407 VALUES LESS THAN ( UNIX_TIMESTAMP('2024-08-01 00:00:00') ),
  PARTITION p202408 VALUES LESS THAN ( UNIX_TIMESTAMP('2024-09-01 00:00:00') ),
  PARTITION p202409 VALUES LESS THAN ( UNIX_TIMESTAMP('2024-10-01 00:00:00') ),
  PARTITION p202410 VALUES LESS THAN ( UNIX_TIMESTAMP('2024-11-01 00:00:00') ),
  PARTITION p202411 VALUES LESS THAN ( UNIX_TIMESTAMP('2024-12-01 00:00:00') ),
  PARTITION p202412 VALUES LESS THAN ( UNIX_TIMESTAMP('2025-01-01 00:00:00') )
);

> このテーブルに対してどのようなsqlを実行しますか？
> 予めsqlを想定してくことで、テーブル構造を最適にしておきたいです。

log_deck_type_changeで調べたい用途のデッキのdeck_noを調べて
user_no,deck_no,is_war_deck,reg_dateを使い主に以下のようなクエリを実行しデッキカードの変更ログを確認する予定です。
user_no,deck_no,is_war_deck,reg_date4つのカラムの複合インデックスを追加しようと思います。

SELECT * FROM log_deck_card_change_detail
WHERE user_no = x
AND is_war_deck = y
AND deck_no = z
AND reg_date >= 'start'
AND reg_date <= 'end'

解雇したとき
転生したとき
進化したとき
などなにかしたらカードに変更があった時の対応

user_noのBIGINTはINTで大丈夫

@wada_tomoya
以下デッキログに入れるように修正行いましたので確認お願いいたします。

• 転生したとき
• 覚醒合成で誘発者として利用したとき
• 覚醒合成で進化したとき

解雇したときについては
デッキ編成中のカードは解雇できませんでしたので対応しておりません。

TODO トレードでカードがなくなったとき

@wada
口頭で話しました対応を行いました。

• 共通処理の関数化
• トレードでデッキにセットされているカードを削除する際のログ記録(対応途中)

現在のトレード時の問題
トレードの際にS_InsertDeckCardChangeLog関数に$change_type = 9 が渡ってきているが、
S_SetDeckCardChangeLog関数内の$sqlStではchange_type=0になっている。

@kouho
> トレードでデッキにセットされているカードを削除する際のログ記録(対応途中)

上記確認したいのですが、デッキにセット中のカードをトレードするにはどうすれば良いですか？

@wada
トレードで選択する際に「デッキにセットされています」と表示されますが、カードを選択することでトレードできました。

@kouho
できました。
用途を設定していないデッキのカードはトレードできるんですね。

@wada
了解です。なるほど用途設定しているデッキのカードはトレードできなかったんですね。
そこ見れてませんでした。

@kouho
確認できた範囲では、S_SetUserCardHoldelReleaseUpdateLog()のS_InsertDeckCardChangeLog()で$card_dataにcard_holder_noがないので、ログデータが作成されていないようでした。

//$card_data['card_holder_no']はないので、S_SetUserCardHoldelReleaseUpdateLog呼び出し前に設定が必要
S_InsertDeckCardChangeLog($user_no, $card_data['card_holder_no'], \DeckUtil::DECK_CHANGE_TYPE_TRADE, 0, 0 );

@kouho
DeckUtil.class.phpですが、
ジョリーではconstを管理するクラスは、{Type}Const.class.phpとしているのでそちらに合わせて欲しいです。

また、DECK_CHANGE_TYPE_CARD_SET = 0は、0以外の数値にして欲しいです。
constでは0に意味を持たせないで欲しいです。
（phpでは意図せず0と判定されることが多いため）

@wada
確認ありがとうございます。
> 確認できた範囲では、S_SetUserCardHoldelReleaseUpdateLog()のS_InsertDeckCardChangeLog()で$card_dataにcard_holder_noがないので、ログデータが作成されていないようでした。

$card_data['card_holder_no']ではなく、holder_noに値が入っていましたので修正しました。

> DeckUtil.class.phpですが、
ジョリーではconstを管理するクラスは、{Type}Const.class.phpとしているのでそちらに合わせて欲しいです。

> また、DECK_CHANGE_TYPE_CARD_SET = 0は、0以外の数値にして欲しいです。
constでは0に意味を持たせないで欲しいです。
（phpでは意図せず0と判定されることが多いため）

DeckUtilクラスをDeckConst.class.phpに修正しました。
また、constの値を1こずつずらしました。

@kouho
ありがとうございます。確認OKです。