[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 2chのread.cgiへ]
Update time : 02/24 23:25 / Filesize : 149 KB / Number-of Response : 521
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Java⇔RDBのMapping-Frameworkを語るスレ Vol.4



1 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 11:54:44 ]
前スレ:
 Java⇔RDBのMapping-Frameworkを語るThre Vol.3
 ttp://pc8.2ch.net/test/read.cgi/tech/1090653286/
過去スレ:
 「Java⇔RDBのMapping-Frameworkを語るスレ Vol.2」(落ち)
 ttp://pc5.2ch.net/test/read.cgi/tech/1086315004/
 「Java⇔RDBのMapping-Frameworkを語るスレ」(落ち)
 ttp://pc5.2ch.net/test/read.cgi/tech/1049030272/


●まずは、基礎知識と技術選択指針など
 [The Fundamentals of Mapping Objects to Relational Databases]
  (RDBに対するオブジェクトマッピングの基礎(英語))
  ttp://www.agiledata.org/essays/mappingObjects.html

 [O/R-Mappingツールの比較サイト(英語)]
  ttp://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison

 [Catalog of Patterns of Enterprise Application Architecture (PoEAA)]
  ttp://www.martinfowler.com/eaaCatalog/

あとは>>2以降


331 名前:328 mailto:sage [2006/08/17(木) 18:32:31 ]
>>330
で、結局利点はなんなのでしょうか(^^;

332 名前:デフォルトの名無しさん mailto:sage [2006/08/17(木) 18:35:56 ]
>>329
個人の趣味で使うものってことでしょうか??
仕事で使うもんじゃないってことでFA?

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

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

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

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

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

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


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

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

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

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

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



340 名前:328 mailto:sage [2006/08/17(木) 19:39:49 ]
XMLをテーブル定義から自動作成する工数と
DTOなど自分でコーディングする工数

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



341 名前:デフォルトの名無しさん mailto:sage [2006/08/17(木) 19:51:09 ]
>XMLをテーブル定義から自動作成する工数と
>DTOなど自分でコーディングする工数

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

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

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

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

343 名前:デフォルトの名無しさん mailto:sage [2006/08/17(木) 19:54:11 ]
そう感じてて、それで本当にいい! ノープロブレム!
って思うなら、それでいいじゃねえか。

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

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

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

345 名前:デフォルトの名無しさん mailto:sage [2006/08/17(木) 20:02:51 ]
生産性にまともな測定方法なんてネーヨ
むかつくやり方を続けると、精神衛生に悪くて生産性が下がる。
それだけ。

346 名前:デフォルトの名無しさん mailto:sage [2006/08/17(木) 20:35:55 ]
>OR mapperに潜んでいるバグのリスク
おまいのところがGavin Kingより優秀な開発者を抱えてるならリスクとなり得るなw

347 名前:デフォルトの名無しさん mailto:sage [2006/08/17(木) 20:47:21 ]
>>345
それは真理だな。

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

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

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



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

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

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

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

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


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

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

354 名前:デフォルトの名無しさん mailto:sage [2006/08/18(金) 01:31:01 ]
>>176
忘れた頃に禿同

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

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


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

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

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

357 名前:デフォルトの名無しさん mailto:sage [2006/08/18(金) 08:00:02 ]
>>356
>>354からそこまで読み取れたらネ申だな。

358 名前:デフォルトの名無しさん mailto:sage [2006/08/18(金) 08:42:51 ]
>>176を先に読めよw

359 名前:デフォルトの名無しさん mailto:sage [2006/08/18(金) 18:56:37 ]
iBATIS2.2.0(β)



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


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

362 名前:デフォルトの名無しさん mailto:sage [2006/09/06(水) 11:11:38 ]
貼っとく
[ThinkIT] 第7回:それぞれのメリット/デメリット (1/3)
ttp://www.thinkit.co.jp/free/article/0606/13/7/

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

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



364 名前:デフォルトの名無しさん mailto:age [2006/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の順に格納されているので、
1コ1コ取り出さないといけないのがメンドイ。

つーか instanceofで確認取らせんな!( ゚Д゚)ゴルァ!!


365 名前:デフォルトの名無しさん mailto:sage [2006/09/26(火) 01:16:45 ]
あいばてぃす?
あいべいてぃす?

366 名前:デフォルトの名無しさん mailto:sage [2006/09/26(火) 01:26:28 ]
いーばてぃす

367 名前:デフォルトの名無しさん [2006/09/26(火) 01:36:02 ]
ibatis.apache.org/background.html

ここ読むと

>We pronounce it: eye-BAT-iss

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

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

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

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

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



370 名前:デフォルトの名無しさん mailto:sage [2006/09/26(火) 08:09:54 ]
作ったらOSSとして公開でいいんじゃない?w

371 名前:デフォルトの名無しさん mailto:sage [2006/09/26(火) 13:10:33 ]
ソースはどこにうpされてるの?


372 名前:デフォルトの名無しさん mailto:sage [2006/09/26(火) 20:32:49 ]
会社で作ってて、パッケージ名までcom.なんとかになってるから、
さすがに公開はできんわw

373 名前:364 mailto:sage [2006/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オブジェクト変数に格納し直されるっていう動作はどーなのよ。
いいの?これ。

どーいう意味かの解説は ttp://canetrash.seesaa.net/article/2656752.html にあるんだが、動作的にねぇ…?
結局引数に渡したmapからListを取り出して、さらにBeanを取り出して…。

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



374 名前:373 mailto:sage [2006/09/26(火) 21:46:39 ]
あー、でも ttp://www.h7.dion.ne.jp/~a.d.1976/naguri20050307.html
見ると

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

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

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


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

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

377 名前:デフォルトの名無しさん [2006/10/07(土) 04:01:15 ]
やっぱHibernate最高ですよね?
うちの会社に導入しようと思っています。
いまどきJDBCでSQL直書きなんて氏ねばいいと思います。

378 名前:デフォルトの名無しさん mailto:sage [2006/10/07(土) 04:23:21 ]
導入前に氏んでいるわけだな。

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



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

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

382 名前:デフォルトの名無しさん mailto:sage [2006/10/07(土) 11:46:24 ]
適材適所。「最高」なんてものは無い。

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

Hibernateありきだ。

最初に。

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

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


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

386 名前:377 [2006/10/08(日) 11:26:36 ]
いや、Hibernateも内部でJDBCを使っている。

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

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

388 名前:デフォルトの名無しさん mailto:sage [2006/10/08(日) 14:15:17 ]
>そういうフレームワークとしてHibernateに
>勝てるわけがないということだ。

すげぇ盲信っぷりにワロタ。

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

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



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

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

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

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

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

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

394 名前:デフォルトの名無しさん mailto:sage [2006/10/09(月) 04:56:36 ]
まずいエサだがスレの内容には沿ってるな>393

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

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

395 名前:デフォルトの名無しさん mailto:sage [2006/10/09(月) 05:56:46 ]
>>393
質問がO/Rマッパーの有用性は

396 名前:デフォルトの名無しさん mailto:sage [2006/10/09(月) 06:29:22 ]
ごめん、途中で送信した

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

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


397 名前:デフォルトの名無しさん mailto:sage [2006/10/09(月) 11:29:44 ]
O/R マッパー自体の有用性が分からない、つーのはスレ違いじゃね?

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

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

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

JDBC 直、Hibernate、iBatis、DBUtils、、、



400 名前:デフォルトの名無しさん mailto:sage [2006/10/14(土) 10:20:46 ]
>製造担当はたぶん JDBC 直以外知らない。
>学習工数、製造工数の少なさを最優先。

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

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

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

401 名前:デフォルトの名無しさん mailto:sage [2006/10/14(土) 14:16:27 ]
>>399
MS Access

402 名前:デフォルトの名無しさん mailto:sage [2006/10/14(土) 14:50:21 ]
短期なのに学習コスト込み?てか10日?
ギャグのつもりじゃなかったらやめたほうがいいだろう。

403 名前:デフォルトの名無しさん mailto:sage [2006/10/14(土) 15:28:56 ]
>>399
JDBC 直

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

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

406 名前:デフォルトの名無しさん mailto:sage [2006/10/14(土) 18:07:12 ]
>>399
JAVA止めて、お前がLLで作る

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

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



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

411 名前:デフォルトの名無しさん mailto:sage [2006/10/15(日) 00:50:59 ]
>>409
thx。DbUtils か JDBC にするわ。

412 名前:デフォルトの名無しさん mailto:sage [2006/10/15(日) 00:52:05 ]
>>410
何のハナシをしているのかわかりません

413 名前:デフォルトの名無しさん mailto:sage [2006/10/17(火) 13:36:28 ]
Hibernate 3.2.0 GA
Hibernate Annotations も Hibernate EntityManager も同時に 3.2.0 GA

414 名前:デフォルトの名無しさん mailto:sage [2006/10/17(火) 18:53:38 ]
ガッはなんだガッは

415 名前:デフォルトの名無しさん mailto:sage [2006/10/17(火) 23:30:51 ]
Generally Available


416 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 00:07:08 ]
>>414
ぬるぽ

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

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

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


419 名前:デフォルトの名無しさん mailto:sage [2006/10/22(日) 21:19:31 ]
>>418
UNIQUE制約ってしってるか?

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



420 名前:デフォルトの名無しさん mailto:sage [2006/10/22(日) 22:18:09 ]
>>419
そりゃそうだ。なんできずかなかったんだろ。ありがとござんした

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

422 名前:デフォルトの名無しさん mailto:sage [2006/10/22(日) 22:19:52 ]
ああ、勘違いした。複合キーが一意であることね。
ごめん

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

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


425 名前:デフォルトの名無しさん mailto:sage [2006/10/25(水) 23:30:26 ]
Hibernate で直に SQL 発行して結果を
Map のリストで受け取ることってできますか?

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

426 名前:デフォルトの名無しさん [2006/10/25(水) 23:31:47 ]
保守

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

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

429 名前:デフォルトの名無しさん mailto:sage [2006/10/26(木) 02:16:00 ]
>>425
Mapによるマッピングには対応している

www.hibernate.org/hib_docs/v3/reference/en/html/persistent-classes.html#persistent-classes-dynamicmodels



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

431 名前:デフォルトの名無しさん mailto:sage [2006/11/02(木) 02:12:45 ]
>>430
dbutils、シンプルで使いやすいから愛用してるんだけど
あんまり使ってる人いないのかな?

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

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

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

435 名前:デフォルトの名無しさん mailto:sage [2006/11/03(金) 14:55:01 ]
>>434
普通と違う?


436 名前:デフォルトの名無しさん mailto:sage [2006/11/03(金) 18:02:24 ]
booleanのときとか?

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

SELECT ID_DATA AS IDDATA

とか、

public void setId_Data() {

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

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

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

439 名前:デフォルトの名無しさん mailto:sage [2006/11/03(金) 23:38:04 ]
ORM使ったこと無いので教えてください。

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



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

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


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

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

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

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

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

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

444 名前:デフォルトの名無しさん mailto:sage [2006/11/04(土) 01:01:50 ]
>>438
DbUtils から BeanUtils への依存関係はないんじゃない。

445 名前:デフォルトの名無しさん mailto:sage [2006/11/04(土) 01:04:14 ]
>>443
>>444じゃないけど、普通は考えるでしょ。


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

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

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

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

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

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



450 名前:デフォルトの名無しさん mailto:sage [2006/11/04(土) 01:34:37 ]
アノテーション使えるDbUtilsが欲しい…

451 名前:447 mailto:sage [2006/11/04(土) 01:39:13 ]
>>449
えーと、シングルスレッドで、順番に更新しないと駄目という意味??

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

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

453 名前:デフォルトの名無しさん mailto:sage [2006/11/04(土) 02:00:11 ]
>>451
そうじゃねーべ。
Hibernateでも何でもいいから一旦勉強してくれ!

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

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

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

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

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

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


456 名前:デフォルトの名無しさん [2006/11/04(土) 11:04:04 ]
>>438

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

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

458 名前:デフォルトの名無しさん mailto:sage [2006/11/04(土) 12:31:30 ]
なんか Hibernate & DbUtils なモードだな。

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

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



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

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

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

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

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

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

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

464 名前:デフォルトの名無しさん [2006/11/04(土) 23:04:37 ]
Hibernateにはバッチは向いてないの?

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

個人的には
通常:Hibernate
バッチ、複雑なSQL:JDBC直

かなあ

466 名前:デフォルトの名無しさん mailto:sage [2006/11/04(土) 23:17:23 ]
>>464
バッチには向いてないだろうね。

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


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

468 名前:デフォルトの名無しさん mailto:sage [2006/11/04(土) 23:47:26 ]
>>467
遅いし、馬鹿だし、救いようがないな

469 名前:デフォルトの名無しさん mailto:sage [2006/11/04(土) 23:48:32 ]
>>467
あるよね。



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

471 名前:デフォルトの名無しさん mailto:sage [2006/11/05(日) 00:14:54 ]
煽ってるだけだから気にすんな

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

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

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

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

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

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

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

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

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

479 名前:デフォルトの名無しさん mailto:sage [2006/11/05(日) 20:09:47 ]
排他制御ってSpringやSeasarといったDIコンテナに
任せるものと違うの?



480 名前:デフォルトの名無しさん mailto:sage [2006/11/05(日) 22:28:55 ]
SpringやSeasarがテーブルのバージョンカラム定義や、
更新時の自動バージョンカラムチェックとかやってくれるのか?w

481 名前:デフォルトの名無しさん mailto:sage [2006/11/05(日) 22:37:53 ]
トランザクションかとおもたw

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


483 名前:デフォルトの名無しさん mailto:sage [2006/11/06(月) 10:24:17 ]
ibatisにsqlをフォーマットするクラスはありますか?

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

485 名前:デフォルトの名無しさん mailto:sage [2006/11/11(土) 21:23:42 ]
hibernate 3.2
hibernate annotation 3.2
hibernate tool 3.2
Eclipse 3.2

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


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

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

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

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



490 名前:デフォルトの名無しさん mailto:sage [2006/11/19(日) 14:14:39 ]
そういうツールはいくらでもあるじゃん。

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

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

困った。


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

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

494 名前:デフォルトの名無しさん mailto:sage [2006/11/20(月) 18:45:26 ]
Hibernateなら整形出力あるんだけどね

495 名前:デフォルトの名無しさん mailto:sage [2006/11/20(月) 18:57:18 ]
>>492
その自称管理者がクソ

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

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

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

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

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

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

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

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

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




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

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

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

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

502 名前:デフォルトの名無しさん mailto:sage [2006/12/06(水) 02:35:47 ]
いつの間にか、Dbutils1.1が出てますね。

503 名前:デフォルトの名無しさん mailto:sage [2006/12/07(木) 02:23:14 ]
Java6のJDBC4.0使った簡易O/Rマッピングってどんな感じですかね?

504 名前:デフォルトの名無しさん mailto:sage [2006/12/07(木) 02:38:46 ]
系統的にはiBatisみたいだね。
www.onjava.com/pub/a/onjava/2006/08/02/jjdbc-4-enhancements-in-java-se-6.html

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

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

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

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

>>506
なんでEJB?


508 名前:デフォルトの名無しさん mailto:sage [2006/12/07(木) 23:24:00 ]
分散を最初から考慮しているってのは確かに大きいな。

509 名前:507 mailto:sage [2006/12/07(木) 23:33:33 ]
>>506
ちょっと喧嘩売ってるみたいな書き方になった…

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

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

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




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

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

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

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

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

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

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


514 名前:デフォルトの名無しさん mailto:sage [2006/12/12(火) 18:52:08 ]
ibatisでカスタムタグを作ることってできますか?

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

おれなら半日で作るね。



516 名前:デフォルトの名無しさん mailto:sage [2006/12/13(水) 23:44:54 ]
半日もかかるのか。イラネ。

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

518 名前:デフォルトの名無しさん mailto:sage [2006/12/14(木) 01:45:16 ]
ibatisの設定ファイルに書くタグのことじゃね?

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

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




520 名前:デフォルトの名無しさん mailto:sage [2006/12/15(金) 12:26:48 ]
>>519
スレ違いなので簡単に。詳細は別スレで語って。
ttp://www.nminoru.jp/~nminoru/java/class_unloading.html






[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<149KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef