Teng v0.14_01 released / perl dbi teng / 2011-11-22 / permalink / Comments このエントリーをはてなブックマークに追加

Tengのv0.14_01をリリースしました。
devリリースです。

Changesから引用すると

- [IMPORTANT] bulk_insert include core feature. do not use Plugin::BulkInsert.- add Plugin::Lookup.
- fixed fork safe connection. (thanks nihen)- support auto reconnect dbh. (thanks nihen)
- can specific column for single or search method.
- support bulk_insert for postgresql 8.2.0 over. (thanks makamaka)
- support bind_param. (thanks makamaka)
- add Plugin::SingleBySQL. (thanks nihen)

このような変更になっております。
Teng::Schema::Loaderが後方互換ない変更ですのでご注意ください。
とはいえ、使いやすくなってるとおもいます。

何か問題あれば言って下さい。

enjoy!


Teng v0.14 released / perl dbi teng / 2011-11-11 / permalink / Comments このエントリーをはてなブックマークに追加

v0.13の変更で$row->updateを経由させると、
deflateが二回実行されるバグがあったので修正しました。


v0.13を使っている人はupdateを
v0.13を使おうと思っていた人は使わないようにしてください!

very thanks @kentaro


Teng v0.13 released / perl teng / 2011-11-10 / permalink / Comments このエントリーをはてなブックマークに追加

Tengのv0.13をreleaseしました。

今回の変更ではinflateのbugfixが入っているのでupdateをおすすめします。@kentaro++
またDBD::SQLiteのバージョンによりtestが一部おかしくなるもののfix。@charsbar++
もういっこがsingleメソッドのチューニングになります。


singleメソッドが結構色々無駄が多かったので色々ショートカットしました。
挙動の変化はありません。


ORMについて / perl teng dbi skinny / 2011-11-08 / permalink / Comments このエントリーをはてなブックマークに追加

最近方々でORM不要論が巻き起こってたりするとかしないとか。
まぁ自分も結構煽ってた節があるのでここでちょっくら
おそらく日本のPerl界隈のORMで一番使われているであろう(自分の適当調べ)、
DBIx::SkinnyとTengの作者の本気の意見
を、ここに吐露してみようと思う。


結論から言うと、一般的なWebアプリだったりそれに付随するアプリ、
DB周りを操作するアプリに関しては普通にORM使えばいいと思います。
以上


以下は色々思うことなどをつらつらと。


正直つかいたければDBICやDODやその他のORMも使い倒したらいいと思います。
DBICにはDBICの良さがあり、typesterさんが今も愛用するにはそれなりに訳があるし
DODはL社でよく使ってるらしいし、DODの透過キャッシュがやっぱり便利だという声も聞きます。
要件を満たせばどんなORMだってつかえばいいんですよ。
もちろん私はTeng / DBIx::Skinnyがイチオシです!


よく、ORMのRowクラスにメソッド生やしてそこで色々処理させるとか
普通に便利だと思うし、リレーションたどってdatabaseを渡り歩きながら
いろんな情報を引っ張りだせるのも一般的なORMの便利なところだと思います。
# DBIx::Skinny / Teng自体はリレーション関係をORMとして提供できないけどRowクラスにそういうメソッド定義すれば可能ではある

Rowクラス作るのが糞だとか言われるのは、
そらDBICみたいに糞でかいオブジェクトにされると
パフォーマンス的な劣化は否めないけどそれでも一般のWebアプリだと別に問題ない。
もちろん行が10000行とかになってそれが全部Rowオブジェクトにされてしまうとか
だとアレゲだけど、そんなのORMの問題ではなく単なる使い方の問題。


一番やっちゃいけないのはなんか周りがアンチORMの人が多いからORMやめとけとか
よくわからない風説に流されることですね。


自分は、昔々につくってたWebアプリではDBICでゴリゴリ作ってましたけど全然普通に動いてましたし。
そら若干重い部分も合ったとは思いますが、大きな不都合はなかった。
本当にホットスポットな部分だけナマのSQLを書いてナマのDBI経由で処理させるとか
やってましたけど、それ以外はDBICバリバリで全然問題なかった。


じゃあなんでDBIx::SkinnyやTengを作ったのかは、
いろんな所で言ったり書いたから割愛するけど知りたい人はここ見て下さい。


DBIx::SkinnyやTengは個人的にも、利用して頂いてフィードバックいただいている方の意見でも同じ
結論になるんですけど、絶妙な按配の上に成り立ってるとおもいます。
「使ってみたらああなんかこんな感じなのを求めていたんだよ」みたいな。
ただ最近忙しかったり仕事でDBIx::SkinnyやTengを使う機会がなかったのであんまり触ってこれなかったんだけど、
周辺ツールだったりでは使える場所はいくらでもあるし、使う環境も良い感じで整いつつあるので、
今後折を見て仕事にも活かしていこうと思ってる。


あと、Tengつくったあと特別宣伝してないのに、意外に多くの人に使ってもらってたりして、
これはそろそろ本気だして宣伝したほうがいいかなと思った。
のでぼつぼつ活動再開するよ。


こんなこと言ったら運用の人達から椅子がバンバン飛んできそうだけど、
そもそもヒットするWebアプリなんてなかなか作れない。
そこそこのリクエストをさばければ十分だし。

その中で運良くヒットしてチューニングが必要だーってなってからやってもいいよね。
実際問題そこに工数割く事ができないだろ、
そのまま糞重いサイトを引きずって結局運用に尻拭いのお鉢がまわってくるじゃねーか!ってなるかもしれんけど、
一番は多くのユーザに使ってもらうサービスをスピード感もって作ってリリースすることなんだから
そんなのはまぁみんなで死に物狂いでがんばればいいんじゃないかな!
よーしらんけどw

#適当なこといってるから椅子とんできたらこわいけどw

まぁそんな中で一言言わせてもらうと、DBIx::SkinnyとTengは運用の人が大好きな生のSQLも良い感じに扱えるし、
結構パフォーマンスにも気を使ってつくってるからDBIx::SkinnyやTeng自体がパフォーマンスのボトルネックになることは
無いと言い切っときます。
DBIx::SkinnyやTengそのものがボトルネックになるってことはそれはもう大変な規模のサービスでしょうね。


だからみんなTeng(DBIx::Skinny)をどんどんつかってどんどんフィードバック頂戴ね♪


Tengでのコネクション管理について / perl teng / 2011-02-28 / permalink / Comments このエントリーをはてなブックマークに追加

現在Tengでのコネクション管理方法を模索中です。


旧来までのSkinny方式のメリットは
connect_infoがある場合はTeng側で
コネクションの接続管理(再接続等)、
トランザクション管理(コネクションとトランザクションは同時に意識して管理する必要がある)
がある程度可能な所でしょう。


ただ、問題もあります。
Skinny/Tengではnewする時などに外部で生成したdbhを受け取り
それを使う事が可能なのですが、connect_infoが不明なため、
Skinny/Teng側ではreconnectしようがないので、若干挙動が分かりにくくなる所でしょう。
(dbhからconnect_infoを取れないのは検証済み..いや、取れるよ!って場合は教えてください!)


またコネクションの再接続は切れてるから接続し直せば良いというものでもありません。
トランザクション中だったり、on memoryにテンポラリテーブルをつくってごにょごにょやっている場合
コネクションを再接続して微妙に動いているように見えても困る訳です。
(その辺りの管理をやりだすと結構色々面倒だしケースバイケースになってくるからあんまやりたくない)


じゃあどのようにするのがよいか。
なのですが、
1:いっそのことTeng側ではコネクション管理やめちゃえという案
2:あんま考えずにSkinny方式でいいじゃないか案
3:インテリジェンスなコネクション管理をTengで持てばいいじゃないか案
があるんですが

現状私の考えでは1を考えています。


コネクション管理をTeng外で行う。

CPANにDBIx::Connectorというモジュールがあるのですが
これは接続とトランザクションを管理するモジュールです。

こういうライブラリで生成されたオブジェクトをTeng側ではうけとり、Teng側でdbhが必要になったら
コネクション管理モジュールのインスタンスからdbhを貰う。

でも外部ライブラリに変に依存したくないし、自前でコネクション管理モジュール書くのやな場合も
当然あるであろうので、Teng側ではconnect_infoを受け取ったらSkinny方式でコネクション管理する
モジュールも同梱する。

でもDBIx::Connectorはコネクションとトランザクション管理だけやってればいいのに余計な事やってるのが
個人的には気に入らない&
トランザクションの掛け方がcoderefをネストで渡しまくる方法しか提供していないので
個人的には気に入らない
ので、作り直そうかなと思ってDBIx::Handlerを作り始めたんだけど、
コネクション管理部分はDBIx::Connectorのコードで全く一切問題ないのでちょっと落ち着くためにペンディング中。

閑話休題

これのメリットはDBIx::Connectorを使わなくても自分でコネクション管理モジュールをつくって
要件にあったコネクション管理ができることです。

例えばバッチ起動したら再接続しないモード。
webの場合は再接続ありモードとか選択できたりなんか。


3は無いです。

2はあるかも。

そんな感じでまだ模索中なのでご意見頂ければと思います。

てことで悩み中です。


TengとDBIx::Skinnyのベンチマークとってみた / teng orm skinny / 2011-01-20 / permalink / Comments このエントリーをはてなブックマークに追加

こんな感じ


また別個でベンチマーク取ってくださった方がいらっしゃいました
http://d.hatena.ne.jp/toorustar/20110119/1295456361


Tengについて / perl teng orm / 2011-01-18 / permalink / Comments このエントリーをはてなブックマークに追加

先ほどTengという新しいORMをリリースしました。
TengはDBIx::Skinnyの後継バージョンと捉えていただいて結構です。


DBIx::Skinnyはおおよそ3年前ほどに一人でつくりはじめたORMで
現在に到るまでに様々な仕様変更を繰り返し、
結構秘伝のタレ的なコードが目立つようになってきました。


元々はDBIx::Skinnyをリファクタリングすることで済まそうと思っていたのですが、
後方互換を残したままのリファクタリングに限界を感じました。
多くの人に使っていただいている現状で後方互換を簡単に捨ててしまうのは
宜しく無いとの判断から別プロジェクトとしてリリースするに至りました。


DBIx::Skinnyは現状、バクレポートも特別なく
問題なく継続してご利用頂けると思いますので、ご安心ください。
また、なにか大きな問題点があれば、サポートしますのでpatches&testsウエルカムです。


さて、Tengを作るに当たっては、
tokuhirom氏とlestrrat氏にご協力頂き、
DBIx::Skinnyよりもシンプルで見通しがよい物が作れたと思います。
それは言葉で語るよりもコードを見てもらったほうが良いと思うので多くは語りません。


DBIx::SkinnyとTengの大きな違いは
・今までクラスメソッド経由でメソッド呼び出しが可能でしたがインスタンスを作って操作するようにした
・Schemaの定義方法が若干かわった
・Schemaを操作するmeta data apiが提供されるようになった
・Schmea::(Loader|Dumper)がコアで提供されるようになった
・triggerの廃止
・find_or_crete/count/bulk_insert/replaceなどの一部メソッドをPluginによって提供するように変更
・PagerをコアのPluginで提供するようにした
・Rowクラスを生成するときにanon classを生成せずにAUTOLOADによりメソッドアクセスできるように変更
・SQLビルダーにSQL::Makerを使用するように変更

と、言ったところでしょうか。

詳細なパフォーマンスの違いなどはまだ計測していませんが、
コードベースで大体DBIx::Skinnyの半分くらいのコード量になったので、
何か内部の挙動を見たい時に悩まされることはないんじゃないかな。


もし、ご意見ご要望などあれば#dbix-skinny@irc.perl.orgやtwitterなどでどうぞです。


それでは今後ともTengをよろしくお願いします。