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が欲しい…
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ってかなりよさげじゃない？
651:デフォルトの名無しさん
07/08/14 09:57:59
>>650
まちがえ、ddlutils
652:デフォルトの名無しさん
07/08/15 14:40:24
>>649
激しく同意
653:デフォルトの名無しさん
07/08/17 01:57:00
>>649
JPQLってINを上手く扱えるようになったのか・・・
654:デフォルトの名無しさん
07/08/17 05:22:41
>JPQLってINを上手く扱えるようになったのか・・・
過去のJPQLがINを上手く扱えなかったような記述だな。
過去のJPQLって？ｗ
655:デフォルトの名無しさん
07/08/17 21:32:58
INで配列使えるの?
656:デフォルトの名無しさん
07/08/17 22:12:54
653がどうして649への安価なのかが理解できない
657:デフォルトの名無しさん
07/08/18 00:34:59
>>656
禿げしく同意
全くもって理解不能
658:デフォルトの名無しさん
07/08/18 00:52:11
JPAもまともに触ってないやつおおすぎ
659:デフォルトの名無しさん
07/08/18 01:40:33
「JPAも」って言うほど評価・実績のあるものではないんだがな。
660:デフォルトの名無しさん
07/08/18 03:23:45
JPAも(Hibernateも)まともに触ってないやつおおすぎ
661:デフォルトの名無しさん
07/08/18 13:25:34
仕事には必要ないでしょ。趣味ならいいけど。
662:デフォルトの名無しさん
07/08/19 12:25:58
661が仕事で使ってるものは、おれには仕事に必要ない。趣味ならいいけど。
そういう話か？
663:デフォルトの名無しさん
07/08/19 14:56:37
iBatisを使っています。
updateをするときは1回主キーで検索した結果のビーンを渡すが普通でしょうか？
1つのテーブルを更新する個所が複数あって、その都度、updateのバリエーションが増えてきてしまっています。
私はORMを今回はじめて使うのであまり口を出せないのですが、こういうものなのでしょうか？
664:デフォルトの名無しさん
07/08/19 15:54:47
>>662
そういう話ｗ
665:デフォルトの名無しさん
07/08/19 19:04:38
>>663
普通のO/Rマッパは変更のあった箇所のみupdateを発行する
薄いラッパほどそのままなので把握がしやすいともいうが、チューニングしていくのは面倒かも
666:デフォルトの名無しさん
07/09/01 15:45:34
ロストアップデートを防ぐような機能ってないですか？
667:デフォルトの名無しさん
07/09/25 22:32:58
Hibernate3になって、ストアドプロシージャをサポートしたらしいけど
参考サイトとかないですかね？
668:デフォルトの名無しさん
07/09/26 00:44:57
>>667
URLﾘﾝｸ(www.hibernate.org)
669:デフォルトの名無しさん
07/09/26 00:48:43
>>668
英語読めない
670:デフォルトの名無しさん
07/09/26 01:39:42
>>669
URLﾘﾝｸ(www.nova.ne.jp)
671:デフォルトの名無しさん
07/09/26 01:45:43
>>669
それは、読んでないだけ。
672:デフォルトの名無しさん
07/09/27 00:48:19
カイエンってどうよ？
673:デフォルトの名無しさん
07/09/28 00:59:53
最近、聞かんな。昔はHibernateと争える勢いだったっけ。
674:デフォルトの名無しさん
07/09/28 07:00:36
JPAに対応したよ
675:デフォルトの名無しさん
07/10/06 18:11:51
最近Ruby on Railsをすこしやってたんだけど、Railsに相当するものって
Javaで言うとどんなのがあります？
やりたいのは、Railsでやってた、↓をJavaでもやりたい。
Four Days on Rails 4日で作るToDoリスト
URLﾘﾝｸ(rails.to)
676:デフォルトの名無しさん
07/10/06 19:05:18
>>675
JRuby on Rails
677:デフォルトの名無しさん
07/10/07 00:30:39
>>675
厳密にはJavaじゃないけど、Grailsとか
URLﾘﾝｸ(grails.codehaus.org)
678:デフォルトの名無しさん
07/10/07 00:48:54
>>675
JSF+Rowsetならすべてポトペタであつかえるオールインワン環境だぞ
問題はRowsetが主流に慣れそうになくてJSF+JPAになりそうだけど
679:デフォルトの名無しさん
07/10/07 01:43:18
>>675
Chura
680:デフォルトの名無しさん
07/10/07 02:05:28
>675の人気にジェラ
681:デフォルトの名無しさん
07/10/07 02:32:45
詳しくないけど、676～678 は違うだろ。>>679 だな。
682:デフォルトの名無しさん
07/10/07 06:00:35
>675
RIFE
683:デフォルトの名無しさん
07/10/07 08:50:59
>>676
JRubyインストールしてみる
>>677
Groovyインストールしてみる
>>678
ポトペタって、マウスでぐりぐりやるとあらできあがり？
わからん
>>679
＞churaの基本構成は､Seasar2.4 + Teeda + KuinaDao + S2Hibernate-JPA + S2Dxo + ツール群という形になります
インストール大変そうだから様子見てみる
>>682
RIFEインストールしてみる（他と比べると、ちょっと情報量が少ない？
684:デフォルトの名無しさん
07/10/07 11:52:24
>>683
churaのインストールはこれだけだよ。
URLﾘﾝｸ(s2container.seasar.org)
俺も最初は面倒くさそうだと思ったんだけど、eclipseプラグイン入れれば揃うみたい。
685:デフォルトの名無しさん
07/10/07 23:49:40
なんというヘタレ…
URLﾘﾝｸ(d.hatena.ne.jp)
686:デフォルトの名無しさん
07/10/08 03:45:53
Railsの環境設定なんか、Netbeans6のRuby版いれればDBもWebサーバーも苦労ないのにな。
687:デフォルトの名無しさん
07/10/08 04:28:59
テーブルと1対1なエンティティクラスとマッピングする利点てなによ？
688:デフォルトの名無しさん
07/10/08 08:46:40
>>685
こんなやつ一生無職のほうが業界のためだ
689:デフォルトの名無しさん
07/10/08 11:59:00
こんなクズに対してレスしてたのか
690:デフォルトの名無しさん
07/10/08 14:31:25
>>685って>>675？
691:デフォルトの名無しさん
07/10/08 14:56:55
一目瞭然だろ
692:デフォルトの名無しさん
07/10/08 17:40:10
結論
標準になった以上、JPA以外の選択肢はありえない
693:デフォルトの名無しさん
07/10/08 19:32:17
Cayenneまで対応したことで、ORマッピングフレームワークが全部JPA対応になったから、どれを選んでもJPAには対応している、ってことか？
結論にはならんな。
694:デフォルトの名無しさん
07/10/08 20:35:11
Db上のフィールドがJavaのメンバ名として使用できない名称のような場合、
どうやってORmappingしているのですか？
695:デフォルトの名無しさん
07/10/08 20:41:11
>>694
完全に一致させる必要ないだろ
696:デフォルトの名無しさん
07/10/08 20:48:05
>>694
好きな名前つければいいと思うよ。
697:デフォルトの名無しさん
07/10/08 20:48:34
>>694
プロパティとDBのフィールド名は一致させる必要はないぞ
698:デフォルトの名無しさん
07/10/08 21:35:58
>>695-697
POJO内のメンバはDB上はこのフィールド、
のようなことはマッピングファイル？か何かに書いておけば
Dbアクセスの時は意識せずに使える、
ORマッピングのツールはどれもそんなモンなんですか？
逆に、それはできないぞ、というモノもあるのでしょうか。
699:デフォルトの名無しさん
07/10/09 01:09:02
>>698
EJB3.0だとこんな感じになるはず。
# ただ、なるべく一致させておいた方が不幸なことが起きないかも・・・
@Entity(name="ITEM")
public class Item implements Serializable{
private int id = 0;
@Id
@GeneratedValue(strategy=GenerationType.AUTO)
@Column(name="RENBAN",nullable=false)
public int getId(){ return id;}
public void setId(int id){ this.id=id;}
private String title = null;
@Column(name="SHOSEKI_MEI",nullable=false)
public String getTitle(){ return title;}
public void setTitle(String title){ this.title=title;}
700:694
07/10/09 01:21:50
試しにCayenneでやってみますた。
作成されたBeanを見ると、
public static final String フィールド名_PROPERTY = "メンバ名";
という定数があって、これを使うようですね。
外部ファイルかアノテーションでやるのかと思ってましたが、
他のフレームワークでもこんなカンジなんでしょうか。
>>699
なるべく一致させたいのはやまやまですが、
ERを変えられるような立場ではないのです。orz
EJB3.0だとアノテーションで指定するのですね。
参考になります、ありがとうございますた。
701:デフォルトの名無しさん
07/10/09 13:04:01
JPAはEJB3から独立してSEで使えるから便利だよ
NetBeansだとテーブルから全部自動で作られるし
702:デフォルトの名無しさん
07/10/09 20:24:11
>>701
NetBeans以外では自動で作ってくれるﾂｰﾙをしらない？
703:デフォルトの名無しさん
07/10/09 21:34:41
プラグインを用意することなくデフォで使えるってのが大きいだけだろ
704:デフォルトの名無しさん
07/10/10 01:27:45
>>702
知ってる
705:デフォルトの名無しさん
07/10/10 01:31:27
>>701
きしだﾀｿ乙
706:デフォルトの名無しさん
07/10/12 06:45:53
>>702
WTP2.0
707:デフォルトの名無しさん
07/10/12 22:52:01
結論：DAOでＯＫ マッピングｲﾗﾈ
708:デフォルトの名無しさん
07/10/12 23:05:37
DAOでOKって、マッピング使っても使わなくてもDAO使うだろ。
709:デフォルトの名無しさん
07/10/13 03:12:15
>>707
ありえないほどバカだな
710:デフォルトの名無しさん
07/10/13 08:51:12
DAO内で自分でSQL発行じゃね？
711:デフォルトの名無しさん
07/10/13 10:59:52
>>710
その場合でも、手動マッピングはするわけだが
712:デフォルトの名無しさん
07/10/13 11:32:35
わかった！>>707はマッピングせずに
M a p を そ の ま ま 使 う ん だ よ ！
713:デフォルトの名無しさん
07/10/13 13:24:55
ものによってはMapそのままでも悪くないと思うけどな
キー値の取得がプロパティの取得につながるし
ただ、HashMapとかそのままつかうのだけは禁止
キー値が存在しない場合Exceptionをかえすような実装ならOK
714:デフォルトの名無しさん
07/10/13 17:00:59
まーた、Map厨発生か。
が、キー値なしで例外は納得した。
715:デフォルトの名無しさん
07/10/15 15:09:20
実は Microfost Data Access Objects のことなのかも知れん。
716:デフォルトの名無しさん
07/10/16 12:47:53
ResultSetだってRowSetだってmapベースだろ
DelphiだってBCBだってスクリプト系だって
717:デフォルトの名無しさん
07/10/16 14:05:52
こいつは何をいっているんだ？
718:デフォルトの名無しさん
07/10/16 14:19:27
はじめから道具ありきで、どっかで道に迷っちゃうんだろ
若い奴らは大変なんだよきっと
719:デフォルトの名無しさん
07/10/16 14:28:44
Map系ってのはMapインターフェースを実装したものではなくて
名前で値を引っ張るものってことだろ。
何もおかしいことはない。
720:デフォルトの名無しさん
07/10/16 14:42:06
どうしてわざわざオブジェクトに情報を詰めなおすのか
知っているか？
721:デフォルトの名無しさん
07/10/16 14:42:10
以前、このスレだか過去スレだかに、Map、Mapと騒ぐ奴がいたのな。
その流れを汲んでの話なんだよ。
自分で間違ったことを言っていないつもりなのだろうけど、
このずっと前からのスレの流れ的には空気読めてないんだよ。
しばらくROMってろ。
722:デフォルトの名無しさん
07/10/16 14:52:41
>>720
JavaがLightWeightじゃないから
723:デフォルトの名無しさん
07/10/16 17:47:29
>>721
それは知っているが、そんな昔の狂ったやつなんてもう今はいないだろう
Mapのように名前を使ってアクセスする場合何が問題だったのかだけがわかって使っていればおけ
VCLのようにラッパクラスをそのまま入れないこと、存在しないキーに対して
取得しようとしたときに例外を発生させることがきまっていれば問題はない
724:デフォルトの名無しさん
07/10/16 17:52:59
>>719
おまえの頭がおかしいということはわかった。
725:デフォルトの名無しさん
07/10/16 18:07:58
"存在しないキーに対して取得しようとしたときに例外を発生させる"
これが必要なのはなんで？
と思ったが、nullが戻ってきたんじゃデータが無いのか項目自体がないのかが判別できないのか
それ以外の理由もある？
726:デフォルトの名無しさん
07/10/16 18:48:26
そもそもDBにnull入れないほうがよくない？
727:デフォルトの名無しさん
07/10/16 21:53:40
そうか？
728:デフォルトの名無しさん
07/10/16 22:33:48
NULLが無いほうが楽ではあるかもな色々と
ただ、Oracleのような、空文字列がNULLであるようなDBMSではNULLを
避けようが無いだろう
729:デフォルトの名無しさん
07/10/16 22:41:00
NullはDBに必要だろ
730:デフォルトの名無しさん
07/10/16 22:42:28
(商用で)一番普及してしまっているOracleの仕様にはモニョるものがある罠・・・。
ただnullはアレで便利な面もあるので、ここらは宗教論だろう。
731:デフォルトの名無しさん
07/10/17 01:04:31
DBにNULLが全くいらないってのが
どんな状況かわからん。
732:デフォルトの名無しさん
07/10/17 02:44:06
Mapを使う時点で、静的型言語の利点を失っている気がする。
だったら、RoRのActiveRecordのほうがよっぽど使いやすい。
733:デフォルトの名無しさん
07/10/17 09:26:04
HOGE <> 1 な条件で、HOGE が NULL なレコードが取得できないのが
直感的じゃないと思うので、検索列には NULL は勘弁して欲しいところだ。
734:デフォルトの名無しさん
07/10/17 11:59:11
>>733
nullがほしいならnullもor条件いれればいいじゃない
直感的ではないというのは同意だが、SQLにとってnullは特別な値だから仕方がないか
735:デフォルトの名無しさん
07/10/17 12:11:08
検索の際の特別扱いだけでなく、
NULLありのカラムはインデクス張る際にも実装上の制約があったりするし、
単純にホスト言語のデータ型とマッピングする際にもやや面倒が生じるので、
少なくとも意味のあるデフォルト値が考えられるようなエンティティなら、
NULLの代わりにデフォ値突っ込んだほうが楽は楽な気がする。
ま、常にそうできるというわけでもないが。
736:デフォルトの名無しさん
07/10/17 12:23:44
むしろプログラム言語で3値論理をきれいに扱えないのがおかしい
737:デフォルトの名無しさん
07/10/17 13:08:35
C#のnullは3値論理だ
738:デフォルトの名無しさん
07/10/17 13:09:54
Javaなら3値普通に扱えるだろ・・・
739:デフォルトの名無しさん
07/10/17 15:11:51
C.J.Dateたんは第五正規形まで正規化すればnullなんていらんだろ派だね。
740:デフォルトの名無しさん
07/10/18 11:31:41
>>733
条件を () で括って最後に is true
741:デフォルトの名無しさん
07/10/21 11:43:49
Daoは1テーブルごとに1クラス作成して、CRUDのメソッドがあるのが普通なのでしょうか。
1:nのテーブルがあって、一覧を表示する詳細な検索画面などでどうしても結合が必要な場合や条件が複雑になる場合は
その画面専用?のメソッドを作成するものなのでしょうか。
742:デフォルトの名無しさん
07/10/21 16:28:16
というか、それはORマッパがやるだろ。
743:デフォルトの名無しさん
07/10/21 17:46:11
テーブル単位でCRUDってのは大概O/Rマッパがやってくれる
連結は製品次第
DBのようにテーブル状に結果が入るほうがいい場合もあるし
そのつど連結先を取ってくるほうがいい場合もあるしなんとも
744:デフォルトの名無しさん
07/10/21 18:06:18
DAOやORマッパは手段なのに、
目的の方を「どうするのが普通でしょうか？」って
おかしくね？
745:デフォルトの名無しさん
07/10/21 18:34:43
そういうヤツは、O/Rマッパの仕様に合わせてテーブル設計とかしそうで怖いよな。
COBOLerお得意の横長DBとか。
まあ、漏れは直でSQLゴリゴリ出来る人なので、条件・結合が複雑だったら
SQLを直書きではあるな。
746:デフォルトの名無しさん
07/10/21 21:12:53
テーブル単位でCRUDするだけがORマッパーの役割と思ってる奴多くね？
747:デフォルトの名無しさん
07/10/21 21:14:14
少ないと思う
748:デフォルトの名無しさん
07/10/21 21:39:36
>>539
って結局JSPで、DTOからコード値をgetして、
<% if (sex.equals("1") {%>男 ... (taglibとか)
みたいなのを書くってことでしょうか。
それともDTOにUser#getSexName、getSexCodeを自前で準備するものですか。
これだと自動生成が大変なのですが。。。
前にViewでマッピングしようとするとコネクションが切断？されてるから例外になったり、
マッピングを自動でするような機能がなかったりして断念したことがあるのですが。
749:デフォルトの名無しさん
07/10/21 23:47:14
>>748
その例外はO/Rマッパ依存の部分でしょ
たとえばJPAのリファレンス実装であるToplinkは参照専用のコネクションを開くので問題ない
それにリソースファイルで扱う場合も多いし、すべてアプリやライブラリなど実装次第としかいえんぞ
750:デフォルトの名無しさん
07/10/22 16:02:03
そこはentityにisMan()isWomen()を持たせたら？
751:デフォルトの名無しさん
07/10/22 19:55:03
>>748
定数値と表示名称のマップをアプリケーションスコープに保存して
ELでアクセスしたりとか
DBに持たせてEntityの2次キャッシュにしたりとか
色々方法はあると思う
752:デフォルトの名無しさん
07/10/22 19:57:38
俺はマップをアプリケーションスコープに入れる派
753:デフォルトの名無しさん
07/10/22 20:38:01
>DBに持たせてEntityの2次キャッシュにしたりとか
これってどういうことなん？詳しくお願いしたいかもー。
754:デフォルトの名無しさん
07/10/22 21:59:39
定数マスタとかをDBに持ってる場合
Hibernateなどの2次キャッシュ機能を使えば
アプリレベルでEntityを共有できる
これを通常のEntityと関連付けてLazyロードさせれば
Entityだけで名称表示を行える
まぁでも設定とか色々と面倒かも
755:デフォルトの名無しさん
07/10/22 22:36:37
>>754
おー、なるほど、どうもです。
756:デフォルトの名無しさん
07/10/23 01:30:51
O/Rマッパでキャッシングはデフォっしょ
やってないほうが少ないのでは?
おかげでLAZYが便利
ただ、hibernateではセッション明けとかないとダメかもね
757:デフォルトの名無しさん
07/10/23 21:41:49
キャッシングした場合、定数マスタかなんかが更新されるタイミングっていつになるのでしょうか。
例えば、DB直接いじって定数テーブル？に1行追加して、htmlの画面で<option>がふえてねーじゃん！てことにならない？