DB接続ライブラリをPEAR::DBからADOdbへ置き換えてみる

[ebihara]

現在のOpenPNEはDB接続ライブラリにPEAR::DBを使用しているが、これをADOdb（​http://adodb.sourceforge.net/）に置き換える。

ADOdbを使用することによるパフォーマンスの向上と、将来的にADOdbに組み込まれているキャッシュ機構を取り込むのが狙い。

参考：http://trac.openpne.jp/wiki/pne-sysadmin

DB接続ライブラリ選定 ¶

OpenPNEをスピードアップさせるために、DBの接続ライブラリを現在のPear:DBから変更する。

    * ADODB
    * PDO(最速でOpenPNE2.12以降で対応を検討) 

SQLキャッシュ ¶

MySQLのクエリーキャッシュを使わずに、PHPのレベルでSQLキャッシュをかけて、負荷を軽減する。

現状ではADODBに組み込まれている、キャッシュ機構を取り込んでいく予定。
単一リクエスト・レスポンス内のSQLキャッシュ ¶

c_memberデータなど、単一のリクエストレスポンス内で行うSQLキャッシュ
単一リクエストを超える特定時間のSQLキャッシュ ¶

c_snsconfig等比較的長期間キャッシュを保持して良いデータに対するSQLキャッシュ 

[ebihara]

やります

[ebihara]

http://trac.openpne.jp/browser/OpenPNE/branches/prj/sysadmin

このブランチに成果物をコミットします。

[ebihara]

webapp/lib/OpenPNE/DB.php で以下のファイルを require してみました require_once 'adodb/adodb.inc.php'; require_once 'adodb/adodb-pear.inc.php';

_connect() など基本的な部分は動作しましたが、$this->db->modifyLimitQueryは互換性がないということで、limit節を付加したSQL文を生成する代替の関数を探してみましたが、見つかりません。 SelectLimit?() などでうまく代替できないかどうか調べてみます。

ちょっと反則して $this->db->modifyLimitQuery をコメントアウトしてみると、PEAR::Auth周りでもエラーが出ているので、このあたりが鬼門になるかもしれません。

​http://phplens.com/lens/adodb/docs-adodb.htm#pear によると以下の関数に対応しているようなので、それほど苦労せずに置換できそうな印象ではあります。

DB_Common query - returns PEAR_Error on error limitQuery - return PEAR_Error on error prepare - does not return PEAR_Error on error execute - does not return PEAR_Error on error setFetchMode - supports ASSOC and ORDERED errorNative quote nextID disconnect

getOne getAssoc getRow getCol

DB_Result numRows - returns -1 if not supported numCols fetchInto - does not support passing of fetchmode fetchRows - does not support passing of fetchmode free <<

[ebihara]

r3603, r3648

以上のリビジョンで対応しました。成果物は http://trac.openpne.jp/browser/OpenPNE/branches/prj/sysadmin です。

作業していたコミュニティは以下： ​http://openpne.jp/?m=pc&a=page_c_topic_detail&target_c_commu_topic_id=2442

#1013:OpenPNE_DBとOpenPNE_DB_Writerをadodb用に書き換え（r3605,r3641,r3643をマージ）
http://trac.openpne.jp/changeset/3648

で、ADOdbに一通り対応させました。僕のほうで動作確認をしてみた限りでは、ちゃんと動いているようです。
今回はまってしまったポイントを列挙しておきます。実装やツッコミの参考になれば幸いです。
※関数名の違いや引数の順番の違いなどの軽微なポイントは省略してます

・PEAR::AuthのPEAR::DB依存
　→ADOdb側で"DB"という名称のクラスを作らないことで対処（PEAR::DBとの互換性を維持するためのadodb-pear.inc.phpを require しないようにする）
　→PEAR::AuthにはPEAR::DBをいままでどおり使っていてもらう

・modifyLimitQuery()と互換のメンバ関数がない
　→SelectLimit()を使うようにOpenPNE_DBのメンバ関数の中身そのものを書き換えてしまう

・ADOdbは配列形式のDNSを受け入れない
　→コンストラクタ内で強引に文字列形式のDNSに変換。ただこれだとMySQLしかうまく行かないかもしれないので、検討の余地あり（本当は PEAR::DBや adodb-pear.inc.php の parseDNS() を引っ張ってきて使いたかったんですが、ライセンス的な問題で踏みとどまりました。いや使ってもいいはずだろみたいなツッコミがあったら、即刻書き換えるので教えてください）

・autoExecute() は デフォルトで NULL や 空文字列をSQL向けに置き換える
　→まあ親切ではあるんですが、このままだと insert や update がうまく行かず、しかたないので空フィールドを無視するように _connect() 内で $GLOBALS['ADODB_FORCE_TYPE'] = ADODB_FORCE_IGNORE; とか書いてます。あー、これ、コンストラクタでもよかったな

・getAssoc() などは結果が空の場合、エラーは返さないが false を返す
　→falseを返されると null や 空の配列 を想定したコードの場合に困ったことになるので、 if ($res === false) { /* code */ } とかで対処

・OpenPNE_DB::get_col_limit() を実現する関数がない
　→get_row() とかは SelectLimit() でレコードセットを作成してから FetchRow() でうまく行ったのですが、FetchCol()的な関数もないしどうしたらいいの、状態でした。Fileds()とかも用途が違うし。
　結局、以下のようにして泥臭い対処。まあでも、これしかないような気が……
　>>
$recordset =& $this->db->SelectLimit($sql, intval($count), intval($from), $params);
$res = array();
while (!$recordset->EOF) {
$res[] = array_shift($recordset->fields);
$recordset->MoveNext();
}
return $res;
　<<

もし「なんでこんなまどろっこしいことしてるんだよ」「この処理ちがってんじゃねーか！」みたいなツッコミがありましたら、是非お願いします！

[kunitada]

実験完了