クエリによって、ソートしたり、オフセット/リミットを指定したり、カラムと値と比較方法を指定してフィルターをかけたり、その他いろいろある事を忘れていた。
その為には一発でデータを引いてくる必要がありそう。
今までperson_idを最初にとってからやったんだけど、それじゃあソートできない。
で、変更。
Shindigに合わせるのも兼ねて。
http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/REST-API.html#standardQueryParameters
今こんな感じ。
はてなフォトライフ使ってみた。
__construct()でSQLのWhere以降をパーツで生成する
doXXX()が呼ばれる前の事前準備。
・OAuth認証を行う。
別クラスで。
1番上でrequire_onceしてるけど、なんか表示されてない。
もし認証に失敗した場合は、401 Unauthorizedを返す。
・リクエストによって、parseRequest_restもしくはparseRequest_rpc(まだ作ってない)を実行。
RESTの場合、PATH_INFOを"/"で区切って、場合によっては更に","で区切る。
・parseRequest_(rest|rpc)からparseRequest_commonを実行。
@viewerとかを具体的なIDに置き換える。
Where文をパーツで生成。
・parseRequest_(rest|rpc)からparseRequest_queryを実行。
引数はクエリの連想配列。
RESTの場合は$_GET。
フィルターのWhere文、OrderBy、Limit部分のSQLをパーツで生成。
doGet()/doPost()/doPut()/doDelete()でリクエストごとにメソッド振り分ける
doXXX()は全て同じ内容。
doPost()/doPut()/doDelete()からはdoGet()を呼ぶ。
doGet()の内容は以下の通り。
・HTTPメソッド＋サービス名のメソッドを呼び出す。
getPerson()とか。
もしメソッドが未実装だったり、変なリクエストがあった場合は、405 Method not allowedを返す。
getSQLSelect($columns,$table)でコンストラクタで作ったSQL文のパーツを繋げる。
・HTTPメソッド＋サービス名のメソッドの戻り値をreturnXXX()に渡す。
returnJson()とか。
返すべき型に変換して返すメソッド。
この辺はまだ形だけ。
そんな感じ。
なかなか簡潔になった。
コメントが残りつつ500行ちょっと。
Whereの負荷が半端ない
というか、負荷を全く考慮していない。
前回は殆どをPHPでやって、データベースへの負荷を最小限にしていた。(おのずとそうなった)
でも、今回は全く逆。
ANYをORで繋いだり。
いかにしてXXX.person_id=XXXという形にするかという部分。
フォローしてるかされてるかのユーザのIDを引くのが面倒。
今ANYを使ってる部分を、事前にPHP側でユーザIDを取って長ったらしいOR文を作った方がよさそう。
インデックスを張ってるとは言え。
いずれそうする。
ORもあんまり速くないって聞くけど、少なくともANYを平気で使う人間には関係のない話。
今は最低限動くものを作るのが最優先/最重要。
もっといい方法が思いつけばそっちで。
最低限守らなければいけないのは、Where以前がどんなSQLでも引けるような引き方にしなくちゃいけないって事。
コンピュータの負荷よりも人間の負荷！
Personはサービスプロバイダのもの
データベースを作った時に、なぜかコンシューマがユーザを所有していた。
で、ここも変更。
全てのテーブルに存在したconsumer_idカラムを削除。
consumerテーブルの殆どをスタティックにサービスプロバイダのデータとした。
それにしてもインデックス張りすぎ。
