仕様決定には知識が必要、無ければ崩壊
なにを当たり前のことを、という感じですが、とても悔しかったので書きます(笑)
仕様、といっても、システムの動作に関する仕様ではなく、どちらかというとコーディングの規約とか方針みたいなほうの仕様です。
ほら、あるじゃないですか、このアプリ作るときにはこのライブラリをこういう風に使う、とか、こういうことやりたいときはこういう関数使う、とか。
今回Ethna色々研究中に、まぁ最初なので色々とやってみようと思い、とりあえずはAppObjectを使う方針ではじめたのですが、これが失敗。
要するに、
- AppObjectで何ができるのか
- AppObjectで何ができないのか
この2つを完全にわかっていないと、必ずどこかで失敗します。あ、別にEthnaの話だけじゃなくて、あらゆるもので。例えばDBのクラスにしても、PEAR::DB使うのか、ADODB使うのか(私はADODBが好きなのですが)とか、それぞれで何ができて何ができないのかを知った上で選択しないと後で大変なことになります。*1
で、今回アプリケーションオブジェクトをO/Rマッパとして使うか、そもそもややこしいのでアプリケーションオブジェクトは使わずに、AppManagerでDBの挿入・削除・更新を自分で書くか(要するにSQL文を書くかどうかの違いだな・・・)を迷って、結局AppObejctを使ってみました。もちろん勉強の意味も含めてだったので、知らないなら使ってみるか、くらいの気持ちで。あ、ちなみにどっちにしてもモデル部分にはアプリケーションマネージャは使います。マネージャの中で getObject するか、getDB するかの違いです。
今回の問題は、
- update をかけたとき、すべてのカラムが更新されてしまう
- 例えば、「created」みたいな、挿入時点でのデータを残しておきたいものは更新したくない
でした。
これだけですが、これが大事なんだってー。。で、結局なにがそこまで失敗だったかというと、
- AppObjectを使うために好きなADODBをあきらめ、PEAR::DBを使った
- 部分的なupdateができないので結局updateメソッドだけAppManager内でgetDBして更新する文を書いた
- だったら全体をそうやって統一したかった
- だったらいっそのことオブジェクト使わずに・・・
- そしたらADODBも使えたのに
みたいなあー。
あ、そうそう、問題のAppObjectですが、最初はsetされてないやつは更新かけないようにupdateできると思っていたら失敗し、ソース調べてたらupdate文の中に、prop_def (だっけかな?)を自動で調べちゃう部分があったので、部分的なアップデートはできないんだ、と思ってるのですが、もし万が一「それできるよ」ということを知っている方がいたら、(このエントリはすべてどうでもいいカンジになってしまいますが)教えてください(笑)
というわけで、教訓になりました。
今度からEthnaでアプリ作るときはAppObjectは使いません。ManagerでSQL書いたほうがいいわい。
*1:もちろんDBクラス程度じゃあそんな苦労はしませんが。記述方法かえるだけ、とかだろうし