DB操作時のトランザクションがない

[uzulla]

TBD

• テンプレート作成に失敗しても、ロールバックされない。

現状

• 基本的にトランザクションを使っていないため
• つまりトランザクションを実装すれば良い

前段でMSDBクラスと、PDO/mysqliのWrapperにおいてトランザクション周りの機能追加が必要

• MSDB(マスター/スレーブ DB？)はレプリカの存在を前提としている？（デフォルトオフ）
• PDOとmysqliのギャップを埋めるWrapperがある
• 例外は内部でキャッチされ、詳細はログにおくられ、レスポンスとしてはfalseだけが返る
  • そのまま例外があがってくれればハンドリングしやすいが…？
  • ただ、すべて\Exceptionなので、\PDOExceptionなどにしたい気はする（ただ、デュアルサポートがきびしくなる）
• レプリカではトランザクションを明示的に拒否する（書き込みは発生しないはずなので）機能などが必要そう
• SQL文を流すことでもBeginやCommitは可能だが、通常DBドライバのメソッドを使うので、その機能が必要そう

検討

• メイン/レプリカ構成をサポートするWrapper（というより、DB接続の管理）は残すことは特に問題ない
• mysqliとPDOデュアルサポートをしているが、本改善や今後のサポート工数の削減を考えると、どちらかに寄せても良いのではないか？
  • 昨今のPHP実行環境においては、mysqliやPDOどちらかない実行環境、というのは特殊かと思われる。
• 現在のコードではmysqli優先となっている。それでもかまわないかと思います
  • いまはデュアルサポートしているので、mysqliならではの機能をつかっているわけではない

現状のDBまわりの別の問題点

• 万能関数resultなどに\Fc2blog\Model\DBInterface::RESULT_ONE, \Fc2blog\Model\DBInterface::RESULT_LISTさまざまな返り値の形がオプション指定ができるため、帰ってくる値の型が深い所の評価まで確定しないので、静的解析がききづらく、エラー処理を書いていて「なにがエラーでなにが正しいのか」がわかりづらい。@return が mixed|int|false|array などになってしまう
  • エラーハンドリングを例外でなく返り値で行うのはスタイルなのでそれはそれでと思うが、完全に最適化してもint|falseなどになるので、将来的なPHP(静的解析)には厳しいのではないか。
• 愚直に取得される型別に、別のメソッドにした方が良いのではないか。
  • そういうWrapper関数を生やすことはできるかと思う

[fc2dev]

・mysqliだけに寄せることは問題ありません。PDOExceptionを利用されたいのであれば、PDOにしても問題ありません。
・レプリカを必要とするようなケースは稀であることや、パフォーマンスや負荷の対策では、
KVSやCDNなどにキャッシュさせる実装の方が多いと考えており、MSDBは撤去いただいても問題ありません。
・戻り値でエラーと値が混ざるのは将来的にはエラー部分を例外に寄せたいと考えています。

[uzulla]

@fc2dev

ご回答ありがとうございます。

• エラーは例外に寄せる

上で、

• mysqliよりDBを生で操作する機能は少ないが、不要であろうと思われる
• PDOはDeprecatedになりづらいと思われる(メンテコスト削減)
• FETCH_CLASSなど、ORM的な事をするときに速度的に有意な機能がある
• (私が通常PDOで開発している)

という所から、PDOの方向で一本化を検討いたします。
また、MSDBについては取り外ししていきたいと思います。

#84 とからめた形で改善していきたいと思います。