※ 商品リンクから購入されると少額の報酬が発生することがあります。
LLの使用が許されそうな案件が降ってきました。
当然Djangoを突っ込みたいのですが、 パッチ をあてていないDjangoでOracle9iを使おうとするとちょっと大変です。
そもそもLLの使用が許されそうといっても、既存のスキーマに存在するテーブルを参照したりするので、ちょっとやらしいのです。
普段の業務DBに対応するためには、次のようなDBテクノロジの邪魔をせずに適切に扱ってくれることが要件です(実際は文字型系のセマンティクスも通常とちょっと違ったりする)。
ビューを扱える(READのみでよい。更新は指示をしないので勝手に更新しようとしなければ良い)
シノニムを扱える(テーブルと同様に扱いたい)
トリガーの動作を邪魔しない(Proxy型等UPDATEのタイミングを勝手に制御されると困る)
RailsのActiveRecordは指定したテーブル・ビュー・シノニムを難なく扱うことができました。
DjangoはOracleのリバースが実装されていません(手でモデルを書けば難なく扱えるはず)。
Djangoはおいしい機能を利用しようとするとDjango用のユーザテーブルが必要です。Ldapで認証して、認証より細かい単位で利用者を特定＋権限設定するためのテーブルをみて(ここまでは普段の業務アプリで常にやる)、Djangoユーザテーブルにユーザがいなければ追加するので3重管理です。
どうせならRailsを使ってみるのも悪くないのかな、と。
以下、愚痴です。わかってます、今風のデータベース設計じゃない所にRailsを突っ込もうとしているのが悪いんです
ビュー・シノニム・トリガーくらいがO/Rマッパの要件かな、と思っていたのですがRailsに踏み込んでみて愕然としました。
なんじゃ？ development/test/production?
rake test 時にdevelopmentデータベースからtestデータベースにスキーマをコピーする？
テーブルしかdumpできてないくせに勝手なことすんなこらっ。どうやってオフにするんじゃい！？
頼むから、テストDBの掃除しなくていいから、開発DBでテストさせてください。。。
テスト操作のデータが入っていたら、テストが誤動作するから？そんなテスト書くなっつの。
とてもスキーマのコピーは正しくしてくれそうにないので、testDBは全部シノニムにして、間違えてrake実行しても問題がないように(drop tableならシノニムは消えない)しようという案あり。
djangoでOracle9iできちんと使えるようにした方が素直なんじゃ？
RailsはレイヤーとしてはApache JServ(tomcatだと高機能過ぎ)みたいだなと感じているのは私だけ？
DjangoやTurboGearsとはレイヤーが違う気がする。
近々複数のRails使いにあえる機会があるので、いろいろ聞いてみよう。どうするかはそれから検討か。