Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.4

Java⇔RDBのMapping-F ..

263:デフォルトの名無しさん
06/06/14 09:18:08
少なくとも、困ったときに直にSQL書いて実行できるようなフレームワークじゃないと、
使えないなあというか使うの怖いなあ。
まあそのときだけJDBC使えって話はあるけど。

264:デフォルトの名無しさん
06/06/14 10:19:43
Hibernateは問題ないな。

265:デフォルトの名無しさん
06/06/14 10:26:34
>>263
ibatis

266:デフォルトの名無しさん
06/06/14 11:37:06
でも直に書けるフレームワークは、普段から直に書く様に成って、後で困る罠。

267:デフォルトの名無しさん
06/06/14 17:14:33
>>266
そういう開発者、いそうだね。特に新規に導入するとき、わからない→直書きってされそう

268:デフォルトの名無しさん
06/06/14 23:34:39
でもハマった時の最後の手段として、SQLとかJDBC APIとかとも上手く連携してくれるのがいいなぁ。
プログラマとしては逃げたくなくても、サラリーマンとしてそういう手段に逃げちゃう時が多々あるんで・・・・・・。

269:デフォルトの名無しさん
06/06/17 11:50:26
Hibernate3とEJB3、これから作るシステムに入れるならどっちがおすすめ？

270:デフォルトの名無しさん
06/06/17 11:51:43
今までどおりの使い分け

271:デフォルトの名無しさん
06/06/17 11:57:00
ゲームで使えそうなORMはHibernateくらいかい？組み込みたいのでオススメを聞きたい

272:デフォルトの名無しさん
06/06/17 14:51:30
>>269
EJB3を使ってJPAの実装としてHibernateを利用

273:デフォルトの名無しさん
06/06/17 14:52:33
>>271
つうか、これからはJPAという標準になるんだから、ゲームで使うくらいならTopLinkもHibernateも大差なかろう。

274:269
06/06/18 01:32:50
>>270
今までEJBって使った事ないんですが、使い分けってどんな基準ですか？

>>272
なるほどー。
使い分けってよりJPAの実装としてHibernateを選択って感じなんですね。

275:デフォルトの名無しさん
06/06/18 02:45:06
>>274
いままで使ってなかったのはEJB2
EJB3とは別物。
ORマッピング使うなら、EJB3で十分。
実質的にはHibernateの仕様がEJB3になったわけだから、EJB3とHibernateをどう使い分けるかということが、そもそもナンセンスということになる。

276:デフォルトの名無しさん
06/06/18 02:57:00
>>275
リモートで呼び出せるかどうかのみ違う。
使い分けはそこだけかな。

277:デフォルトの名無しさん
06/06/18 03:02:14
JPA仕様とそれぞれのORマッパーって結構違うんじゃない？ Hibernateについては同感だけど。

たとえばCayenneもJPAをサポートするといって準備しているけど、Cayenneの
発想とJPA(Hibernate)のやり方（というか考え方）って結構違うように思う。特に
トランザクションを意識させない設計とか、どうすんだろ、と思う。

TopLink(Grassfishに組み込みのやつ）とかはどうなんだろうか。

278:275
06/06/18 03:47:22
>>277
HibernateもCriteriaとかProjectionとかがEJB3に取り入れられてなくて残念なんだけど、ORマッピングのプログラムインタフェースの部分だけを見ればJPA準拠ならHibernate互換ということになるんじゃないかな、と思ってます。

279:275
06/06/18 03:53:08
>>277
重箱の隅だけど、GlassFishね。草みたいな魚じゃなくて、ガラスみたいな魚。
TopLinkは、JPAの実装として使う限りでは、個性を感じない。
もちろん、どのJPA実装も、JPAの実装として使う限りでは個性を感じないというのは当たり前の話ではあるんだけど。

280:デフォルトの名無しさん
06/06/18 05:50:23
パフォーマンスの差とかあるのかな？

281:275
06/06/18 08:08:21
それぞれの固有の機能を使わない限りは、無視できるほどの違いしかないと思う。
でも実測値がほしかったら、実サーバーで確認するのんが確実

282:デフォルトの名無しさん
06/07/03 23:13:24
Hibernateが特許侵害だとよ。
URLﾘﾝｸ(japan.cnet.com)
>テキサス州の連邦地方裁判所に今週提出された訴状によると、
>原告のFireStar Softwareは、JBossのHibernate 3.0が同社の
>「オブジェクト指向ソフトウェアを用いた、リレーショナルデータベースの
>リンクに関する特許」を侵害していると主張しているという。

283:デフォルトの名無しさん
06/07/04 01:49:42
>>282
特許侵害しているとして訴えられただけだろう。
まだまだ一方的な主張の段階。
「特許侵害だとよ。」は風説の流布に当たるおそれがあるから注意。
断定は判決が出てからに汁。

よくあるアメリカ流のふっかけ・ゆすりと推測してみる。
うまく行けば和解金ふんだくれるもんな。

284:デフォルトの名無しさん
06/07/04 21:10:50
時給１０００円でＪａｖａ教えてくださるかたを募集します
場所　所沢（池袋・高田馬場から直通）

ｉ－ｗａｎｔ－ｔｏ－ｓｔｕｄｙ－ｊａｖａ＠ｈｏｔｍａｉｌ．ｃｏ．ｊｐ
（アドレスは全角で書いてあるので半角に直してください）
よろしくおねがいします

285:デフォルトの名無しさん
06/07/04 23:56:57
>>281
すでに「おい、そのころには既にEOFがあったわけだが。
そのEOFにすら先行技術があるんだが？」と冷静なツッコミが
入っとるよ。

286:デフォルトの名無しさん
06/07/05 05:13:30
BerkeleyDB Java Editionつかってます

287:285
06/07/05 09:03:31
アンカーミスった。
>>282
だった。

288:デフォルトの名無しさん
06/07/10 22:01:42
SimpleORM
URLﾘﾝｸ(www.simpleorm.org)

whitepaperを眺めてみたらいい感じ。
クラスに定義したメタデータからテーブルを作ったりできるらしい。

新規開発にしか向かないかな？

289:デフォルトの名無しさん
06/07/17 21:22:59
教える対象は超初心者です。

専門学校などでJavaを勉強されていて夏休みだけ教えたいという方も歓迎です

290:284
06/07/17 21:28:22
教える対象は超初心者です。

専門学校などでJavaを勉強されていて夏休みだけ教えたいという方も歓迎です

291:284
06/07/17 21:46:20
いきなり缶詰ー＞架空請求スパムの送信

292:デフォルトの名無しさん
06/07/18 01:36:11
亜米利加の特許は先発明制だから、いくらでも先行特許あるよ。

293:デフォルトの名無しさん
06/07/18 03:38:48
>>290 = >>291
自分でマルチして、自分で突っ込んでる

294:デフォルトの名無しさん
06/07/18 18:28:56
HibernateのHQLで select sum(*) の返り値を
IntegerじゃなくてLongで取得したいのですが、いったいどうすれば…

295:デフォルトの名無しさん
06/07/18 20:19:24
>>293
IDも出ない板でよく言うよ

296:デフォルトの名無しさん
06/07/19 01:07:07
>>294
URLﾘﾝｸ(opensource.atlassian.com)
3.2での対応になる

297:デフォルトの名無しさん
06/07/19 02:32:50
>>296
ありがとうございます

丸一日、試行錯誤してしまいましたが
3.2.CR2入れることにします…

298:デフォルトの名無しさん
06/07/22 09:36:29
知らぬ間にこんなの追加されていた。
アノテーションにSQLを書くみたいだが。

URLﾘﾝｸ(download.java.net)

299:デフォルトの名無しさん
06/07/22 11:01:44
BeehiveのJDBC Controlみたいな感じか。

300:デフォルトの名無しさん
06/07/23 02:09:26
俺も同じようなコンセプトの Object/SQL mapper を作っているのだけれど、標準に搭載されるようじゃ用無しだなこりゃ。ｱﾊﾊ
こういうのなんだけどさ。

@SQL(value = "SELECT * FROM dept", bean = Dept.class)
public abstract List<Dept> readAll();

@SQL(value = {
"UPDATE emp SET salary = salary - {#arg[2]} WHERE id = {#arg[0].id}",
"UPDATE emp SET salary = salary + {#arg[2]} WHERE id = {#arg[1].id}",
}, type = TYPE.UPDATE
)
public abstract void moveSalary(Emp from, Emp to, int price);

完成したら公開しようと思っていたのだけれど、微調整したら公開しちゃおう。ｴﾍﾍ

301:デフォルトの名無しさん
06/07/23 09:05:28
>>300
標準のは、CachedRowSetを使っていて、CachedRowSetはJDBCドライバの対応が
必要だから、存在価値としてないわけじゃないと思うけどね。

しかし、どうせなら誰か.NETのDataSetをそのまま実装して欲しいな。
NinjaVAが実装しているけど、DataSetのソースが5000ステップくらいあるのと
微妙に違うので、いまいち使いづらい。

302:デフォルトの名無しさん
06/07/26 23:40:17
>>300
公開期待してます。

303:デフォルトの名無しさん
06/07/28 00:40:27
Hibernate Annotationで質問があります。

簡単なサンプルを作成して実行してみたところ以下のようなエラーが出ました。
Exception in thread "main" org.hibernate.MappingException: Unknown entity: sample.Employee

そこでhibernate.cfg.xmlから<mapping package="sample"/>と<mapping class="sample.Employee"/>
のタグを削除してnew AnnotationConfiguration().configure().addClass(Employee.class)と
したところ問題なく実行できました。

この場合どこが悪くて最初の方法で実行できなかったのでしょうか
使用したライブラリのバージョンは下のやつです。
hibernate-3.2
hibernate-annotations-3.2.0.CR1

304:300
06/07/28 01:33:19
とりあえずサンプルをちゃんと動くようにして、上げました。
BSD License です。

URLﾘﾝｸ(sourceforge.jp)

すいません、ドキュメントが一切ないです。サンプルのソースを見て下さい。

ognlとcglibが必要です。
こちらでは以下のバージョンで動かしています。他で動くかはわからないです。
サンプルを動かすには hsqldb が必要です。1.8.0 を使っています。
　cglib-nodep-2.1_3.jar
　ognl-2.6.7.jar

まだ無い機能、やってないこと
　ログを取る機能
　しっかりしたエラー処理
　HSQLDB以外での動作確認
　ドキュメントを書く
　もっとしっかりしたサンプルを書く
　ソース内のコメント

SQLの中の {#arg[0]} の部分。ここの {} の中に ognl が記述できます。methodの引数が arg という配列に入ってます。

305:300
06/07/28 01:43:02
補足事項
hsqldbで
CREATE TABLE dept (
　id INTEGER NOT NULL IDENTITY,
　name VARCHAR NOT NULL,
　PRIMARY KEY(id)
);
としていて、
INSERT INTO dept (name) VALUES ('name');
としたら、id列に値が自動で入ります。

この時id列に入った値を、取り出してbeanにセットしようとしています。
id列に入った値を取り出す方法が、RDBMSによってマチマチ？なようです。
で、とりあえず、SQLアノテーションのtypeというパラメータで使い分けるようにして、

　INSERTした直後にCALL IDENTITY()とやって、その値をセットする方法を、CREATE_IDENTITY
　PreparedStatementでINSERTしたあと、PreparedStatement#getGeneratedKeysする方法を、CREATE_GENERATE
　INSERTしっぱなしでbeanに値を入れるのを放棄する方法を、CREATE

としてますので、使う人は使いわけて下さい。
IDENTITYを設定した列が2コあったらどうなるんだ？とか、まとまり切っていませんので。

306:300
06/07/28 01:44:30
始めてオープンソースでソフトを公開しました。
ドキドキしています。

307:デフォルトの名無しさん
06/07/28 01:54:41
早速パクって儲けさせていただきました。無料で公開してくれてありがとう。

308:デフォルトの名無しさん
06/07/28 08:15:21
>>304
乙！
と思って、早速いろんなDBで動作確認…と思ったら、
リリース物件もソースコードリポジトリも空っぽですよ？

309:300
06/07/28 08:23:51
俺のアカウントからなら見られるのに……
俺sf.jpの使い方わかってないぽいので、しばしお待ちを……
スレ汚してすいません。

310:デフォルトの名無しさん
06/07/28 09:41:06
>>300
頑張れ。君に期待している。

311:デフォルトの名無しさん
06/07/29 00:47:50
>>300
私も期待しています。
頑張ってください。

312:デフォルトの名無しさん
06/07/29 01:58:50
>>308
DL出来るようになってるみたいだね

313:デフォルトの名無しさん
06/07/30 04:53:44
sfはリリースしてから実際にDLできるまでにラグがあるらしい

314:ストーカー
06/08/03 01:49:49
URLﾘﾝｸ(crudfactory.sourceforge.jp)
こんなんできてるYO!

315:デフォルトの名無しさん
06/08/03 11:29:37
メモリに入りきらないぐらいの巨大なテーブルをSELECTして、一件ずつ処理したいと思っています。
Hibernateを使おうかと考えていますが、ネットの入門を見ている限りSELECTした結果を一気に取得しているようです。
全件一気にオブジェクト化するとメモリが足りなさそうなのですが、こういう用途はJDBC使って1件ずつ取り出した方が良いんでしょうか？

316:デフォルトの名無しさん
06/08/03 11:56:03
1件ごとにSELECTすると効率が悪いから
何十件かまとめてSELECTするよろし。

それにそもそも、巨大なテーブルを全部変更するなら
ストアドプロシージャのほうが圧倒的に効率がいい。

317:315
06/08/03 12:48:31
書き方が悪かったですね、申し訳ないです。
SELECT * FROM TABLEして全件取得して、ResultSet.next()で1件ずつ処理したいって事なんです。
Hibernateの入門ページ見てると、検索結果がListで一気に戻ってきているようだったので。
つまり聞きたいのは、検索結果全件を一気にオブジェクト化するとメモリが足りないので、
検索結果全件の中から1件ずつオブジェクト化して処理できないかな？って事です。

ListのgetやIteratorのnext時にオブジェクト化されていたら問題なさそうなんですか。
って書いてたら聞くより本なり読んでちゃんと理解してから判断した方がいい気がしてきた・・・。

318:デフォルトの名無しさん
06/08/03 13:24:03
>>713
素のJDBCだと一方向に読み込み専用で取得すると
一気には取ってこないみたいだね

319:315
06/08/03 16:36:42
>>318
それをO/RマッピングでやってみたいんですがやっぱJDBC使わないとダメなんでしょうかね。
ふむむ、できないとしたら分割してSELECTするなり工夫が必要かぁ・・・。

320:デフォルトの名無しさん
06/08/03 16:52:08
>>315
Hibernate使ったこと無いけど、lazy initializationを有効にすると
取得したコレクションからオブジェクトを取得するときまで
インスタンス化を遅らせることができるそうだ。
URLﾘﾝｸ(www.hibernate.org)
つうかドキュメント読め。

321:315
06/08/03 17:14:37
>>320
おお、良い感じですね。
問題はいらなくなった読み込み後のオブジェクトがちゃんとゴミ掃除されるかどうかだけど・・・とりあえずいろいろ読んでみます。
㌧クス!!

322:デフォルトの名無しさん
06/08/07 18:33:15
Beanて、テーブル毎に一つ作るものでしょうか？
INSERT目的なら全カラム必要になるだろうけど、
SELECT目的なら一部のカラムのみで十分なケースってあると思うんです。

例：
BOOKというテーブルはID、名前、著者名、カテゴリ情報、概要等、
本に関する情報を多数持っているが、
検索結果に表示するのは名前だけで十分、という場合。

この時ID、名前以外の情報まで持ってくるのは非効率な気がするのですが、
このSELECT目的に別にBeanクラスを定義するというのはアリでしょうか。

class Book { 全カラム }
class BookForSearchResult { ID, 名前 }

それとも、この程度の効率はO/Rマッピングを使用する以上、
気にしない方がいいんでしょうか。

323:デフォルトの名無しさん
06/08/07 19:15:38
>>322
どうしても気になるのなら、IDと名前だけのビューを作って、
そのビューとBeanをマッピングしたらどうでしょう？

324:デフォルトの名無しさん
06/08/08 01:42:02
hibernate使ってたけどいろいろ面倒くさくなってきたのでCommonsDbUtilsに戻してしまった。
なんかすがすがしい気分になった。

325:322
06/08/08 11:09:26
>>323
なるほど、ビューを対象にするなら違和感ないですね。
カラムを限定するようなケースが発生するのは大概検索画面なので、
わざわざビューを作る、というのもアリが気がします。
ありがとうございます。

326:デフォルトの名無しさん
06/08/08 19:12:24
OJB 1.0.4を利用しようと思ってソースとバイナリを取ってきて
動かそうとしているのですが、junit test suiteがFailureを出します。

WinXP (SP1)
JDK 1.5.0_06
lib等は、
antは1.6.5を別途導入。junit.jarはojb1.0.4のをcopy
DBはデフォルトのhsqldb (入手したママ)

でるFailure　(1件のみ)
testReportPathExpressionForExtent2
check size expected:<2> but was:<0>

(その他実行結果のファイルにはNOT_EXISTテーブルがないとかもでている)

OJBのドキュメント等やMLも読んだのですが、junit testについては
(hsqldb)についてはそのまま動くとのことで、どう修正すれば
動かせるのかどうかわからなくて困っています。

ここでいいのかどうかわからないのですが、よろしくお願いします。

327:デフォルトの名無しさん
06/08/09 00:20:58
まだ見てるかわからんが、HibernateならScrollableResultsがある。
ResultSetと同じようなカーソル的な使い方ができるので、
適度にevict()しながら処理すればいいと思われ。

328:デフォルトの名無しさん
06/08/17 18:09:46
正直O/Rまっぱーの利点がわからん。
簡単な表結合ならSQL書いちゃったほうが早いし
難しい表結合はO/Rまっぱーじゃ結局無理だし。
なにがいいのか俺にもわかるように説明してくれ。
DTO自動で作るだけならエクセルマクロで十分だし。

329:デフォルトの名無しさん
06/08/17 18:22:18
そのエクセルマクロ生成コードにむかついた人が張り切ってしまって
できたのがO/Rマッパー。
むかつかない人はそのままでいいよ。

330:デフォルトの名無しさん
06/08/17 18:29:30
＞簡単な表結合ならSQL書いちゃったほうが早いし
ORMの利点は、「SQLを書かなくていい」ではない。

＞DTO自動で作るだけならエクセルマクロで十分だし。
それを「車輪の再発明」と言う。
ダメエンジニアが行う愚行の一つ。

331:328
06/08/17 18:32:31
>>330
で、結局利点はなんなのでしょうか（＾＾；

332:デフォルトの名無しさん
06/08/17 18:35:56
>>329
個人の趣味で使うものってことでしょうか？？
仕事で使うもんじゃないってことでFA?

333:デフォルトの名無しさん
06/08/17 18:42:12
>>331
オブジェクトとSQLのマッピング作業をフレームワークがやってくれる点。

334:デフォルトの名無しさん
06/08/17 18:43:03
>>329のレスから>>332のような結論が出る時点でDQNエンジニア確定だな。

335:デフォルトの名無しさん
06/08/17 18:46:33
ぶっちゃけ俺DQNエンジニアだとおもう。
まっぱーの利点とか理解できないし。
だから教えてくださいお願いします。

>>333
マッピングってDTOつくって、ResultSetから値を取り出してDTOに入れていくってことですか？
ただそれだけですか？
そこでそんなにバグが出たり工数がかかったりしてるんですか？

336:デフォルトの名無しさん
06/08/17 19:01:57
>>335
検索だけじゃなくて、挿入・更新のときのマッピングもね。

DQNかも知れないエンジニアを大量に使わざるを得ないプロジェクトで、
テーブル数が数十個ある場合で、カラムの追加変更などがある場合でも
フレームワークにやらせるよりも手作業の方が早くて確実なら使う必要はないだろう。

337:328
06/08/17 19:10:21
それだけしか利点がないならやっぱ内の会社にはいらないのかもしれない。。
ほんとにそこでみんな困ってるの？？？
そのあたりって仮にまちがえてもテスト段階でバグ発見しやすい部分だと思うし
そもそもDTOに入れたり出したりするのなんてそんなに大変な作業でも
ないとおもうんですが・・・。

うちのシステムもテーブル150ぐらいあるし、
カラムの追加変更もときどきあるけど
一度に追加変更されるのって2、3テーブルぐらいのものだし
それだけのためにxml書いたりといった面倒な作業が
工数的、費用的ににペイするのかしら？？

あたらしいもの好きな人たちが趣味でやってる領域なのでは？
実際に業務に使ってるひといるの？？？

338:デフォルトの名無しさん
06/08/17 19:25:27
XMLファイルを手書きしてたらメリットは感じないたろうね。
トータルの記述量はあまり減らないし、かえって面倒と感じるだろう。
そこは自動生成するところだよ。

339:デフォルトの名無しさん
06/08/17 19:32:14
ORM=XML設定ファイル必須というわけでもない。
S2DAOや、Hibernate Annotation、EJB3はXMLによるマッピング不要だ。

340:328
06/08/17 19:39:49
XMLをテーブル定義から自動作成する工数と
DTOなど自分でコーディングする工数

システム開発全体にかかる工数から比較したら
これらが締めるのは微々たるものでは？

341:デフォルトの名無しさん
06/08/17 19:51:09
＞XMLをテーブル定義から自動作成する工数と
＞DTOなど自分でコーディングする工数

ちがう。
テーブル定義からXMLとDTOとを自動生成する工数と
DTOを自分でコーディングおよびSQLとDTOの値の受け渡し処理の
コードを書く工数とその部分をテストする工数の合計だ。

後者の方が早くて確実なら使う必要はない。

342:328
06/08/17 19:54:00
その2つだけをくらべたら後者のほうが遅くて不確実なんですが
OR mapperに潜んでいるバグのリスクや、
各OR mapperの使い方を覚える工数を考えたら
やっぱ使わないって判断かなあ。
そもそもわざわざ導入したところで削減できる工数が少なすぎるような気が。

あんだけ雑誌やネットで騒がれておきながら
メリットってこんだけなの？
なんかほかにメリットないのかしら・・。

343:デフォルトの名無しさん
06/08/17 19:54:11
そう感じてて、それで本当にいい！　ノープロブレム！
って思うなら、それでいいじゃねえか。

俺はDTOを自分で書くなんて冗談じゃねえが。
Hibernate Annotationでハッピーライフ。

344:328
06/08/17 19:57:38
いや、どう感じるかは問題ではなく
客観的な指標から判断して
どちらが生産性の向上につながるのかが知りたい。

なんでこれだけのものにみんな大騒ぎしてるんだろう？
なんかあるのでは？って思ってしまう。

345:デフォルトの名無しさん
06/08/17 20:02:51
生産性にまともな測定方法なんてﾈｰﾖ
むかつくやり方を続けると、精神衛生に悪くて生産性が下がる。
それだけ。

346:デフォルトの名無しさん
06/08/17 20:35:55
＞OR mapperに潜んでいるバグのリスク
おまいのところがGavin Kingより優秀な開発者を抱えてるならリスクとなり得るなｗ

347:デフォルトの名無しさん
06/08/17 20:47:21
>>345
それは真理だな。

>>344
なんにもないから安心しろ。
頑張って車輪を発明し続けてくれ。

348:デフォルトの名無しさん
06/08/17 21:04:21
>>346
マジレスすると、Kingよりも優秀な奴が一人いてもダメだと思う。
HibernateやS2DAOがどれだけの人に動作検証されているのかを考えると、
それ以上の動作検証ができて、はじめて
「OR mapperに潜んでいるバグのリスク」が自作コードより大きくなると言える。

349:デフォルトの名無しさん
06/08/17 21:37:15
>>348
自作コードの方が普通は仕様が小さいから、
同程度の品質を確保するのにそこまでの動作検証は要らないけどね。

350:デフォルトの名無しさん
06/08/17 22:30:32
ORマッパには、いままでの長い期間で発見されたパフォーマンス
改善手法がデフォルトで組み込まれている。

ORマッパの大部分は関連テーブルのレコードを自動的に取得
できる。

百人がよってたかってデバッグしたコードと、どっかの中小企業が
自分たちのしょぼいプロジェクト用に作って二人か三人でデバッグ
したコードでは、前者の方が信頼性が高い。

ただし１テーブルのデータちょっと取ってくるだけ、しかもテーブル間
リレーションもほとんどない、毎回SQLをコンパイルさせる程度の
負荷などまったく気にしない、とかなら別に使う必要はなし。

351:デフォルトの名無しさん
06/08/17 22:36:31
大量のデータをinsertするような、バッチ的処理には向いてないね。
あくまで、オンライントランザクション処理を簡易化するためのフレームワーク。
万能ではない。

352:デフォルトの名無しさん
06/08/17 23:09:32
まずはテーブルの構造からO/Rマッパー的に作る必要がある。
それができないプロジェクトは、リプレースするか、捨てるか。どっちかしかない。

353:デフォルトの名無しさん
06/08/18 00:54:27
>>328
とりあえず何か動かしてみたりはしたの？
Hibernateなら、ツール使えばスキーマ読み込んで勝手にクラス作成までやってくれるから
一度適当に使って試してみたら？
結局ツール適用のメリット有無なんて、対象システムや開発環境との相性だからな

354:デフォルトの名無しさん
06/08/18 01:31:01
>>176
忘れた頃に禿同

オレもエンティティにビジネスロジックを書きたくなってしまう。
GRASPじゃないけど、OO的に考えるなら、データに近いところへ
メソッドを寄せ集めておきたいんだよな・・・

自動生成されたエンティティをサブクラスするのはちとキモイしねぇ

355:デフォルトの名無しさん
06/08/18 07:19:44
>>176,354
＞自動生成されたエンティティをサブクラスする
ちょっと意味不明だけど

任意のクラスを継承したエンティティを自動生成できるツールがほとんどだよ

356:デフォルトの名無しさん
06/08/18 07:48:13
>>355
クラス継承によるロジック共通化をフレームワーク単位で行うと、クラスの拡張性が著しく損なわれるので
最近は避けられる傾向にある
最近DIコンテナを使った開発で多用されているのが、委譲による疎結合。
その場合はステートレスなロジッククラスが利用される。
これとドメインモデルとの相性がイマイチなのがORマッピング利用時の問題
ORマッパー自体がDIをサポートして、ロジックを委譲するオブジェクトを注入してEntityを作成することが出来れば
ドメインモデルでも疎結合でロジックを構築できるのでは？・・・という話

357:デフォルトの名無しさん
06/08/18 08:00:02
>>356
>>354からそこまで読み取れたらネ申だな。

358:デフォルトの名無しさん
06/08/18 08:42:51
>>176を先に読めよｗ

359:デフォルトの名無しさん
06/08/18 18:56:37
iBATIS2.2.0(β)

360:デフォルトの名無しさん
06/08/19 00:12:40
あれ？
iBATIS2.2.0って、ストアドプロシージャと
Beanとのマッピング出来るようになったん？

361:デフォルトの名無しさん
06/09/05 02:43:56
ついに1000体突破かよ
アイロボットみたいだな
株ロボもいつか夢を見るようになるのかなぁ

362:デフォルトの名無しさん
06/09/06 11:11:38
貼っとく
[ThinkIT] 第7回：それぞれのメリット／デメリット (1/3)
URLﾘﾝｸ(www.thinkit.co.jp)

363:デフォルトの名無しさん
06/09/08 15:08:40
質問なんですが
Hibernateでsessionキャッシュ上の永続オブジェクトに対して
オブジェクト単位での変更チェックは出来ないんでしょうか？

bool Session#isDirty(Object o, ...)みたいなものがあればいいのですが...

364:デフォルトの名無しさん
06/09/26 00:45:24
キましたね。iBATIS。

ストアドプロシージャとBeanのマッピングOK。
サンプル書いて確認とれました。

sqlMap.queryForObject(query, map);
ArrayList list = (ArrayList)map.get("out");

for(int i=0; i<list.size(); i++){ Bean bean = (Bean)list.get(i); bean.getId();}

SpringFrameworkと連携するときは使えないかもしれないけどね。
とりあえず、Map（HashMap）->ArrayList->Beanの順に格納されているので、
１コ１コ取り出さないといけないのがメンドイ。

つーか instanceofで確認取らせんな！( ﾟДﾟ)ｺﾞﾙｧ!!

365:デフォルトの名無しさん
06/09/26 01:16:45
あいばてぃす？
あいべいてぃす？

366:デフォルトの名無しさん
06/09/26 01:26:28
いーばてぃす

367:デフォルトの名無しさん
06/09/26 01:36:02
URLﾘﾝｸ(ibatis.apache.org)

ここ読むと

>We pronounce it: eye-BAT-iss

ってあるから、あいばってぃす？

368:デフォルトの名無しさん
06/09/26 02:22:18
シンクイットって登録しないと読めないから資料価値ない。
グーグルキャッシュに入らないマイコムにも言えるが。

エクセルマクロ生成コードにむかついた人が張り切ってしまってできたのがO/Rマッパーなのはいいが、漏れはO/RマッパーのXMLファイル作成にムカつくのはどうすれば良い？
誰かエクセルマクロからXML生成するツール作ってない？
つーかxlsファイル自体を読み込んでO/Rマッピングしてくれってのが、.NETのノリ？

369:デフォルトの名無しさん
06/09/26 02:44:42
＞誰かエクセルマクロからXML生成するツール作ってない？
当然みんなつくってんじゅねぇーの？
一々仕様書から写す手間を考えるとそりゃマクロで吐き出させるだろうし。

こういうのってオープンソースで一個作っちゃったほうがいいよーな気もするよな。

370:デフォルトの名無しさん
06/09/26 08:09:54
作ったらOSSとして公開でいいんじゃない？w

371:デフォルトの名無しさん
06/09/26 13:10:33
ソースはどこにうpされてるの？

372:デフォルトの名無しさん
06/09/26 20:32:49
会社で作ってて、パッケージ名までcom.なんとかになってるから、
さすがに公開はできんわｗ

373:364
06/09/26 21:23:18
SpringFramework + iBATIS でのPL/SQL連携を確認。

つーかさ、DBの問い合わせから戻ってきた値が
<parameterMap>のclass要素のオブジェクトにマッピングされるのはいいんだが、

public List findList(String query, HashMap map)throws DataAccessException
{ return (List)getSqlMapClientTemplate().queryForList(query, map); }

↑のコードの意味無いじゃん。↑のメソッドを ArrayList list = (ArrayList)dao.findList(query, map);
で呼び出すんだけど、結局引数に渡したmapオブジェクト変数に格納し直されるっていう動作はどーなのよ。
いいの？これ。

どーいう意味かの解説は URLﾘﾝｸ(canetrash.seesaa.net) にあるんだが、動作的にねぇ…？
結局引数に渡したmapからListを取り出して、さらにBeanを取り出して…。

メンドクサーですよ。O/R-Mapperってこんなんなん？いや、動作的にはO/R-Mappingなんだろうけどさ。
識者コメント＆ツッコミ・キボンヌ。

374:373
06/09/26 21:46:39
あー、でも URLﾘﾝｸ(www.h7.dion.ne.jp)
見ると

--------------
sqlMaps で SQL を実行する時のパラメータとして使えるクラスには次のものがあります。

・Bean
・Map
・プリミティブクラス（Integer など）
--------------

ってなってるから、だめだ。Map or Beanじゃないと。orz

375:デフォルトの名無しさん
06/09/27 07:55:54
O/Rマッパーじゃないけど、RailsのMigrateみたいなDBのバージョン管理できるJavaプロダクトって何かありますか？
あーゆーの欲しい。

376:デフォルトの名無しさん
06/09/29 01:08:11
>>368
blancoDb だろ。Excel O/R マッパー。
俺はそれを作ってる、いがぴょんっていう奴の顔がキモすぎて
試してもない。違うんかもしれんが。

377:デフォルトの名無しさん
06/10/07 04:01:15
やっぱHibernate最高ですよね？
うちの会社に導入しようと思っています。
いまどきＪＤＢＣでＳＱＬ直書きなんて氏ねばいいと思います。

378:デフォルトの名無しさん
06/10/07 04:23:21
導入前に氏んでいるわけだな。

379:デフォルトの名無しさん
06/10/07 08:56:57
>>377
Hibernateがいいときもあるし、JDBCでSQL書きがいいときもあるし、iBatisがいいときもある。
最高ではない。

380:デフォルトの名無しさん
06/10/07 09:48:02
まあいまどきJDBCのようなところはとりあえず入れたほうがいいな。
見聞を広げるちゅー意味でも。

381:デフォルトの名無しさん
06/10/07 11:13:58
同意。
Hibernate最高とか言っちゃわない程度には触っておいたほうがいいな。

382:デフォルトの名無しさん
06/10/07 11:46:24
適材適所。「最高」なんてものは無い。

383:377
06/10/08 10:47:35
いや、Hibernateは上級レベルの達人たちが
ものすごい工数をかけて作成したフレームワークだ。

Hibernateありきだ。

最初に。

もちろんHibernateではダメだというケースも
あるとは思うが、まずはHibernate最高と思っておいて
問題ないのでは？

384:デフォルトの名無しさん
06/10/08 11:14:28
JDBC APIだって上級レベルの達人たちが
ものすごい工数をかけて作成した仕様なのだが・・・

385:デフォルトの名無しさん
06/10/08 11:25:44
妄信してる信者の発言にしか聞こえない。
結局はどれが良いのか客観的に語ってよ。

386:377
06/10/08 11:26:36
いや、Hibernateも内部でJDBCを使っている。

どんなシステムでも大抵、JDBCを利用するための
フレームワークを作っているだろうが、
そういうフレームワークとしてHibernateに
勝てるわけがないということだ。

387:デフォルトの名無しさん
06/10/08 14:01:29
うちなんてHibernateどころかServletすら使えないよ
DBまわりはWrapperがあるけど
BroadVision6...

388:デフォルトの名無しさん
06/10/08 14:15:17
＞そういうフレームワークとしてHibernateに
＞勝てるわけがないということだ。

すげぇ盲信っぷりにﾜﾛﾀ。

389:デフォルトの名無しさん
06/10/08 18:44:47
まあ言い方はあれだけどｗ、
日本の会社が自社で作っていたものとは次元が違う存在というのは言うまでもない。
すべてのケースに適しているとはいえないが、
使ったこともないじゃORマッパーを語れないな。

俺はjar（というか使ってるクラス）があまりにも多すぎるところがいやだな。
入れたら起動も死ぬほど重くなるし、OutOfMemoryにもなりやすい。
サーバーにいくつもHibernateを使ってるWebAppがあったら目も当てられない。

390:デフォルトの名無しさん
06/10/08 19:11:56
そんな貧相な鯖で Java を動かすこと自体が間違ってる。

391:デフォルトの名無しさん
06/10/08 23:17:11
フレームワークは目的ではなく手段。
無駄な残業したくないなら要件にフィットするものを選ぼう。
冷静に、冷静に。

392:デフォルトの名無しさん
06/10/09 01:04:59
あれこれ選び分ける程の余裕もスキルもありません。
可能な限り「標準」で行きたいのだけど。

JPAはしばらく安定しないだろうなぁ・・・

393:デフォルトの名無しさん
06/10/09 03:36:02
>>386
Hibernate に詳しいようだから、使ってみた感想でいいから
他のいくつかの O/R マッパーと比較して何かいいか
教えてくれないか？

俺には何がいいかさっぱり分からんので。

394:デフォルトの名無しさん
06/10/09 04:56:36
まずいエサだがスレの内容には沿ってるな＞393

Hibernateのよさは、資料が多いことだな。

俺はCayenne > Hibernateだと思う。複雑なクエリを
HQLで書くのは俺には無理。

395:デフォルトの名無しさん
06/10/09 05:56:46
>>393
質問がO/Rマッパーの有用性は

396:デフォルトの名無しさん
06/10/09 06:29:22
ごめん、途中で送信した

O/Rマッパーの有用性はわかるけど、Hibernateの優位性がわからないのか
O/Rマッパーの有用性がわからないのか、どっちなんだ

前者ならJPA実装の中でも枯れてるしData Mapperパターンでは決定版に近いってレスになるし、
後者なら、そうですねってレスになる

397:デフォルトの名無しさん
06/10/09 11:29:44
O/R マッパー自体の有用性が分からない、つーのはスレ違いじゃね？

有用性があるのが前提で、優劣を議論するのがスレの趣旨じゃね？

398:デフォルトの名無しさん
06/10/09 19:50:13
>>397
適用範囲を把握するという意味では、
有用性自体を問うのもありだと思ふなり

399:デフォルトの名無しさん
06/10/14 10:05:46
ド短期製造、お前らなら何使う？
製造期間 10 日、マスタメンテ 3 機能。
DB 設計済み（複合キー）、検索条件は可変多し。
製造担当はたぶん JDBC 直以外知らない。
学習工数、製造工数の少なさを最優先。

JDBC 直、Hibernate、iBatis、DBUtils、、、

400:デフォルトの名無しさん
06/10/14 10:20:46
＞製造担当はたぶん JDBC 直以外知らない。
＞学習工数、製造工数の少なさを最優先。

10日間に学習工数も含めるのなら、断然JDBC直。

フレームワークは学習コストがそれなりにかかることを
認識しておかないと痛い目を見る。
それを認識できてない奴が「生産性が低い」と騒ぐんだ。

強いて何か覚えるなら、ORMよりもDbUnitでも覚えておいた方がいいんじゃね？

401:デフォルトの名無しさん
06/10/14 14:16:27
>>399
MS Access

402:デフォルトの名無しさん
06/10/14 14:50:21
短期なのに学習コスト込み？てか１０日？
ギャグのつもりじゃなかったらやめたほうがいいだろう。

403:デフォルトの名無しさん
06/10/14 15:28:56
>>399
JDBC 直

404:デフォルトの名無しさん
06/10/14 16:47:16
JDBC直よりは、closeし忘れとかを防止する意味で、
DBUtilsの方がいいんじゃない？
まあ、10日であることを考えたらJDBC直でもいっか。
悩んでいる暇があったら、早くやれって感じだ。

405:デフォルトの名無しさん
06/10/14 17:31:45
JDBC直でResultSetMetaDataとDatabaseMetaDataをひっぱって
全テーブル同じクラスで処理する。

406:デフォルトの名無しさん
06/10/14 18:07:12
>>399
JAVA止めて、お前がLLで作る

407:デフォルトの名無しさん
06/10/14 23:48:22
仮に実装担当者が「色々とORM知ってます」と言ってきても
ちょっとしたもんならJDBC直（or 学習コストがかからん DbUtils）で十分。
後々メンテ担当者がチェンジする時のリスクも小さかろう。

408:デフォルトの名無しさん
06/10/14 23:57:44
>>400
DbUnit も知らんとか言ってたな。
一応、俺が Struts 上にアクセス制御、セッション管理、ログ、エラー制御あたりの
共通部を 2 日ぐらいで俺が作って後は任せようかと思ってる。
Click か Wicket も考えたけど 10 日じゃこわいんでやめとこうと思ってる。

>>402
俺はフリーで複数案件やってて60 万で案件とろうとしてるだけだ。
60 万ぽっちじゃ、10 日ぐらいでやらんと割りにあわんだろ。
部下の勉強がてらに良いと思ったんだけど意見を聞きたかった。

>>404
JDBC 直で close し忘れ防止は Session in View パターンで
ServletFilter でも作るわ。

>>405
結果は Map に格納すんの？リフレクションで Bean？
昔作ったような気もするけど、それだったら何かあるやつ使うかなー。

409:デフォルトの名無しさん
06/10/15 00:08:49
>>408
勉強がてらなら、もっと納期が厳しくない案件でやらせた方がよくない？
確実に作らせたいのなら、担当のスキルと日程をふまえて指示する側が見極めないとな
あと、DbUtilsにするんなら、1.0は色々問題があるからdevelop版を使ったほうがいい。

410:デフォルトの名無しさん
06/10/15 00:33:13
可変長の引数が可能ですが、引数取り出しの扱いがわかりません。
function! AllRead(...)
while args
r args
endwhile
endfunction
どうすればいいでしょうか？

411:デフォルトの名無しさん
06/10/15 00:50:59
>>409
thx。DbUtils か JDBC にするわ。

412:デフォルトの名無しさん
06/10/15 00:52:05
>>410
何のハナシをしているのかわかりません

413:デフォルトの名無しさん
06/10/17 13:36:28
Hibernate 3.2.0 GA
Hibernate Annotations も Hibernate EntityManager も同時に 3.2.0 GA

414:デフォルトの名無しさん
06/10/17 18:53:38
ガッはなんだガッは

415:デフォルトの名無しさん
06/10/17 23:30:51
Generally Available

416:デフォルトの名無しさん
06/10/18 00:07:08
>>414
ぬるぽ

417:デフォルトの名無しさん
06/10/22 21:05:50
以前ibatisで使った開発のときテーブルごとのクラスに結果を詰め込むようにしてたんだけど
結合テーブルのSQLなんかのとき都度それにあった結合テーブルクラス（必要なカラム以外もすべて定義）を使って結果を返していた

つまり結果は絶対SQLのと同じ表形式だったわけなんだけど
普通そういう設計するの？

418:デフォルトの名無しさん
06/10/22 21:10:26
複合キーのテーブルの場合代理のキーを作ってDB設計したほうがHibernateとかでは使いやすい
と同僚が言ってた。代理キーはシーケンスで振っていくようにするといってたけど
そうすっと一意制約が保障できないような気がするが、回避方法あるのかい？

419:デフォルトの名無しさん
06/10/22 21:19:31
>>418
UNIQUE制約ってしってるか？

PRIMARY KEYとは別にUNIQUE制約をかければいいだけだよ。

420:デフォルトの名無しさん
06/10/22 22:18:09
>>419
そりゃそうだ。なんできずかなかったんだろ。ありがとござんした

421:デフォルトの名無しさん
06/10/22 22:18:15
>>418
一意になるように代理キーで、作るべきだと思うけど。

422:デフォルトの名無しさん
06/10/22 22:19:52
ああ、勘違いした。複合キーが一意であることね。
ごめん

423:デフォルトの名無しさん
06/10/22 22:23:01
>>417
例えば、どうなってほしいの？
クラスを作るのが面倒ならば、Mapを使ってもよいと思うが、そうなるとタイプセーフではなくなる。

424:デフォルトの名無しさん
06/10/22 22:56:42
>>423
あーたとえばですね、親子関係のテーブルなんかの場合
親テーブルクラスに、子テーブルクラスを保持するフィールドもたせて
クエリーの結果をそういう感じで保持すんのかな？とおもって。

425:デフォルトの名無しさん
06/10/25 23:30:26
Hibernate で直に SQL 発行して結果を
Map のリストで受け取ることってできますか？

Hibernate を使わなければならず、
でも結果は Map で返さんとだめで、
entity クラスも作成できないんです。

426:デフォルトの名無しさん
06/10/25 23:31:47
保守

427:デフォルトの名無しさん
06/10/26 00:59:39
>>425
たぶん駄目じゃない。
Spring使ってるならJdbcTemplate。ないならDbUtilsでごまかしとけば。

428:デフォルトの名無しさん
06/10/26 01:38:43
>>427
助かりました。
JdbcTemplate#queryForList
でごまかせるような気がします。

429:デフォルトの名無しさん
06/10/26 02:16:00
>>425
Mapによるマッピングには対応している

URLﾘﾝｸ(www.hibernate.org)

430:デフォルトの名無しさん
06/11/02 00:22:59
dbutils 1.1 ってまだ開発中？
使いたいのだけど、1.0はだめだって聞いたんだけど。。
他のがいろいろでてきたからもう開発ストップしてるんかな。

431:デフォルトの名無しさん
06/11/02 02:12:45
>>430
dbutils、シンプルで使いやすいから愛用してるんだけど
あんまり使ってる人いないのかな？

432:デフォルトの名無しさん
06/11/02 03:48:26
何故だか各種ORMと比較されてショボイと思われてる感はあるかも。
個人的にはQueryRunnerがPreparedStatementを
基本、隠蔽する方向になってるのが何だか惜しいって印象。
まあ、そうしてもらうと楽な面も、もちろんあるんだけど。

433:デフォルトの名無しさん
06/11/03 02:24:54
>>431
俺も愛用している。
設定ファイルいらずだし、MapListHandlerの結果をJSP内のELで使うと超ラクで気に入ってます。

434:デフォルトの名無しさん
06/11/03 08:33:31
dbUtils、いいんだけどBeanHandler使うときのフィールド名とプロパティの
マッピングが普通とちがうのがちょっとなぁ。あれは直してくれんかな。

435:デフォルトの名無しさん
06/11/03 14:55:01
>>434
普通と違う？

436:デフォルトの名無しさん
06/11/03 18:02:24
booleanのときとか？

437:デフォルトの名無しさん
06/11/03 21:53:02
>>434
フィールド名/プロパティ名が2語以上から成るとき、DBでは通常アンダースコア連結、
Javaはキャメルケースで表記するでしょ？
他のORMにはそこを変換してくれるものもあるけど、dbUtilsは単にcase-insensitiveで
比較するだけだから、

SELECT ID_DATA AS IDDATA

とか、

public void setId_Data() {

とか書かないといけない。

438:デフォルトの名無しさん
06/11/03 22:48:00
DbUtilは、キャッシュも遅延ロードも無いし、
commons BeanUtilsのリフレクション使いまくりだから、目に見えて遅い。
大規模・高負荷なシステムでは使えない。

けど、シンプルで俺は好き。
自社のお問い合わせ送信フォームとか、
小規模なマスタメンテとかで使ってみたことがある。

439:デフォルトの名無しさん
06/11/03 23:38:04
ORM使ったこと無いので教えてください。

DbUtils以外のORMはリフレクションを使わずに、Beanにどうやって格納したりしているの？
キャッシュが高速なのは分かるのですが、逆に古いデータを読んでしまうことにならないかも気になります。

440:デフォルトの名無しさん
06/11/03 23:53:58
>>439
キャッシュとDBの同期化をどうするかというAPIも用意されている場合も多いので
アプリケーション側でも制御できるし、デフォルト設定も変更可能な多い。

リフレクションを使わず、バイトコードをゴニョゴニョしたりするフレームワークも多い。

441:デフォルトの名無しさん
06/11/03 23:57:27
>>439
＞キャッシュが高速なのは分かるのですが、逆に古いデータを読んでしまうことにならないかも気になります。
何か勘違いしてるんじゃないか。

442:デフォルトの名無しさん
06/11/04 00:37:41
>>440
バイトコードを変えることで、リフレクション使わずにセットしてたりするのか。
それは知らなかった。かなり高度なことをしているんだな。

>>441
こう考えているんだけど、勘違いしてると思った点を教えてくれれば幸い。

キャッシュを使えば、DBにアクセスすることなく、取得済みのデータを再利用するので、高速だと思っている。
「古いデータを～」と思ったのは、データがすでに更新されたのに、
更新前のキャッシュデータを使ってしまうことがないのか？ということを気にしている。

なんか間違ってるだろうか。

443:デフォルトの名無しさん
06/11/04 00:42:51
＞「古いデータを～」と思ったのは、データがすでに更新されたのに、
＞更新前のキャッシュデータを使ってしまうことがないのか？ということを気にしている。
ここの意味がよくわからん。
ひょっとして、複数のサーバでそれぞれ同一DBに対して
接続するとか、そういう使用法を考えてるわけ？

444:デフォルトの名無しさん
06/11/04 01:01:50
>>438
DbUtils から BeanUtils への依存関係はないんじゃない。

445:デフォルトの名無しさん
06/11/04 01:04:14
>>443
>>444じゃないけど、普通は考えるでしょ。

446:デフォルトの名無しさん
06/11/04 01:07:56
>>444
すまん。勘違いしていたらすい。
リフレクションAPI直叩きだね。

447:デフォルトの名無しさん
06/11/04 01:07:56
複数のサーバとは限らないけど、1つのDBに対して、複数の接続が発生するのが普通では？

キャッシュってのは、DBの複製的な情報を、アプリ側で保持するわけでしょ。
検索→キャッシュ生成→（他スレッドなどがDB更新）→キャッシュの値は更新前の値のまま
もちろん、ORMを使わず更新するとかが、論外なのは分かっているけど。

ここまで書いてきて気づいたのだけど、
1つのDB接続セッション内で、キャッシュされるのかと思ったけど、
全体でキャッシュを共有して持っているということ？
それならば、「更新前のデータを見ない」という意味は、理解できる。

448:デフォルトの名無しさん
06/11/04 01:30:13
そもそも>>443みたいな設計がおかしいんじゃないか？
それともEJBのことを指しているのか？だとしたら意味が違うと思うが

449:デフォルトの名無しさん
06/11/04 01:31:24
＞検索→キャッシュ生成→（他スレッドなどがDB更新）→キャッシュの値は更新前の値のまま
　　　　　　　　　　　　　　　　　~~~~~~~~~~~~~~~~~~~~~~~
これ何よ。こんなことするなよ。

450:デフォルトの名無しさん
06/11/04 01:34:37
アノテーション使えるDbUtilsが欲しい…

次ページ