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

Java⇔RDBのMapping-F ..

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が欲しい…

451:447
06/11/04 01:39:13
>>449
えーと、シングルスレッドで、順番に更新しないと駄目という意味？？

452:デフォルトの名無しさん
06/11/04 01:44:57
Hibernateのキャッシュは2段階になってる
1次キャッシュ(Session)は一つのスレッド・トランザクションに閉じてる
自分でアクセスしたエンティティを再利用するだけだから遅延はない

2次キャッシュは複数のスレッド・トランザクションで共有されて実装を選択できる
2次キャッシュの実装に分散キャッシュを使えば複数のプロセスでも共有できる
遅延に関しては実装次第
一定時間でリフレッシュするのもあれば他プロセスから更新通知を受けるのもある
分散ロックや分散トランザクションをサポートしたものもある
当然遅延とパフォーマンスはトレードオフだから用途に合わせて実装を選べばよろし

453:デフォルトの名無しさん
06/11/04 02:00:11
>>451
そうじゃねーべ。
Hibernateでも何でもいいから一旦勉強してくれ！

454:447
06/11/04 02:06:22
>>452
なるほど。
1次キャッシュなら、遅延は無いものの、キャッシュとしての効果は薄いと思うし、
2次キャッシュは、どうしても遅延が発生するだろうと感じていたのです。
キャッシュを利用して高速になるからといって、やはり遅延することを無視できないわけですね。

>>441の話だと、遅延があり得ないように、聞こえたので疑問に思っただけです。

>>453　ごみんなさい。勉強しときます。

455:デフォルトの名無しさん
06/11/04 02:13:46
だから、Hibernateのデフォルト設定では
更新前に一旦SELECTして同期するようになっている。

DBを他システムからも操作されることが想定される場合には
SELECTを含むクエリ発行のたびに毎回キャッシュと同期化するようにもできる。

他システムから操作されないのなら、キャッシュを最大限に利用する設定にすることも出来る。

456:デフォルトの名無しさん
06/11/04 11:04:04
>>438

リフレクションやっぱ遅いのか。
ユーザ数の少ない業務アプリケーションしか作ったことないから、
SQL以外の速度気にしたことないな。。

457:デフォルトの名無しさん
06/11/04 11:10:57
気にすることないよ実際。
>438はまともにプロファイリングしたことないかな？
相当いびつな使い方をしない限り影響はない。DBのそれと比べると誤差の範囲。

458:デフォルトの名無しさん
06/11/04 12:31:30
なんか Hibernate ＆ DbUtils なモードだな。

DbUtils だけど、キャッシュはともかく、遅延ロードが無いことに関しては
ナマSQLを書く以上、SQLの書き方／コーディング次第な所なんで
大規模・高負荷なシステムで使えんって理由には直結しないんじゃないかな。

459:デフォルトの名無しさん
06/11/04 14:10:33
>>457はdbUtilを使ってまともなアプリを作ったことが無いのだろうか。

460:デフォルトの名無しさん
06/11/04 16:02:20
大規模・高負荷とか言ってるけど、逆にそういう用途にHibernateとかのORMは
使うのを躊躇するけどな。
キャッシュがあるといっても、このレベルじゃ到底信用できないし。

実際そういうところに使っている人いる？

俺の場合、パフォーマンスが必要なところでは基本JDBC直、得失を考慮したうえで
問題ない部分ではdbUtilsを使って楽をしてもいいかな、という感じ。
Hibernateを使うのは、パフォーマンスをあまり気にする必要がないところで
ちょっと複雑なデータを永続化したい場合だな。

461:デフォルトの名無しさん
06/11/04 16:26:06
今のHibernateはEJBの実装。
大規模システムでの利用を前提にしたプロダクトだと思うけど。

462:デフォルトの名無しさん
06/11/04 16:42:50
元々EJBは大規模つぅか分散システムのアーキだしなあ。
パフォーマンスクリティカルな案件じゃ
JDBC直（＋軽いラッパ）が実状じゃなかろうかと

463:デフォルトの名無しさん
06/11/04 21:51:05
一口に大規模高負荷と言っても、同時多アクセスのWebシステムなのか
大量データ一括処理のバッチなのかで大きく違うよね
前者ならHibernateの２次キャッシュが活用できそうだし
後者はやはりJDBC直書きか（というかストアド使えるならそっち使った方がいいかも）

>>462
分散前提のEJB2と分散前提ではなくなったEJB3は大きく異なる。
更に、EJB３からも独立したJPAは分散とは無関係

464:デフォルトの名無しさん
06/11/04 23:04:37
Hibernateにはバッチは向いてないの？

465:デフォルトの名無しさん
06/11/04 23:05:40
うちの会社でHibernateか、Torqueか、iBatisか、JDBC直を
検討しているんだけど、どれがいいの？

個人的には
通常：Hibernate
バッチ、複雑なＳＱＬ:JDBC直

かなあ

466:デフォルトの名無しさん
06/11/04 23:17:23
>>464
バッチには向いてないだろうね。

>>465
あなたの見解は正しいと思う。
Torqueは論外。

467:デフォルトの名無しさん
06/11/04 23:27:07
>>449
Webアプリなんかじゃ、ふつーに別スレッドに更新されることが、あるんじゃねーの？

468:デフォルトの名無しさん
06/11/04 23:47:26
>>467
遅いし、馬鹿だし、救いようがないな

469:デフォルトの名無しさん
06/11/04 23:48:32
>>467
あるよね。

470:デフォルトの名無しさん
06/11/04 23:49:05
>>465
自分で選べないくらいプロダクトの特性を理解してないなら
どれを選んでも失敗する

471:デフォルトの名無しさん
06/11/05 00:14:54
煽ってるだけだから気にすんな

472:デフォルトの名無しさん
06/11/05 00:53:17
しかし、なんだ。
バッチ系にもWEB系にも使えるものてのは、ありそうでないもんだな

473:デフォルトの名無しさん
06/11/05 01:04:43
万能ってのは無いよ。数あるフレームワークを適材適所で使うのが現実的。

474:デフォルトの名無しさん
06/11/05 05:12:40
うちでは、勉強するってモチベーションが低いのか、ちっともHibernateや他ORMが受け入れられない。
複雑なクエリ文を、しこしか書いている人たちに、HQL使えって言うのは厳しいし、
無理して使ってもらうこともないんだけど。

Hibernate最高って人は、
（実行パフォーマンスに目をつぶっても）開発側が楽だから？
それとも、（開発は多少面倒になるが）実行時に効果的だから？
もしくは、その両方？

475:デフォルトの名無しさん
06/11/05 07:38:32
今からHibernateのAPIやHQLを覚える必要はほとんど無い。
JPA/JPQLを使えよ。

476:デフォルトの名無しさん
06/11/05 15:30:26
開発効率も品質もそれなりの前提知識・意欲を持つ人が集まることで
ある程度保障されるものだし、何とも言えないんじゃ。

ただ、コンパクトなJDBCラッパだけで色々な案件を
問題無く捌けてりゃ、それはそれでハッピーだとは思う。

477:デフォルトの名無しさん
06/11/05 19:30:17
>>474
実行パフォーマンスについては、上手く作ればWebアプリ等では逆に早くなることもある。
開発に関しては、たしかに覚えることは多いが、
リスナーを使ってDBのトリガーみたいな処理をプログラムを使って書けたりとか、
あとは特に排他制御実装が非常に簡単になるのが嬉しい
SQLも使えるから、難しいところは無理にHQL使わずに積極的にSQL使えばいいし
（FROM句への副問い合わせやUNION以外はだいたいHQLで書けるけど）

478:デフォルトの名無しさん
06/11/05 19:36:19
たとえば、よくあるWebアプリの一覧検索から１件選んで更新処理とかする画面だと
一覧を取ってくる所は複雑な問い合わせ文になることが多いから
SQLをORMに投げて結果をBeanのListで受け取る。
１件選ぶ処理では主キーを渡してORMでEntityを受け取る。
そこから先はORMの機能だけで関連Entityを取って来たり、
排他制御しつつ更新処理とか全部やってくれる。

479:デフォルトの名無しさん
06/11/05 20:09:47
排他制御ってSpringやSeasarといったDIコンテナに
任せるものと違うの？

480:デフォルトの名無しさん
06/11/05 22:28:55
SpringやSeasarがテーブルのバージョンカラム定義や、
更新時の自動バージョンカラムチェックとかやってくれるのか？ｗ

481:デフォルトの名無しさん
06/11/05 22:37:53
トランザクションかとおもたｗ

482:デフォルトの名無しさん
06/11/06 00:30:31
比較的S2DAOが、バッチもオンラインも対応しやすい。
Seasarのリスクを受容出来るなら、S2DAOと必要に応じてストアドあたりが、
いい感じだな。

483:デフォルトの名無しさん
06/11/06 10:24:17
ibatisにsqlをフォーマットするクラスはありますか？

484:デフォルトの名無しさん
06/11/06 17:20:38
プリペアードステートメントの「?」にサブクエリーなどのＳＱＬを書いても
ＳＱＬではなく短に文字列として処理されるのでしょうか？
さらにibatisは$xx$はプリペアードステートメントの「?」で、#xx#はＳＱＬとして展開ですよね？

485:デフォルトの名無しさん
06/11/11 21:23:42
hibernate 3.2
hibernate annotation 3.2
hibernate tool 3.2
Eclipse 3.2

な環境でPOJO(アノテーション付き)からその他もろもろを生成したい。

486:デフォルトの名無しさん
06/11/12 08:41:06
>>485
今普通にそれでやってる。その他もろもろってDDLくらいしかなくね？
とりあえずHibernateのサイト見ればできるようになんだろ。

487:デフォルトの名無しさん
06/11/12 08:46:53
そういやDdlUtilsってアプリ組み込みDB初期化に便利そうなんで
早くリリースされないかなぁ。

488:デフォルトの名無しさん
06/11/18 13:49:05
sqlを見やすいようにフォーマットしてくれるクラスありますか？
ibatis、dbutils何でもいいのですが・・

489:デフォルトの名無しさん
06/11/19 11:55:54
一口に見易いと言っても好みがモロに出る所だと思うが、
とりあえずカンマの前後で改行入れる程度のものなら
自分ででっち上げる方が早い気もする。

490:デフォルトの名無しさん
06/11/19 14:14:39
そういうツールはいくらでもあるじゃん。

491:デフォルトの名無しさん
06/11/20 04:29:31
MySQLにテーブルをいくつか作って、
Hibernate Toolsを使って.hbm.xmlと.javaを自動生成させた。

one-to-oneになって欲しい部分がone-to-manyになっている。

困った。

492:デフォルトの名無しさん
06/11/20 10:00:20
>>490
すいません。ツールは知っているのですが、管理者からＰＧ側から整形済みをログで吐き出せといわれていまして・・・

493:デフォルトの名無しさん
06/11/20 10:16:39
管理者ならログ整形するツールくらい用意しろよと言い返せ。

494:デフォルトの名無しさん
06/11/20 18:45:26
Hibernateなら整形出力あるんだけどね

495:デフォルトの名無しさん
06/11/20 18:57:18
>>492
その自称管理者がクソ

496:デフォルトの名無しさん
06/11/27 01:29:48
WebアプリでHibernateを使うとき、updateて普通どうやるんですか？
マニュアルとか見ると、一般的なやり方として
load -> データ変更 -> update
しかないみたいなんですがWebアプリだとloadとupdateの間に
画面遷移が入るのが普通ですよね.

・最初にloadしたデータをセッションにでも入れておく
・updateのときにもういっかいloadする
・loadはせず、自分でオブジェクトを生成してidや全てのプロパティを手動で設定

どんなふうにやるもんなのでしょうか.

497:デフォルトの名無しさん
06/11/27 01:33:40
・最初にloadしたデータをセッションにでも入れておく
の後、データを再度トランザクションにくくりつける。
・updateのときにもういっかいloadする
は、勝手にやってくれる。

498:デフォルトの名無しさん
06/11/27 01:38:35
>>496
前の画面で取得したEntityをsessionなどに保持しておいて
Session（Hibernate Core）使うならupdate
EntityManager(Hibernate EntityManager）使うならmerge

手動で再loadとかすると、排他制御をHibernateに任せられなくなるので
お勧めできない

ちなみに、同一トランザクション上なら、取得したEntityは
値を変えるだけでUPDATEされるので、updateメソッド使う必要はない
ここを間違ってupdateメソッド使うかのように書いてる本が多いので、騙されないように

499:496
06/11/27 03:00:40
ありがとうございます.
セッション管理がいやなので更新時再loadでやろうと思ってました...

ブラウザのウインドウをいくつも開いて同時に編集というのを
許可する場合はどうするんでしょうか？
entityの種類とidごとに別のキーでセッションに入れたりして、
セッション内に作業中entityをどんどん保存/updateしていく
という感じになるんでしょうか．

500:デフォルトの名無しさん
06/11/27 06:50:21
ログを常時監視してる場合も有るから、人間が直接読めるってのは重要な場合も有るかと。

まあ要求するのは良いが、それならおまいが管理までやれって返されるだけだよ(w
やぶ蛇にならないようにガンガレ。

501:デフォルトの名無しさん
06/11/27 09:13:01
ログを監視する場合はむしろSQLを整形して吐かれるのは嫌だと思うんだけどなぁ。
ログは、基本一行で全部出して欲しい派。

正規表現で取り出しやすくなるし。

502:デフォルトの名無しさん
06/12/06 02:35:47
いつの間にか、Dbutils1.1が出てますね。

503:デフォルトの名無しさん
06/12/07 02:23:14
Java6のJDBC4.0使った簡易O/Rマッピングってどんな感じですかね？

504:デフォルトの名無しさん
06/12/07 02:38:46
系統的にはiBatisみたいだね。
URLﾘﾝｸ(www.onjava.com)

505:デフォルトの名無しさん
06/12/07 22:45:10
>>498
いつも思うんだけど、Hibernateで排他制御を任せると、
複数サーバでの運用って事実上無理にならない？

JavaVM1つでしか動きを保障できないようなフレームワークが
なぜこんなに流行るのかわからない。

506:デフォルトの名無しさん
06/12/07 22:58:32
複数サーバの並列運用が必要な案件がそんなにないからじゃないかと。
大規模案件はやっぱりEJBの出番なんでしょう。

507:デフォルトの名無しさん
06/12/07 23:18:00
>>505
普通にHibernate経由でDBロック取ればいいじゃん。
API提供されてるし。

>>506
なんでEJB？

508:デフォルトの名無しさん
06/12/07 23:24:00
分散を最初から考慮しているってのは確かに大きいな。

509:507
06/12/07 23:33:33
>>506
ちょっと喧嘩売ってるみたいな書き方になった…

補足すると、そもそも並列稼動の実装ってかなり設計に依存するから
安易に大規模案件=EJBを持ち出す意味がわかんないって話。

単純なスケールアウトの話で、VMをまたいだキャッシュの同期を
意図してたならHibernateでもいくつかサポートしてるキャッシュ実装があるよ。
※Coherenceとか

ま、JBossのEJBって話だったら別に変わんないか。

510:デフォルトの名無しさん
06/12/08 00:27:16
>>505
Hibernateの排他制御は基本的に楽観的排他で、
UPDATE文発行するときに、検索条件に主キー＋バージョンカラムの値をつけ、
UPDATEの結果が０だったら排他エラーにするものだよ
同期を取っているのはあくまでもDBで、JVMは関係ないと思うけど

２次キャッシュに対する更新は、たしかに複数サーバでの運用が問題になるが
そんなときはクラスタ対応のJBoss TreeCacheを使えばいい

511:デフォルトの名無しさん
06/12/08 01:02:00
>>510
へー、そうなのか。勉強になった。
どちらにせよ、最近は状態を頑張って各ノードで通信して同期するより、
なるべく状態非依存にしてスケールアップする方向に進んでるから、
Hibernateの挙動はあまりいくないと思う。

512:デフォルトの名無しさん
06/12/08 01:33:17
>>511
参考までに聞きたいのだが、状態を持たない場合、複数画面の排他制御ってどうやってやるのが普通なの？
主キー＋バージョン値だけを保持して、バージョン値も条件に入れて再SELECTとか？
ただこの場合、関連するEntityを同時に再SELECTする場合、全部のバージョン値を保持しなきゃいけなくなるよね
自分もHibernate使っていたとき迷ったのだが、結局HttpSessionに保持してmerge以外に良い方法を思いつかなかった

513:デフォルトの名無しさん
06/12/08 02:15:47
>>511
Hibernateの挙動というよりは、単に2次キャッシュを使わなければ良いだけでは？
OptimisticLockも2次キャッシュ同様にデフォルトでは有効でないから
そこに文句をつけるのは違うと思う。

> どちらにせよ、最近は状態を頑張って各ノードで通信して同期するより、
> なるべく状態非依存にしてスケールアップする方向に進んでるから、

これ、そうなの？クラスタ系プロダクトの信頼度が上がってくるのはこれからじゃないのかな。
あと、下のケースはスケールアウトと間違えてない？

514:デフォルトの名無しさん
06/12/12 18:52:08
ibatisでカスタムタグを作ることってできますか？

515:デフォルトの名無しさん
06/12/13 23:35:57
>>514
OpenSessionInViewパターン的な仕組みとやりとりするカスタムタグを
作るってことなら、そんなに悩まずできるんじゃないの？
iBatisだろうとHibernateだろうと生Jdbcだろうと。

おれなら半日で作るね。

516:デフォルトの名無しさん
06/12/13 23:44:54
半日もかかるのか。ｲﾗﾈ。

517:デフォルトの名無しさん
06/12/14 00:06:28
タグ作って、テストして、プロジェクトの他メンバーに仕様を伝えるためのドキュメント作って・・・
としていたら半日なんてあっという間。

518:デフォルトの名無しさん
06/12/14 01:45:16
ibatisの設定ファイルに書くタグのことじゃね？

519:デフォルトの名無しさん
06/12/15 11:03:54
gcの対象って、インスタンスだけじゃなくてクラスも対象なんですか？
クラスに定義してあるメソッドの実行コードもメモリから消えちゃう？

Ｃをやっていたとき、実行コードはメモリのtextにロードされるから、
textエリアは書込み禁止なはずなので・・・、javaでは実行コードはtextに書かないのかな

520:デフォルトの名無しさん
06/12/15 12:26:48
>>519
スレ違いなので簡単に。詳細は別スレで語って。
URLﾘﾝｸ(www.nminoru.jp)

521:デフォルトの名無しさん
06/12/23 01:54:12
JBOSSなんて実運用で使ったら軽く死ねるよ。
コストかけても商用のEJBフレームワークを採用した方が、ロードバランサも不要で安くつく。

syslogやsnmpで監視しても、最後はopenviewのSQL DBに突っ込んでるしねえ。
加工することを考えると、SQL DBにログを突っ込むのは悪くはない。
syslogのテキスト処理しか出来ないperl廚が困るだけでしょ。DBIぐらい覚えろよと。

522:デフォルトの名無しさん
06/12/23 02:10:02
GlassFishでいいんじゃね？

523:デフォルトの名無しさん
06/12/23 04:50:43
>>521
知ったかぶり乙。

524:デフォルトの名無しさん
06/12/23 08:45:01
ほんとに意味不明だなｗ
ある種の才能。

525:デフォルトの名無しさん
07/01/08 12:20:52
HOS

526:デフォルトの名無しさん
07/01/17 22:43:07
取得する列を可変にしたいのですが、iBatisではどうやればいいですか

527:デフォルトの名無しさん
07/01/18 00:00:12
DBの型とJavaの型マップのデフォルト値を取得する方法ないでしょうか？
java.sql.Connection#setTypeMap　で型マップの上書きができるのは、分かったのですが・・・。

528:デフォルトの名無しさん
07/01/18 02:01:48
フレームワークとは直接関係ないんだけど、良いDAOの作り方というのが
いまいちわからん。
検索条件が複雑なユースケースがたくさんの場合、メソッドの引数やDTO
だとすげー煩わしくなってくるんだけど、みんなはどう対応してる？

529:デフォルトの名無しさん
07/01/18 23:59:20
>>528

検索はほぼＤＴＯですね。。
あとで変更があっても影響範囲極小にできるから

530:デフォルトの名無しさん
07/01/19 01:26:04
DTO でもめんどいと、もう Map しかないよね。

うぇーって感じだけど、DTO 書きが面倒というような規模
(ビューからDAOまで自分一人とか)なら、Map は割と現実的な
解だと思ってる。

531:デフォルトの名無しさん
07/01/19 01:29:16
SELECT文からDTOを児童生成するようなフレームワークって無いのかな？
Velocityとjava.sql.ResultSetMetaData使えば結構簡単に作れそうな気がするけど。
一時期作ってたけど、
同僚のマの人がせっせこ作ってくれるんで途中で投げた。

532:デフォルトの名無しさん
07/01/19 01:58:10
Hibernate以外でDAOでオブジェクトを生成するとき、みんなどこまでの階層を読み込んでる？
基準とかあるのか？

533:デフォルトの名無しさん
07/01/19 02:01:17
あるあるｗｗ

534:デフォルトの名無しさん
07/01/19 12:18:29
Mapが面倒ならRowSet使うのがいいと思われ

JPAとかこれから普及すると思うが、テーブル単位で扱うのが常識なのだろう
RDBに慣れた人ならjoinつかって重複するデータ部分も生成してすべてOneToOneでつなげれば今までと同じように使えるし
既存コードからの変更はわりと容易

535:デフォルトの名無しさん
07/01/19 19:14:25
もれのORマッピングに関しての認識がどうも間違ってるみたいなので教えてください。

ORマッピングフレームワークにはHibernateやToplinkなどが一昔前からあり、
最近JPAというものが登場し、JAVAEE5、SE6にも取り込まれている。JPAはEJB3.0でも使用されている。
JPAはコアの部分にtoplinkを使っていてtoplinkエッセンシャルと呼ばれる？
なんかよく分かんないのですがあってます？

536:デフォルトの名無しさん
07/01/19 20:00:39
あってない
まずJPAはEJB3.0の中のひとつ
ただし、JavaSEでも使えるように独立している

toplinkはJPAの実装のうちのひとつででリファレンス実装となっている
サーブレットコンテナのリファレンス実装だったTomcatと同じような位置づけ

537:535
07/01/19 20:32:39
>>536
ありがとうございます。
なんとなく理解できました。
EJB3.0の中にいたJPAは独立可能なのでSEにも加えられて、
toplinkとJPAの関係は Myfacesとjsfみたいなもんというわけですね。
めもめも

538:デフォルトの名無しさん
07/01/19 21:13:28
JavaSE6にJPAは取り込まれてない

539:デフォルトの名無しさん
07/01/19 23:56:48
すみませぬ。質問させてください。
取り出したレコードがコード値(性別とか)を保持している場合、0 -> 男性などのマッピングはいつ行えばいいのでしょうか。
あとDTOにコード値とマッピング後の文字列、両方を保持するのが一般的なのでしょうか。

540:デフォルトの名無しさん
07/01/20 00:03:15
そのへんは突き詰めるとSEXSテーブルを作ってSexオブジェクトを作って…。みたいになりそうだ。
enumうまく使えたら良いのかな？

541:デフォルトの名無しさん
07/01/20 01:15:37
>>539

DTOにマッピングの文字列を取得するメソッド作成するかな。。
確かにこういうの迷いますよね。。

542:539
07/01/20 11:34:33
SQLで結合してしまえばいいともおもうのですが(iBatis使ってるんで)顧客とかって結構コード値で管理してるデータが多いじゃないですか。
SQLのFromにだらだらと並べるのも嫌だし。。。
今のところマスタ系のデータはグローバル領域で保持して、View(jsp)でマッピングするという流れになっています。

543:328
07/01/21 02:02:35
マッピングはviewじゃないかな？

544:デフォルトの名無しさん
07/01/21 21:32:58
viewかー

545:某スレ167
07/01/22 01:48:20
んと、今まではシコシコと自作でDAO書いてたのですが、DI×AOPの導入と一緒にフツーのORMも勉強してみようと思い立ちました。

HibernateはどーしてもあのHQLとXDocletが好きになれず、Seasar2＋S2Daoをしばらくいじってみましたが、Spring Remotingにかなりクラっと来て、他のORMももう少し深く調べてみようと思いました。
PHPな人でもあるので、両方で（ある程度）知識を共用できるORMということでS2Daoとblanco、DI×AOPするならS2Daoという筋道で選択しましたが、Hibernateにコストをかけるべきかで少々迷っていますが、どんなモンでしょう？

今のこころは、とりあえずはDbUtilsやSpringJDBCを手早く身に付けておいて、続きはJPAというふうにしたほうがいいかな？、と思っています。
今日買ってきた「Spring2.0入門」を読んだ限りでは、ActiveRowMapperが正式リリースされればSpringJDBCはかなり使い勝手がよいという印象を持ちました。

自分でいくつかDAOを書いた限りでは、結局1:Nマッピングや複雑なビューの生成は自分で書くしかない、って思ってしまうんですよねぇ。
設計がまずいだけかもしれませんが、結局はそのあたりもビジネスロジックとは完全には無縁ではいられないのだから、１テーブル／１レコードをそのまま扱うDAO／DTOを基底クラスとして作って、
テーブル同士の関連は（ある程度のビジネスロジック込みで）ファサードとして纏める、なんてことをしてしまっています。
もっとも、これはあまり深くまで勉強せず、かじったどころか舐めた程度でしかない者の浅はかな感想かもしれませんが……。

追伸
それでもSeasar2の自動コンポーネント登録／自動アスペクト登録にはまだ魅力を感じています。ありゃ便利です。
人はこうやってSeasarの重力に魂を引かれていくのか……（苦笑）
ま、これは本当の余談ですけどね(^^;

546:デフォルトの名無しさん
07/01/22 02:07:54
S2/S2DAOはいいと思うよ。
Hibernateを今から覚えるぐらいなら、JPAを覚えて、
HibernateはJPA実装として使うという位置づけでいいんじゃないか？

547:デフォルトの名無しさん
07/01/22 18:59:48
>>545
Hibernate使ってる身としては、もう1:Nマッピングとかを自分で書く気にはなれないな
DBの定義に関する情報は、フレームワークがスキーマ読み込んでクラスまで自動作成すべき
たしかにHibernateの学習コストの高さはネックだけど、
JPAが出たおかげで、マッピング周りはかなり簡単になったと感じてる

548:デフォルトの名無しさん
07/02/08 10:01:15
あ

549:デフォルトの名無しさん
07/02/18 16:37:27
え？

550:デフォルトの名無しさん
07/02/19 22:28:19
iBatis
abatorConfigでsqlMapを自動生成するとかなりいろんな条件いれてくれたり、XXXExampleとか作られるのがうざいんだけどなんとかならない？

551:デフォルトの名無しさん
07/02/24 13:02:37
Hibernate...
いちいち関連を定義しないと外部結合できないのはなんとかならんのか。

552:デフォルトの名無しさん
07/02/24 14:48:47
>>551
それがあるから、Entityに関連書きまくることになるんだよなぁ

553:デフォルトの名無しさん
07/02/25 01:51:51
>> SELECT文からDTOを児童生成するようなフレームワークって無いのかな？

DBFluteとDolteng はSQLからS2Dao用のDTOを生成してくれるよ

554:デフォルトの名無しさん
07/02/25 12:14:08
>>553
そりゃあもちろん、SELECT文はDTOを出産しない＞児童生成

555:デフォルトの名無しさん
07/02/26 10:36:09
認知してよ！

556:デフォルトの名無しさん
07/02/26 12:29:29
>>551
SQLを意識するならHibernateを使わないほうが良いと思われる

むしろXMLで定義するだけでオブジェクト間関連を永続化してくれるのはありがたいと思え

557:デフォルトの名無しさん
07/02/26 15:47:06
Hibernate は先にオブジェクトがあって、
永続層がたまたまRDBでしたって感じで使わないと
無駄に時間かかるだけだな・・

何故俺の行く先はロクに正規化もされてない神聖不可侵な
クソスキーマがアプリオリに存在してるのばかりなのはなんでなんだぜ。

558:デフォルトの名無しさん
07/02/26 15:53:29
>>557
っ「転職」

559:デフォルトの名無しさん
07/02/27 23:38:39
>>558
たぶん、>>557の転職先でも、同じようなDB設計になるはずｗ
つまり、それは運命ｗｗｗ

560:デフォルトの名無しさん
07/02/27 23:43:16
>>556
外部結合と、SQLを意識するしないは関係ないよ。
（SQL特有のものだったら、そもそもHQLにouter joinなんて単語は出ない）
単に機能が不完全なだけ。実装が面倒だったんだろ。
内部結合は関連なくてもできるしね。

561:デフォルトの名無しさん
07/02/28 01:21:12
HQLでのouter joinとかって苦肉の策だと思うのは俺だけか？
普通なら結合条件つけなくていいと思うんだが・・

562:デフォルトの名無しさん
07/02/28 02:44:43
>>561
FETCH JOINで使ったり、SELECT new ...()で外部結合テーブルのカラムを含めるときに
普通に使ってるが、なぜつけなくていいと思ったの？

563:デフォルトの名無しさん
07/02/28 22:16:10
>>562
お前、全然オブジェクトで考えられてないのなｗｗｗ

564:デフォルトの名無しさん
07/03/01 00:19:50
>>563
考えられてないでいいけど、なぜつけなくていいと思ったの？

565:デフォルトの名無しさん
07/03/01 00:35:19
>>564
オブジェクト中心に考えてるとつけなくていいから

566:デフォルトの名無しさん
07/03/01 00:36:28
>>564
HibernateってORマッピングフレームワークだぞ。
Object-RDBだぞ。
Object中心に考えないとおかしい使い方になる

567:デフォルトの名無しさん
07/03/01 01:08:45
FETCH JOINは通常パフォチューで使うもので、オブジェクト中心とか関係ない
N+1セレクト問題を避けるため、関連を全てLAZYで定義して
HQLのFETCH JOINを使うのがHibernateの常套手段
また、レポートクエリをEntityのみで無理矢理行うのは馬鹿げている
HQLならSELECT new、またはSQLQueryで普通にSQL発行すればいい
全てをEntity中心に行うのは無理で無駄。
Entityは排他制御＋登録・更新処理で威力を発揮する。
レポート機能はSQL中心に考える。適材適所で使えばいいんだよ

568:デフォルトの名無しさん
07/03/01 11:58:30
>567
俺ならレポート部分はJDBC使う

569:デフォルトの名無しさん
07/03/01 11:59:41
> N+1セレクト問題を避けるため、関連を全てLAZYで定義して
> HQLのFETCH JOINを使うのがHibernateの常套手段
どこかに資料ありますか？

570:デフォルトの名無しさん
07/03/01 15:08:26
>>569
Hibernate in Action

571:デフォルトの名無しさん
07/03/01 21:21:24
そういやiBatis in Actionの訳本出ないかな～

572:デフォルトの名無しさん
07/03/01 22:31:13
レポートとか統計取るときにオブジェクトで考えてもおかしくなるだけだもんな。

そーゆー時には統計に優れれた言語であるSQLを使うのがやっぱり正しい。

573:デフォルトの名無しさん
07/03/02 09:18:32
RDB-Objectマッピングフレームワークの方がよくね？

574:デフォルトの名無しさん
07/03/02 12:31:06
つまりJava以外の話をしたいってこと？

575:デフォルトの名無しさん
07/03/02 13:11:16
O/R でなく R/O になってるところがポイントじゃね？
Object の永続層に RDB 使うためのマッピングフレームワークではなく、
RDB が先にあって、プログラミング言語から簡単に使うためのフレームワークなのでは。

576:デフォルトの名無しさん
07/03/02 13:45:57
DBを最初に考えて使いやすいものを
となるならJDBCRowSet使えばいいじゃない

577:デフォルトの名無しさん
07/03/02 15:25:12
データ構造はRDBのER図＋正規化で決定するけど、プログラムはオブジェクト指向でやりたいのよ

578:デフォルトの名無しさん
07/03/02 15:52:08
なら普通にJPAでいいだろ

579:デフォルトの名無しさん
07/03/02 15:59:26
JPAはObjectありきじゃね？

580:デフォルトの名無しさん
07/03/02 16:35:48
俺もRowSetにいっぴょ。

データをハンドリングする部分がオブジェクト指向で書ければ、
データそのものは生っぽくてもいいよ。

581:デフォルトの名無しさん
07/03/02 16:47:55
>>579
先にDBを定義しておいても使えるし、先にクラスを定義しておいても使える
どっちがメインかなんて意味なさ杉

582:デフォルトの名無しさん
07/03/02 17:09:31
おれはオブジェクト図を先に作るほうだけど、
ER図でどうなるかとか、SQLで結合しやすいかなどは考えながらやってるよ。
そういう意味じゃO-R-Oマッピングくらいか。

HQLやEJQLを使えば何でもできるというのはなんか違う気がする。
こいつは必要悪とは言わないがある種の妥協なんだと思う。

583:デフォルトの名無しさん
07/03/02 23:07:58
iBatis
テーブルごとにsqlMapを分けてるんだけど、
呼び出し側でnamespace意識して呼び出すことってできないの？

584:デフォルトの名無しさん
07/03/05 01:24:38
RDB使う時点で、性能やコーディングやりやすさはRDBの方に制約が大きいから、RDBの比重を大きくしたほうがしたほうがいいと思う。

585:デフォルトの名無しさん
07/04/08 01:06:34
こんな過疎スレがあったとは・・・・・・

586:デフォルトの名無しさん
07/04/12 19:09:54
hibernateなんだけど、one2many to many なテーブルをone2manyなBeanにする方法ってありますか？
具体例を挙げると、ショップとカタログと商品のテーブルがあるとすると
カタログテーブルはショップIDと商品IDのユニークな組み合わせを持ってて、他にカラムは無い状態。

実際はあるオブジェクトに対してカスタム属性を付加するアプリなんだけどね。

587:デフォルトの名無しさん
07/04/13 01:36:02
>>586

Chapter7.Association Mappings
URLﾘﾝｸ(www.hibernate.org)

試してなくて申し訳ないんだけど、ここに書いてある「join table」使ったマッピングじゃだめ？

588:デフォルトの名無しさん
07/04/14 00:43:39
586って、いわゆる many-to-many だと思うんだけど、違うの？

589:デフォルトの名無しさん
07/04/14 02:15:57
どう見てもただの many-to-many です。

590:デフォルトの名無しさん
07/04/14 19:00:53
カタログがリンクテーブルっぽいけど、商品から見たショップは1だろうからmany-to-manyではないんじゃないの？
よくわかんないけど。

591:デフォルトの名無しさん
07/04/14 19:17:24
>>586は「one2many to many 」って言ってるじゃないか
それがなんだかわからんが

592:デフォルトの名無しさん
07/04/14 19:49:12
カタログテーブルの商品IDがユニークなんだろ

593:586
07/04/17 18:45:14
ただのmany-to-manyのようでした。
カタログテーブルにあたるビーンを作ってしまったのが混乱の元のようで。

594:デフォルトの名無しさん
07/05/10 00:19:39
とっぷりんくあげ

595:デフォルトの名無しさん
07/06/23 18:25:45
データベースのコード値ってプログラムではどういうふうに管理してますか？
定数だけを集めるクラスを作ったり、列ごとの列挙型のクラス作ったりするのが普通なのですか？

596:デフォルトの名無しさん
07/06/23 18:34:07
ご自由に

597:デフォルトの名無しさん
07/06/23 20:46:11
・直値(マジックナンバー)
・const値
・enum挙
・ステートパターン
選択肢ってこれくらい？

598:デフォルトの名無しさん
07/06/23 23:25:41
エンティティクラスで const 定義してる。
基本的に、対応するカラムの型にあわせたconstを用意。

599:デフォルトの名無しさん
07/06/23 23:35:58
ステートパターンが使えるとこでは使うのが自然かな

600:デフォルトの名無しさん
07/06/24 08:30:24
エンティティでカプセル化でしょうな

601:デフォルトの名無しさん
07/06/24 14:02:08
>>597
揚げ足とりでスマンけど、直値って言うか？
immediateは即値じゃね？

602:デフォルトの名無しさん
07/06/24 23:53:07
回答いただきありがとうございます。
エンティティクラスとステートパターンがわからないので出直します。

603:デフォルトの名無しさん
07/07/11 10:15:30
aaaaa

604:デフォルトの名無しさん
07/07/13 10:49:14
各DBのテーブル定義などを取得するための共通IFをもったライブラリってありますか？

605:デフォルトの名無しさん
07/07/13 12:15:09
>>604
JDBC

606:デフォルトの名無しさん
07/07/13 14:25:25
>>605
例えばgetTableInfo()みたいなものがあって、使用者側はどのベンダー化を意識しなくてもいいってこと？

607:デフォルトの名無しさん
07/07/13 14:36:27
ある程度意識しないとダメだがな

608:デフォルトの名無しさん
07/07/13 14:52:45
>>607
ありました
DatabaseMetaDataのgetColumns、getTables

609:デフォルトの名無しさん
07/07/13 23:33:47
activerecord

610:デフォルトの名無しさん
07/07/13 23:34:40
hibernate

611:デフォルトの名無しさん
07/07/18 18:48:27
sql分を解析するライブラリって知ってます？

612:デフォルトの名無しさん
07/07/19 00:52:22
>>611
JavaCCとかAntlrとか

613:デフォルトの名無しさん
07/07/23 20:03:22
すみませんが、教えてください。

例えばhibernateで、１対多の関係のあるテーブルをone-to-manyで関連付けた場合、
「１」側のデータを取得した際に「多」側の関連するデータのインスタンスを
すべて作成してしまうんですよね？１万件のデータであっても。

最初の１０件・・のような、ページに分けて表示するようなWEBアプリの場合、
最初の１０件分のインスタンスだけが取得できればいいと思っているのですが
多側のインスタンス数のコントロールとかできるのでしょうか？

もしくは、みなさんこんな場合にはどのようにしているのか教えていただけると嬉しいです。

よろしくお願いします。

614:デフォルトの名無しさん
07/07/23 21:00:10
>>613
取得することも出来るし、しないこともできる

JPAでもそうだよ
基本はLAZYだろうね

615:デフォルトの名無しさん
07/07/24 12:49:13
>>614
ありがとう。
> しないこともできる
っていうのはどういう風にやるのでしょうか？出来たら教えて欲しいです。
次の１０件とか、どうやるんだろう？
LAZYにして、必要な分だけloopするとかですか？ん？違うかな。

それと、もう一つ教えてください。
hibernateで、例えばマスターデータの追加ではなく編集の画面で、
入力画面→確認画面→結果画面って流れで、
入力画面から取得した値をhibernateから取り出したエンティティの
プロパティ値に直接書いちゃうと、確認画面を表示するところで、
updateされちゃうじゃないですか。
普通は、このような流れの時には、hibernateから取り出しエンティティの
値をDTOなどにつめ直してセッションとかにぶち込んでおいて、
最後にDTOの値をエンティティに書き戻したりするんでしょうか？
うーん、伝わるかなぁ・・・。
よろしくお願いします。

616:デフォルトの名無しさん
07/07/24 13:51:11
>>615
標準APIであるJPAの実装では1:nのデフォはLAZY
なにもアクセスしなければ連結先は取得されない

後半の文はおかしくないか？
実装次第だが仮にエンティティにデータを入れたところで勝手にupdateされるか？
WEBアプリなら入力専用にデタッチされたエンティティわたしてもいいし、
入力専用のBeanでわたしてもいい（これが普通）

スタンドアロンアプリなどではトランザクションでコミットしなければそのままだし
コネクションの持ち方と運用次第としか

ループ命令はfor文とwhile文のどちらがいいですか？といってる感じがしてどうもなぁ

617:デフォルトの名無しさん
07/07/24 14:37:38
>>616
ありがとうございます。
> 標準APIであるJPAの実装では1:nのデフォはLAZY
> なにもアクセスしなければ連結先は取得されない
なにもアクセスしなければ、取得されないのは判るのですが、
ちょっとだけとか、ある範囲（２０件目～３０件目など）だけ取得したいのに、
全件取得されちゃうんじゃないかと・・・？違うんですかね？

> 後半の文はおかしくないか？
すんません。
> 実装次第だが仮にエンティティにデータを入れたところで勝手にupdateされるか？
ええ。例えば先の例（WEB）で、
１．エンティティを取得→入力画面にエンティティの情報含めて表示。ユーザーが入力してOKする。
２．おんなじエンティティを再度取得して、入力データでそのエンティティのプロパティを変更してセッションとかに入れる
　　→確認画面に編集後のエンティティの情報を表示
３．OKが押されたなら、その編集後のエンティティを取り出して、update

って流れで考えていたのですが、２．の終了段階でflushされて、その時エンティティの状態が変更されているから、
updateしちゃうんですよ。てっきりupdate(entity)メソッドを発行しない限りupdateされないかと思ってたんですけど
・・・って、私が試したのはhibernate2だったんですけど。今は違うのかな？
すみません。

618:デフォルトの名無しさん
07/07/24 15:06:30
それ、デタッチしないでセッション(=トランザクション)が開いたまま
使ってたんじゃないの？それだと update しなくても、セッションが
終了するときに、自動的に更新されるよ。

セッションって、webじゃなくてhibernateのほうのね。

619:デフォルトの名無しさん
07/07/24 16:11:49
>>618
ありがとうございます。
そうですね、デタッチしてなかったです。
そもそも、設計自体がよろしくないんですね。きっと。
専用のBeanを使うのがやはり普通なのでしょうかね？

なんとなく、入出力用のBeanを使うと、beanとエンティティとの間でプロパティのコピーを
しなきゃいけなくって、そうするのもわずらわしいと思って、
直接エンティティを操作していたんですけど、←これがわるいんですね。きっと。
勉強になりますた。

どなたか>>617の前半の部分も解決させていただけると助かります。
よろしくお願いします。教えて君ですみません。

620:デフォルトの名無しさん
07/07/24 18:56:52
UIはUIで割り切ったほうが良いんじゃないのか？

例だけど、エンティティでは電話番号というデータ1つだけど、
UIでは-区切りの入力欄にするとかあるし・・・

621:デフォルトの名無しさん
07/07/24 22:26:58
一部分だけの検索がほしいってlimitとか条件で絞るって話のことか?
それならEAGERでいいっしょ
まぁLAZYでもその程度問題ないけど、全件取得して処理するのはおかしい

O/Rマッパというのはキャッシングも利用するからSQLが投げられるとも限らないからね
運用すればわかるがLAZYだから遅くなるとは限らない

622:デフォルトの名無しさん
07/07/24 22:27:52
>>620
フレームワーク次第じゃない?
ハイフン区切りや複数のコンポーネントの結果が1つのフィールドになるようなら何にも問題ないし

623:デフォルトの名無しさん
07/07/25 08:28:56
>>619
> ちょっとだけとか、ある範囲（２０件目～３０件目など）だけ取得したいのに、
> 全件取得されちゃうんじゃないかと・・・？違うんですかね？

違うよ。LAZY LOADだとforループとかで21-30件目を
DTOなりにコピーするたびに

SELECT ... FROM ... WHERE ID=?

が発行されるだけ。なので計10回クエリーされるけど全件は取得されない。

SQLの効率をよくしたいなら、
JPQLなりHQLなりで必要な範囲だけ一回で取り出しておいて
コピーすればいい。

624:デフォルトの名無しさん
07/07/25 08:50:03
なんか、話がOneToManyとManyToOneでずれてる気がする

625:デフォルトの名無しさん
07/07/25 08:56:45
そもそもは
Maker m = getSingleResult("select m from Maker m");
ってやって
List<Product> products = m.getProducts();
ってやったときにproductsが1万件あったらどうするの？ってことじゃないの？

626:デフォルトの名無しさん
07/07/25 23:37:08
select m top 30 from Maker

627:デフォルトの名無しさん
07/07/26 00:10:29
>>625
そんなあほな話じゃないだろ・・・

さすがにそう思いたい

628:デフォルトの名無しさん
07/07/26 01:37:40
List<Products> products =
　em.createQuery("select p from Products p where p.maker = :maker").
　　setParameter("maker", m).setFirstResult(20).setMaxResults(10).getResultList();

629:デフォルトの名無しさん
07/07/26 01:40:12
SQL書いたほうが早いな

630:デフォルトの名無しさん
07/07/27 01:37:22
>>628
OneToManyの意味ね～

631:デフォルトの名無しさん
07/07/27 17:23:31
何千行もあるようなSQL書いて悦に入ってる香具師が
まだこの世には存在しているという事実にナッカリ。

632:デフォルトの名無しさん
07/07/27 20:19:50
昔の方がSQLの長さに理不尽な制限があったりしたような気がするが

633:デフォルトの名無しさん
07/07/27 23:39:38
今だってOracleの場合 VARCHAR 4000 Byte の制限やテーブル名、カラム名の長さ制限には泣かされてるがな。

634:デフォルトの名無しさん
07/07/27 23:49:49
H2はLIKEがCLOBにも使えて感動した覚えがある。
たしかOracleって無理だったよね？

635:デフォルトの名無しさん
07/07/27 23:56:39
何千行もあるようなSQLを書くような輩が発生する
危険性があるので、O/Rマッパー使いなさいってのは無理がある

636:デフォルトの名無しさん
07/07/28 08:33:07
何千行もあるようなSQLがORマッピングで解決できると思ってるやつは、ORマッピングの意味を間違えている。
データベースにやらせてた処理をJava側にやらせるためにあるもんじゃない。

637:デフォルトの名無しさん
07/07/28 10:07:04
長いSQLが必要な処理ってのはある

O/RマッパとSQLは排他ってわけじゃないし
それぞれ利点と不利な点がある

638:デフォルトの名無しさん
07/07/28 10:54:56
ワイルドカードあるのに実質的に使えないのが癌だな
ついついカラム名を２～３文字にして
エイリアスも極力短めに（ｒｙ

639:デフォルトの名無しさん
07/07/28 14:17:05
JPAでは
select count(*) from Employee e
は使えないのでつか？

640:デフォルトの名無しさん
07/07/28 14:26:19
select count(e.id) from Employee e
とかじゃないかな

641:デフォルトの名無しさん
07/07/28 14:29:38
どうもでつ

642:デフォルトの名無しさん
07/07/28 14:37:34
select count(e) from Employee e
でもおk

643:デフォルトの名無しさん
07/07/28 20:01:35
またまたありがとでつ
そちらの方を使うことにしまつ

644:デフォルトの名無しさん
07/08/07 22:08:14
Java永続化APIの次期バージョン、"JSR 317"として仕様策定プロセスへ
URLﾘﾝｸ(journal.mycom.co.jp)

既存バージョンからの主な変更点は以下の通り。

・組み込みオブジェクトのコレクションサポート
・組み込みオブジェクトの多段ネストをサポート
・Orderd Listのサポート
・アクセスタイプの組み合わせをサポート
・JPQL(Java Persistence Query Language)の拡張
・Criteriaの導入
・クエリとエンティティマネージャの設定ヒントの標準化
・DDL生成とJava2DBマッピングのための追加メタデータの標準化
・Bean Validation(JSR-303)のサポート

645:デフォルトの名無しさん
07/08/07 23:56:23
ポイントは
・Orderd Listのサポート
・クエリとエンティティマネージャの設定ヒントの標準化
・Bean Validation(JSR-303)のサポート
あたりかな

気になるのはenumが使いたい場合ってのが結構あることかな

たぶんJPAで一番ほしいのはDBのデフォルト値を有効に出来るような仕様だろうな
開発、運用していて一番これが厳しかったりする

646:デフォルトの名無しさん
07/08/08 00:28:41
Criteriaの導入が気になる。

Hibernateの仕様をベースにすんのかな？
あれはSQLと違って条件に応じて結合するテーブルを
動的に変化させるような使い方の場合に便利だと思う。

Hibernateではちょっと実装面がアレだったけど、
JPAだと安定しやすい仕様になってくれるんだろう。

647:デフォルトの名無しさん
07/08/08 00:42:05
Criteriaが必要になるときってそんなにない

というか、ある程度のことをやろうとしようとするとどうせJPQLを組み立てることになって
Criteriaでまかなえないことも多そうだし

LAZYなどの厳密化がほしいかな
デフォだとめちゃくちゃ検索の連鎖する場合が多すぎる

ただ、鯖だとキャッシングしまくるからパフォーマンスの問題はでないんだけど
クライアントからのアクセスがおわっとる

せっかくSwingとの親和性がよくなりそうなのにC/S無視するのはどうかと
社内アプリならわりとC/Sもシェアあるぜ
まだまだ50%は超えているんじゃないかな

648:デフォルトの名無しさん
07/08/12 14:18:04
>というか、ある程度のことをやろうとしようとするとどうせJPQLを組み立てることになって
>Criteriaでまかなえないことも多そうだし
具体的にはどういうケースですか？

649:デフォルトの名無しさん
07/08/12 15:49:31
>647の知識はHibernate2で止まってるとみた。

650:デフォルトの名無しさん
07/08/13 10:57:08
dblってかなりよさげじゃない？

次ページ