操作
リファクタ #177
完了
ScoreLogDatabaseAccessor と ScoreDataLogDatabaseAccessor の統廃合方針を整理する
リファクタ #177:
ScoreLogDatabaseAccessor と ScoreDataLogDatabaseAccessor の統廃合方針を整理する
説明
Redmine #165 のコードベースレビューとユーザー確認からの派生タスクです。
背景¶
ScoreLogDatabaseAccessor と ScoreDataLogDatabaseAccessor は現状どちらも使用中ですが、責務が近いため統廃合して整理する方針になりました。
対応内容¶
- 両 accessor の保存対象、スキーマ、呼び出し元、互換性要件を整理する。
- 旧データや既存 DB との互換を壊さない移行方針を決める。
- 統合可能な責務と分離維持すべき責務を分類する。
- 実装が大きくなる場合は、調査・移行・削除のサブタスクに分割する。
確認観点¶
- 既存ユーザーのスコアログやリプレイ関連データを失わないこと。
-
PlayDataAccessorからの呼び出しと保存・読み込み動作に回帰がないこと。 - 必要な DB 互換テストを追加すること。
いづ さん さんが25日前に更新
- 関連している リファクタ #165: コードベースの棚卸 を追加
エージェント ちゃん さんが8日前に更新
- 子チケット #458 を追加
エージェント ちゃん さんが8日前に更新
調査結果 : 両 accessor は責務・スキーマ・読み出し経路・消費者がすべて異なるため、統合せず scoredatalog を廃止する方針¶
1. 保存対象・スキーマ・呼び出し元・互換性要件の整理¶
| 観点 |
ScoreLogDatabaseAccessor（scorelog.db / scorelog） |
ScoreDataLogDatabaseAccessor（scoredatalog.db / scoredatalog） |
|---|---|---|
| author | exch | omi |
| 保存対象 | 自己ベスト更新時の差分（clear/oldclear, score/oldscore, combo/oldcombo, minbp/oldminbp + mode, date） | 1プレイの ScoreData フルスナップショット（全判定数 + notes/combo/minbp/playcount/clearcount/trophy/ghost/option/seed/random/date/state/scorehash） |
| 主キー |
無し（全列 pk=0）→ INSERT OR REPLACE が実質追記。1譜面に複数行・date付き = 追記型イベントログ |
複合PK (sha256, mode) → INSERT OR REPLACE が upsert。(sha256,mode)単位で毎プレイ上書き = 最新スナップショット1行。名前に反して履歴は残らない
|
| 書き込み元 |
PlayDataAccessor.writeScoreData 2箇所（通常譜面 L306-310・コース L397-401）。差分があった時だけ sha256 をセットして記録 |
PlayDataAccessor.writeScoreData 1箇所（通常譜面のみ L312-321）。コース側には無し |
| 読み出し元 |
能動的に読まれる: SQLiteSongDatabaseAccessor.getSongDatas（scorelog.db を ATTACH し score.sha256 = scorelog.sha256 で JOIN）／BarManager の「今日のランプ更新/スコア更新」フォルダ（scorelog.clear > scorelog.oldclear AND scorelog.date ...）／CommandBar／RandomCourseData／外部 izu-IR scorelog-plugin（IR名 "Scorelog"） |
どこからも読まれていない（アプリ内に getScoreDataLog 相当なし、scoredatalog.db を ATTACH/SELECT する箇所もなし。外部消費も現状無しとユーザー確認済み） |
| 互換性要件 | 既存ユーザーDB・selectバー・曲DB JOIN・外部IRが依存。スキーマ/読み出し契約を維持必須 | 読み手が居ないため、書き込みを止めても既存 DB ファイルが孤立するだけで挙動への影響なし |
2. 移行方針（旧データ・既存DB互換）¶
-
scorelogは現状維持（スキーマ・追記挙動・読み出し契約をそのまま温存）。互換テストは既存のExistingUserDatabaseCompatibilityTest/ScoreLogDatabaseAccessorTestを継続。 -
scoredatalogは廃止。読み手が居らず、かつ upsert で履歴も持たないため移行すべきデータが存在しない。既存ユーザーのscoredatalog.dbはディスク上に残るが誰も開かなくなるため無害で、削除もマイグレーションも不要。
3. 統合可能な責務 / 分離維持すべき責務¶
-
分離維持（残す）=
scorelog: 「自己ベスト更新の疎な差分イベントログ」。選曲画面・フォルダ・曲DB JOIN・外部IRという確立した読み出し契約を持ち、他へ統合する利点がない。 -
廃止 =
scoredatalog: 「全プレイのフルスナップショット」だが未読・履歴なし。scorelogとは粒度（差分 vs フル）も保持戦略（追記 vs upsert）も読み手も異なり、安易に統合すると外部 scorelog-plugin・選曲JOIN・既存DB互換を壊すリスクのみが残る。両者は名前が似ているだけで責務が別物のため、統合ではなく未使用側の削除が妥当。
4. サブタスク分割¶
本チケットは調査・方針整理として完了し、実装は別チケットに切り出した。
-
#458 ScoreDataLogDatabaseAccessor（scoredatalog）を廃止する（リファクタ / 親 #177）: accessor 削除・
PlayDataAccessorの書き込み除去・関連テスト除去。データ移行は不要（未読・履歴なし）のため「移行」サブタスクは設けない。
確認事項¶
-
scoredatalog の廃止可否: 現状どこも読んでいない前提で「廃止」を推奨。ただし scoredatalog は ghost/seed/random/scorehash 等のリプレイ再構成情報を保持しており、将来リプレイ/IR分析で活用する計画があるなら、廃止せず
scorelog側の拡張で吸収する代替案もある。#458 着手前に最終方針を確認したい。 - 任意の軽微整理として、両 accessor のコンストラクタ/DataSource 構築ボイラープレートの共通基底化が可能だが、挙動非変更のため必須ではなく今回はスコープ外とした。
操作