06/04/25 23:38:41
>>158
ひべるなーて
160:デフォルトの名無しさん
06/04/25 23:50:59
>>158
はいばーねいと、でいいんじゃないの？
161:デフォルトの名無しさん
06/04/26 00:59:50
冬眠って読むんだよ
162:デフォルトの名無しさん
06/04/26 14:39:18
>158
はぁい、ばーねいと！ （やあ、ばーねいと）
あい、ばーてぃす！（いいえ、わたしはばーてぃすです。）
163:デフォルトの名無しさん
06/04/26 14:48:17
カイ！ エ～ン ･ﾟ･（ﾉД`）･ﾟ･
164:デフォルトの名無しさん
06/04/26 14:52:21
ハーイバネット、ハーイバネットぉ～♪ 夢のハイバーネットたかたぁ～♪
165:デフォルトの名無しさん
06/04/26 19:14:12
Hibernateって、マッピングするときBean指定しないとダメなんですか。
ibatisではHashMapが使用できて、key=カラム名、value=値 で取得可能なのですが。
166:デフォルトの名無しさん
06/04/26 22:16:20
いや別にMapが欲しいだけならDbUtilだけでいいんだし....
167:デフォルトの名無しさん
06/04/26 23:13:32
だれかJavaドメインモデルの実践的な実装を解説した書籍を教えてください。
サービス、ドメイン、ＤＴＯ、エンティティなど単語はよく聞きますがＵＭＬ
図ばっかりの本がおおくて実際のソースコードで実感できるものを見たことが
無いので。。。
168:デフォルトの名無しさん
06/04/26 23:47:32
>>165
Mapでも取得可能。DOMのElementに値を詰めて返すことも出来る
169:デフォルトの名無しさん
06/04/27 00:02:01
ドメインモデルって難しい言葉を意識するから難しく感じるんであって、
要するにあれって「ただのまっとうなオブジェクト」ってことなんじゃないの？
「USERテーブルの行をロードしたデータ」じゃなくて、「ユーザー」という
「もの」を表したオブジェクトって考えようよ、というのがドメインモデルの
ベースにあるところじゃないかと。
オブジェクトだと考えたら、「ユーザーの登録を抹消する」なら「じゃあ
unregisterメソッドを読んだら抹消するってことで」と自然に思うじゃん。
裏でどんなSQL投げようが、ファイル読もうがセッションをごにょごにょ
しようが、抹消してくれればしったこっちゃないでしょう。それがオブジェ
クト指向ってもんだ。
ＤＢを前提に考えちゃうと「ユーザを抹消するってことは、まず関連付けられた
契約レコードをすべて抹消したあと、ステータスをごにょごぎょして、
ユーザーのレコードの削除フラグをオン。それを効率良くするには、関連
レコードをジョインして....」とか考えてしまって、それをそのままべたっと
コードに書いてしまいがち。
オブジェクト指向的には、ユーザーというオブジェクトの「抹消」という
命令を呼び出したら勝手にごにょごにょして抹消してくれりゃいいわけ
で、その抹消メソッドが裏で勝手に契約レコードを抹消してステータス
変更してくれりゃいいじゃん、それがオブジェクトってもんだろ？
契約だってオブジェクトなんだから、ユーザーオブジェクトの抹消メソッド
のなかで、契約オブジェクトの契約解除メソッドよべばいいじゃん。
ってのがドメインモデルじゃないかな。
↓さあ景気良くいこう
170:デフォルトの名無しさん
06/04/27 00:16:08
> ドメインモデルって難しい言葉を意識するから難しく感じるんであって、
> 要するにあれって「ただのまっとうなオブジェクト」ってことなんじゃないの？
おそらくそういうことなんだろうな～とは思ってるんですが、「サービス」とか
いうやつの位置付けがようわからんです。なんでも人によると「薄いのが良い」
とかいう意見を見受けますが”じゃなんなんだい！”みたいな
171:デフォルトの名無しさん
06/04/27 00:44:03
おれはサービス層については、下のような用途かなあと思う。
・業務的には複数のモデルにまたがった業務処理を一括して行うためにある。
例：発送処理 おそらく「商品」と「発送業者」と「在庫」くらいの複数のモデルが
関わる予感がする。
・プログラム的視点では、トランザクション境界を定めるためにある。
サービス層の一つのメソッド呼び出しが１トランザクションになるようにする、
という感じで。いろんなモデルをごにょごにょした結果、裏でいろんなＳＱＬが
走るわけだけど、それを一つのトランザクションにまとめる、という感じだろうか。
172:デフォルトの名無しさん
06/04/27 00:58:31
> ・業務的には複数のモデルにまたがった業務処理を一括して行うためにある。
> 例：発送処理 おそらく「商品」と「発送業者」と「在庫」くらいの複数のモデルが
> 関わる予感がする。
EntityやDAOの呼び出しロジックをサービスにまとめるってことで総括して良いん
でしょうか。もっとシンプルに言うなら、ビジネスロジックの担当がサービスなん
だっていうことなんでしょうか。
173:デフォルトの名無しさん
06/04/27 01:12:01
データベースアプリを組むときには、ほとんどドメインモデルは必要ない。
174:デフォルトの名無しさん
06/04/27 03:01:05
データベースアプリというのが何を指しているのかよくわからないが、
データベースを使ったアプリという意味なら、データベースを使ったアプリで
ドメインモデルを使わなけりゃいつ使うのかと。
175:デフォルトの名無しさん
06/04/27 03:23:22
>>172
１行目はそうだと思う。
２行目は微妙。たとえば売り上げオブジェクトの「未回収」メソッドを呼んだら
赤伝オブジェクトが生成されて、台帳オブジェクトに追加されるとしたら、
これは立派なビジネスロジックなわけだが、この処理を書くところはあくまで
「売上」オブジェクトであるべきだよな。
だって「未回収」メソッド呼んだら裏でごにょごにょやる内容が赤伝生成だったり
台帳更新だったりするわけで。
仮に台帳更新をしたらどっかの担当者にメールを送らないといけないとしても、
台帳の更新メソッドが呼ばれたら、メーラーオブジェクトの送信メソッド呼ぶように
してりゃいいわけで、結局外からみれば、売上の「未回収」を呼ぶだけで台帳に
赤伝が入って担当者にメールが飛ぶ、というビジネスロジックが実行される。
だったらロジック実行には売上オブジェクトだけあればＯＫだよな？
こんな感じで結構な数のビジネスロックはドメインモデル内で実行可能だと思う。
でも処理実行後に、たとえば現在の赤伝数とか、赤伝発行後の売上高だとか
を取得して画面に返さないといけないとしたら、これはあくまでウェブアプリ
ケーションの都合で実行するんであって、ビジネスロジックとは関係ない。
でも同じトランザクション内で赤伝数のカウントしたり、売上高計算したり
しないといけなかったりもする。
となると、サービスとして一つのトランザクション境界としてまとめるのが
一番やりやすいかなあ、と思うな。
まあでもぶっちゃけて言うと、Springとか使うとメソッド呼び出しと応答までを
トランザクション境界にする機能があって便利なんで、それを利用するためだ
けにサービス用意して、サービスを呼び出したら即モデルのメソッド一つ呼んで
終わり、なんてこともある。だってプログラム的にトランザクション制御する必要な
くて楽だからさあ。
176:デフォルトの名無しさん
06/04/27 06:41:15
O/Rマッピング使っていると、エンティティに情報があるんだから
ドメインモデルとしてロジックを書きたくなるんだけど
現在のDIコンテナは、ステートレスなトランザクションスクリプトを扱う方が便利だから
そこにちょっとしたズレを感じたりしている
エンティティにストラテジーをDI出来たりするO/Rマッピングツールが出たら便利そうなんだが
177:デフォルトの名無しさん
06/04/27 09:26:32
Hibernateの遅延ロードで質問
遅延ロードのときのSet型の中身を並べ替えすることは、mappingの定義（order-byアトリビュート)
でできるけど（実際、many側のデータを使った並べ替えはできた）、many側にひもづく別のクラスの
データを使って並べ替える事は可能？
A:B:C －＞ A:B=1:n B:C=n:1
Cの「並び順」フィールドの値でBを並べたい、みたいな感じ
178:デフォルトの名無しさん
06/04/28 14:22:22
>>168
すんません。
参考サイトとか教えていただけないでしょうか？
179:デフォルトの名無しさん
06/04/29 06:17:05
>>178
URLﾘﾝｸ(www.hibernate.org)
そういや、リファレンスの日本語版はいつまで経っても2.1.6のままだな
180:デフォルトの名無しさん
06/04/29 10:31:44
>>179
つ「言いだしっぺ必敗の法則」
ということで翻訳よろしくｗｗ
181:デフォルトの名無しさん
06/04/30 03:38:19
>>180
つ「言いだしっぺ必敗の法則」
それやると誰も何も言いださんくなるよ。
おれの前の会社がそーだったよ。
182:デフォルトの名無しさん
06/04/30 06:43:25
もともとNetNews（それもfj）とかの世界で人を黙らせるための
ものだからな＞言いだしっぺ
あれはある意味2chの対極にある世界だった。
183:デフォルトの名無しさん
06/05/01 00:51:28
>>181-182
つか、冗談だからｗ ちゃんと"ｗｗ"つけてるじゃん。
というか、前の翻訳は誰がやったんだ？
184:デフォルトの名無しさん
06/05/01 01:12:56
最近 2ch のせいで「www」とかいうアドレスをみると
笑えてくる。
185:デフォルトの名無しさん
06/05/01 15:15:45
>>184
人生楽しそうですね。
186:デフォルトの名無しさん
06/05/02 19:19:08
OpenJPA記念ｶｷｺ
URLﾘﾝｸ(incubator.apache.org)
187:デフォルトの名無しさん
06/05/02 23:31:28
すいません、.NETで申し訳ないんですが、質問させて下さい。
.NETでORMに詳しい人が集まってそうなスレが見当たらなかったもので・・・。
NHibernate Best Practices with ASP.NET, Generics, and Unit Tests
URLﾘﾝｸ(www.codeproject.com)
上のサイトのサンプルに、NHibernateでのOpenSessionInViewパターンの実装例があるのですが、
リクエスト開始時にbeginTransaction、リクエスト終了時にcommitTransactionとsessionCloseを行っています。
この作りだと、もしリクエスト中に例外が発生した場合、Transactionはどうなるのでしょうか？
JavaのFilterと全く同じ仕組みが無いのでこうしてるのかとは思うのですが、これで問題が無いのかどうかがイマイチわかりません。
一応、Session管理クラスの中を見ると、commit時に例外キャッチしたらrollbackするようにはなっているんですが、
Transaction中に例外が起きた場合にcommitが成功してしまうケースってありえないんでしょうか？
それともTransaction中に例外が発生した場合には、必ずcommitで例外が送出される仕組みなんでしょうか？
188:デフォルトの名無しさん
06/05/03 23:31:55
jarファイルの中のdaoからHibernateを利用しようと考えてるんだけど
マッピングxmlやhibernate.cfg.xmlって普通どこに配置するのがメジャー？
189:デフォルトの名無しさん
06/05/13 10:40:38
ibatisって、jspみたいに自作のタグを使用できないのでしょうか？
190:デフォルトの名無しさん
06/05/13 12:20:53
普通にjspのカスタムタグを使えばいいんじゃないでしょうか....
191:ＪＡＶＡ初心者
06/05/13 23:44:13
こんにちは。いつもいろいろ教えてくださいましてありがとうございます。
今日はＴＯＲＱＵＥに関する質問です。
ＴＯＲＱＵＥについて、まだ使用経験がないのですが、今度使わなくてはいけなくなりました。。。。
でも、なにせ資料が少ないので。。。。
ＤＢの中でプライマリーキー（ここではＩＤ）の一番大きい数をしるのは
そうやってやればいいでしょうか？
たとえば、ＩＤが今は１０番まで使われていたとして、その１０番というのを
知る方法が知りたいのです。ＳＱＬだと、ＳＥＬＥＣＴ ＭＡＸみたいなので
ＧＥＴできると思いますが。。。。。
よろしくお願いしますｍ＿＿ｍ
192:191
06/05/13 23:52:50
書き忘れました。
ここから誘導されてきました。
【初心者】Java質問･相談スレッド85【大歓迎】
ｽﾚﾘﾝｸ(tech板)l50
193:デフォルトの名無しさん
06/05/15 17:44:33
>>190
すいません。ちがいます。
sqlのxmlファイルに、ibatis用の拡張タグを使用できる仕組みになっているかを確認したかったです。
194:デフォルトの名無しさん
06/05/16 09:57:01
>>193
<!DOCTYPE sqlMap
PUBLIC "-//iBATIS.com//DTD SQL Map 2.0//EN"
"URLﾘﾝｸ(www.ibatis.com)">
195:194
06/05/16 10:07:24
連投ｽﾏｿ
SqlMapClientBuilder#buildSqlMapClientに
velocityを喰わせることは出来るかもね。
やったことないケド
196:デフォルトの名無しさん
06/05/17 00:40:11
いつも参考にさせていただいてます。
現在Javaで作成している基幹系アプリケーションで、ランタイム上で
テーブルの作成・修正・削除を行う必要があります。
この場合、O/R Mapping Frameworkは向かないでしょうか？
今のところ、JavassistなどでAnnotation付きのクラスファイルを生成して、
それをHibernateのConfigurationに動的に読み込ませれば良いのでは？
と考えていますが、まだ実現に至らずです。
どなたかノウハウをお持ちでしたら、ぜひ教えてくださいm(_ _)m
197:デフォルトの名無しさん
06/05/17 00:45:43
>>196
URLﾘﾝｸ(www.fk.urban.ne.jp)
198:デフォルトの名無しさん
06/05/17 09:45:07
>>196
> ランタイム上でテーブルの作成・修正・削除
ていうか何そのキチガイ設計。
キチガイが作ったのを引き継がされたの？
199:196
06/05/17 22:48:44
お二方、回答ありがとうございます。
>>197さん
提示していただいたリンク先の方法を確認しました。
生成したクラスコードからテーブルを自動的に生成する
必要があります。
そのため、この方法は利用できないと判断しました。
>>198さん
キチガイですいません orz
まだまだ勉強が足りないと痛感してます。
200:196
06/05/17 22:49:27
196です。
今回の案件では、ユーザが自由に編集できるクラスと
そのオブジェクトを永続化してRDBに登録するアプリケーションを
作成します。
クラス自体の生成、修正（継承先の変更等）、削除だけでなく、
クラスのフィールドの追加、修正、削除もサポートする必要が
あります。
クラスの編集によって、オブジェクトを格納するテーブルも
修正しなければいけないため、アプリケーション上で動的に
テーブルを操作する方法を質問しました。
できるだけO/Rマッピングツールを使うように言われていますが、
今回の目的だと、素直に動的にSQLを生成して操作した方が
良いような気がしており、エキスパートの方々のご意見を伺おうと
思いました。
個人的には、今回の案件だと、RDBMSの種類やバージョンに
よる方言を吸収して、コネクションプーリングなどを提供する
ツールなら何でもいいような気もしますが、中小の下請けなので
強く言い出せません orz
乱文長文失礼しました。
201:デフォルトの名無しさん
06/05/17 23:19:26
ユーザがクラスを動的に生成・変更できるってことは
バイトコード操作使いまくりか…
正直Javaでやるのが間違ってると思われ。いまからLispハッカー
探せ。奴らは毎日そういうことやってる。
202:デフォルトの名無しさん
06/05/17 23:20:31
((((((((((((；ﾟДﾟ))))))))))))ﾘｽﾘｽﾌﾟﾙﾌﾟﾙ
203:デフォルトの名無しさん
06/05/17 23:29:43
>>199
データベースさえcreate文で作ってしまえばいいんじゃねぇの？
そしたらあとはマッピングクラス生成してマッピングっていうのをやってくれて望みどおり
204:デフォルトの名無しさん
06/05/17 23:43:52
クラスをシリアライズしてvarchar2(4000)
くらいの列につっこむようにするとかは？
205:196
06/05/18 00:27:31
お騒がせしてます。196です。
>>201さん
すいません、>>200の説明で、大変な御幣がありました。
>今回の案件では、ユーザが自由に編集できるクラスと
>そのオブジェクトを永続化してRDBに登録するアプリケーションを
>作成します。
ここで言うクラスとオブジェクトはJavaのものではなく、OWLのものでした。
先方さんは、
OWLのクラス・インスタンス ⇔ Javaのクラス・インスタンス ⇔ DB
という処理を希望されています。
OWLだと、トリプルの構造をそのままテーブルに格納すれば良いと
思っていましたが、メインは検索処理でインスタンス数が多いそうで、
そのようなテーブルスキーマだと速度が出ないと判断しました。
206:196
06/05/18 00:37:18
連投すいません。196です。
>>203さん
DDLだけConnectionを直接取得してSQLで行うことも検討しています。
このとき、対応するマッピングクラスをConfigurationに設定した場合、
既にbuildされたSessionFactoryに変更を反映する方法が分かりませんorz
独自にFactoryの実装を行えば動作しそうな気もしますが・・・
>>204さん
BLOBにシリアライズしたクラスコードとオブジェクトを挿入することも考えました。
この場合、index用のデータをテーブルの別のフィールドに格納しておけば
検索速度も上がるのかなと思いますが、保守やシステムのアップグレードが
大変そうで躊躇しています。
相変わらず長文ですいませんorz
最近謝ってばかりだ…
207:デフォルトの名無しさん
06/05/18 00:49:24
OWL？ Lispハッカー以上に気の狂った世界に踏み込んでるな。
漏れにはわからん世界だが、RDBMSの性能のことならわかる。
いまのPCの性能で、行数が多すぎて性能が出ないなんて
話は猛烈なレアケース。
いろいろごちゃごちゃ理由がつくんだろうが、RDBMSはごちゃごちゃ機能を
つけてて、必ず対策があるようにできてる。RDBMSのマニュアル調べてみろ。
208:196
06/05/18 01:15:01
>>207さん
OWLのクラス階層の編集を可能とするため、上位クラスの変更を下位クラスにも
反映させる必要があります。
また、個々のクラスのインスタンス数は大したことはないですが、想定している
インスタンス数が全体で100万のオーダーであるため、それを一つのテーブルで
OWLのトリプル単位でばらして格納するよりは、クラス単位でテーブルを生成して
そこに持たせた方が良いのでは、と考えました。
（複雑なデータ型の問題ももちろんあります）
O/R Mapping Toolを使わずに、自前で作成した方が良いのかもしれません。
とりあえず、仕様を含めて、RDBMSをもう一度勉強しなおしてきます。
ご指摘ありがとうございました。
あぁ、今夜もクラス階層を構築している夢を見そう orz
209:デフォルトの名無しさん
06/05/18 01:21:21
ところでOWLってなに？
腹がよじれた失意体前屈？
210:デフォルトの名無しさん
06/05/18 01:56:02
Javaのインスタンスを生成する必要がわからん……
211:デフォルトの名無しさん
06/05/18 10:39:25
>>205
>OWLのものでした。
BC++のObjectWindows Libraryかと思った
212:デフォルトの名無しさん
06/05/18 13:05:54
>>194
本当にすいません。
タグはタグでも、<select>内に書ける<equal>などのタグです。
213:デフォルトの名無しさん
06/05/18 13:21:17
>>209
巨乳巨腹のorzです。
214:デフォルトの名無しさん
06/05/18 14:03:33
スキーマの緩いXML-DBを使った方がよかったりして。
215:196
06/05/18 22:14:30
>>210さん
OWLのクラスをJavaのクラスに、OWLのプロパティをJavaのクラスのフィールドに
見立てようと思っていました。
そうすると、OWLのインスタンスはJavaのフィールド値の集合で表せるかな、と。
>>211さん
OWLはWeb Ontology Languageの方です。
不注意で誤解を与えて申し訳ない。
>>214さん
今回は検索系がメインらしいので、XML-DBだと速度面が不安です。
先方さんの話をよく聞くと、各RDBMSのSQLの方言を吸収できて、かつノウハウが
多く得られるようなミドルウェアなら何でも良さそうです。
何かの記事で読んだC-JDBCとか気になりますが、スレ違いなのでやめておきます。
皆様、お付き合いいただきありがとうございました。
216:デフォルトの名無しさん
06/05/18 22:22:06
>>215
OWLってのの具体的な事は全くわからんが、
最初の３行が間違ってる気がするな。
217:デフォルトの名無しさん
06/05/18 23:33:54
性能要求が厳しいのにRDBMS依存を避けろ、か…
キチガイの相手は大変だな。
おそらく全部ぐだぐだになって成果物ゼロで終わると思うが、
金はしっかり取れよ。
218:196
06/05/19 00:29:06
196です。また来てしまい、すみません orz
>>216さん
OWLのクラスとプロパティのそれぞれに、独自のAnnotationをつける仕様なので、
（１）OWLのクラスのAnnotation用テーブル
（２）OWLのプロパティのAnnotation用テーブル
（３）OWLのクラスとOWLのプロパティの対応情報テーブル
（４）各クラスのインスタンス用テーブル（カラム名は各プロパティ名）
の４種類のテーブルを作成するように設計しました。
大学出立てで経験が浅いので、どの辺がマズいかはわかりませんorz
>>217さん
汎用性と性能は両立しないのは分かっていますので、そこそこのものを提供しようと
思っています。
情報収集の最中に発見したのですが、Seasarファウンデーション傘下のTuigwaaが
Hibernate使用＆DDLサポートとなっていました。
ダイコン？とかよく分からないですが、参考になるかもしれないので今週末の休みに
ソースを読んでみようと思います。
219:デフォルトの名無しさん
06/05/19 00:36:42
>>218
＞OWLってのの具体的な事は全くわからんが
おまえ日本語読める？
220:デフォルトの名無しさん
06/05/19 00:53:12
>>219
顧客がイカレてるせいで、こいつもおかしくなってるんだろう。
金だけはしっかり取れよ。
221:デフォルトの名無しさん
06/05/19 01:15:22
>>159
ヒルベルト変換、ヒルベルト包絡線を思い出した
222:デフォルトの名無しさん
06/05/19 01:44:03
何が悪いとはっきり言うつもりはないが、もうちょっとまともに検討しないと大火災になるぞ、そのプロジェクト。
223:デフォルトの名無しさん
06/05/19 01:51:03
もうなってるようにしか見えないっす
224:デフォルトの名無しさん
06/05/19 02:19:36
LDAPとかのがまだマシなような。
225:デフォルトの名無しさん
06/05/19 10:31:23
何から何まで不毛な要件で、かつゴールもなんら魅力が無いと来た。
世の中色んな案件あるんだね。
226:デフォルトの名無しさん
06/05/19 14:11:21
dbutils結構いいかも。
227:デフォルトの名無しさん
06/05/19 14:56:26
Mapに詰め込むだけでもMappingといやーMappingだが
228:デフォルトの名無しさん
06/05/19 22:42:45
Beanに詰めることも出来るよ。一応。
229:デフォルトの名無しさん
06/05/19 23:15:35
ちんこがBeanBeanでつ
230:デフォルトの名無しさん
06/05/19 23:51:15
〃∩ ∧＿∧
⊂⌒（ ・ω・） はいはいわろすわろす
｀ヽ_っ⌒/⌒ｃ
⌒ ⌒
231:デフォルトの名無しさん
06/05/27 13:38:21
Cayenneで部分読みしたいんですがどうすればわかりません。
サンプルが落ちているところをご存知の方いませんか？
232:デフォルトの名無しさん
06/05/27 19:56:18
>>231
SelectQueryのsetPageSize()じゃ用途に合わないのかな？
Cayenneのページにサンプルがあるよ。
URLﾘﾝｸ(www.objectstyle.org)
233:231
06/05/29 11:43:03
>>232
サンクス
見てみます。
234:デフォルトの名無しさん
06/05/31 14:58:57
参照系だけの場合、HibernateとJDBC直書きとどっちがパフォーマンスいいですか？
キャッシュの設定によってはHibernateのが早かったりする？
235:デフォルトの名無しさん
06/05/31 19:46:51
ストアド化しろ
236:デフォルトの名無しさん
06/05/31 22:47:03
つうか素でHibernateのほうが速いだろ。
237:デフォルトの名無しさん
06/06/01 01:50:11
それはほとんどない。
238:デフォルトの名無しさん
06/06/01 22:10:42
どういう設定をしたら参照がJDBCより遅くなるのかと。あらゆる局面で
lazyオフでキャッシュなしか？
239:デフォルトの名無しさん
06/06/01 22:27:56
>>238
いくつかは考えられるだろ。
・最初の一回目の検索の場合（Hibernateが該当するオブジェクトをまだロードしていない状態）
・ストアドプロシージャを呼び出す場合（Javaアプリ側でなんとかするより、ストアド使った方が速い場合が多い）
240:234
06/06/03 00:48:56
みなさんレスありがとうございます。
ちなみに、バッチ処理で1回のみですがテーブル全件舐めたりします。
1回きりの場合だとHibernate導入するメリット無さそうですね・・・（パフォーマンス面で）。
ストアドである程度書いてJDBCで呼ぶってのが理想的みたいですが、ストアドで作るとメンテできん！って怒られます。
バッチでストアド無しでパフォーマンス高くする手ってなんかないですかね～・・・。
241:デフォルトの名無しさん
06/06/03 11:17:37
バッチ処理でHibernateを利用する理由はほとんど無いな。
242:デフォルトの名無しさん
06/06/03 15:39:34
O/R-Mappingでやってることって、結局
・バックグラウンドでSQLを作って投げる
・返ってきたresultsetをbeanに自動的にマッピングしてcollectionに詰めて返す
が本質だよね？
そう考えると、DbUtilとかでも十分なのかな。。。
うちの会社、こういう新しい？技術とかの導入に消極的だし、
新しい知識を積極的に勉強しようっていう技術者も少ない。。。
個人的にはiBATISあたりがよさげなんですが、使ってる人いますか？
243:デフォルトの名無しさん
06/06/03 16:15:01
キャッシュとか遅延ロードが主なメリットじゃない？
244:デフォルトの名無しさん
06/06/03 16:38:13
関連テーブルの紐付けが嬉しい。
245:デフォルトの名無しさん
06/06/03 16:46:05
今一これの利点が分からないんだけど
いちいちXMLとかに定義しないと使えないわけ？
extends MySQLObjectとかしてささっとプロパティだけで完結して欲しい。
246:デフォルトの名無しさん
06/06/03 17:12:28
>>242
関連テーブルを自動的に取ってきてくれるという重要な機能が
あるでしょ（これはDbUtilにはない）。
247:デフォルトの名無しさん
06/06/03 17:15:40
>>245
つ 無定義Hibernate
URLﾘﾝｸ(www.fk.urban.ne.jp)
俺の場合はCayenneを使ってＤＢのDDL作成とマッピング定義作成を
Cayenne Modelerで同時にやっちゃうので、ORマッパーを使ったからと
いってそんなに負荷は変わらない感じ。
248:デフォルトの名無しさん
06/06/03 17:25:55
最近はどこのO/Rマッパーもテーブルからのクラス自動生成機能持ってる
ＪＰＡ使えばXMLファイルはもういらない
249:デフォルトの名無しさん
06/06/03 17:33:59
>>247
ふーん。いいね、組み込みDBとかで気軽に永続化できるようになると
ゲームとかも作りやすくなっていいかなぁ
250:デフォルトの名無しさん
06/06/03 19:05:00
>>245
MiddlegenでもXDocletでも、Hibernate Annotationでも、好きなの使え。
251:デフォルトの名無しさん
06/06/08 22:05:18
JPAの解説記事少ないなあ。
みんなxmlでしこしこやってるの？
252:デフォルトの名無しさん
06/06/08 23:30:24
>>240
いまPro EJB3を読んでるところだと思われ。
でもなんでそこでxmlが出てくるのかわからない。
253:デフォルトの名無しさん
06/06/09 10:14:29
>>251
Java Persistence APIってなんなの？
254:デフォルトの名無しさん
06/06/09 10:26:06
ORまっぱの仕様
255:デフォルトの名無しさん
06/06/09 11:20:29
>>254
jspタグライブラリでも使用できるらしいけど。
ってことは、jspでＤＢアクセス用ってことか・・・。不要じゃん
256:デフォルトの名無しさん
06/06/09 16:54:17
それはJPAを使うタグライブラリのこと
JPAの仕様とは関係ない
JPAは、HibernateやTopLinkを元にしたO/Rマッピングの標準仕様のこと
257:デフォルトの名無しさん
06/06/10 18:42:38
>>255
JSPタグライブラリにJDBCタグライブラリがあるが、JDBCはJSPでDBアクセス用か？
258:デフォルトの名無しさん
06/06/10 20:18:24
そう。
259:デフォルトの名無しさん
06/06/11 13:51:28
アホな流れになってるな。
子供か！！
260:デフォルトの名無しさん
06/06/11 16:52:36
そう。
261:デフォルトの名無しさん
06/06/13 22:09:47
Hibernate2xで関連テーブル使ってmany-to-manyでマッピングしてる時、bagとかのwhere属性で関連先のテーブルのカラムに対する条件って書けますか？
普通にカラム名と条件書くと関連テーブルにそんなカラムねーよ！！って怒られちゃうんですが・・・。
262:デフォルトの名無しさん
06/06/14 07:18:09
能動的にコーディングできるってだけで、O/Rマッパーはチューニングに向いてないんだな
263:デフォルトの名無しさん
06/06/14 09:18:08
少なくとも、困ったときに直にSQL書いて実行できるようなフレームワークじゃないと、
使えないなあというか使うの怖いなあ。
まあそのときだけJDBC使えって話はあるけど。
264:デフォルトの名無しさん
06/06/14 10:19:43
Hibernateは問題ないな。
265:デフォルトの名無しさん
06/06/14 10:26:34
>>263
ibatis
266:デフォルトの名無しさん
06/06/14 11:37:06
でも直に書けるフレームワークは、普段から直に書く様に成って、後で困る罠。
267:デフォルトの名無しさん
06/06/14 17:14:33
>>266
そういう開発者、いそうだね。特に新規に導入するとき、わからない→直書きってされそう
268:デフォルトの名無しさん
06/06/14 23:34:39
でもハマった時の最後の手段として、SQLとかJDBC APIとかとも上手く連携してくれるのがいいなぁ。
プログラマとしては逃げたくなくても、サラリーマンとしてそういう手段に逃げちゃう時が多々あるんで・・・・・・。
269:デフォルトの名無しさん
06/06/17 11:50:26
Hibernate3とEJB3、これから作るシステムに入れるならどっちがおすすめ？
270:デフォルトの名無しさん
06/06/17 11:51:43
今までどおりの使い分け
271:デフォルトの名無しさん
06/06/17 11:57:00
ゲームで使えそうなORMはHibernateくらいかい？組み込みたいのでオススメを聞きたい
272:デフォルトの名無しさん
06/06/17 14:51:30
>>269
EJB3を使ってJPAの実装としてHibernateを利用
273:デフォルトの名無しさん
06/06/17 14:52:33
>>271
つうか、これからはJPAという標準になるんだから、ゲームで使うくらいならTopLinkもHibernateも大差なかろう。
274:269
06/06/18 01:32:50
>>270
今までEJBって使った事ないんですが、使い分けってどんな基準ですか？
>>272
なるほどー。
使い分けってよりJPAの実装としてHibernateを選択って感じなんですね。
275:デフォルトの名無しさん
06/06/18 02:45:06
>>274
いままで使ってなかったのはEJB2
EJB3とは別物。
ORマッピング使うなら、EJB3で十分。
実質的にはHibernateの仕様がEJB3になったわけだから、EJB3とHibernateをどう使い分けるかということが、そもそもナンセンスということになる。
276:デフォルトの名無しさん
06/06/18 02:57:00
>>275
リモートで呼び出せるかどうかのみ違う。
使い分けはそこだけかな。
277:デフォルトの名無しさん
06/06/18 03:02:14
JPA仕様とそれぞれのORマッパーって結構違うんじゃない？ Hibernateについては同感だけど。
たとえばCayenneもJPAをサポートするといって準備しているけど、Cayenneの
発想とJPA(Hibernate)のやり方（というか考え方）って結構違うように思う。特に
トランザクションを意識させない設計とか、どうすんだろ、と思う。
TopLink(Grassfishに組み込みのやつ）とかはどうなんだろうか。
278:275
06/06/18 03:47:22
>>277
HibernateもCriteriaとかProjectionとかがEJB3に取り入れられてなくて残念なんだけど、ORマッピングのプログラムインタフェースの部分だけを見ればJPA準拠ならHibernate互換ということになるんじゃないかな、と思ってます。
279:275
06/06/18 03:53:08
>>277
重箱の隅だけど、GlassFishね。草みたいな魚じゃなくて、ガラスみたいな魚。
TopLinkは、JPAの実装として使う限りでは、個性を感じない。
もちろん、どのJPA実装も、JPAの実装として使う限りでは個性を感じないというのは当たり前の話ではあるんだけど。
280:デフォルトの名無しさん
06/06/18 05:50:23
パフォーマンスの差とかあるのかな？
281:275
06/06/18 08:08:21
それぞれの固有の機能を使わない限りは、無視できるほどの違いしかないと思う。
でも実測値がほしかったら、実サーバーで確認するのんが確実
282:デフォルトの名無しさん
06/07/03 23:13:24
Hibernateが特許侵害だとよ。
URLﾘﾝｸ(japan.cnet.com)
>テキサス州の連邦地方裁判所に今週提出された訴状によると、
>原告のFireStar Softwareは、JBossのHibernate 3.0が同社の
>「オブジェクト指向ソフトウェアを用いた、リレーショナルデータベースの
>リンクに関する特許」を侵害していると主張しているという。
283:デフォルトの名無しさん
06/07/04 01:49:42
>>282
特許侵害しているとして訴えられただけだろう。
まだまだ一方的な主張の段階。
「特許侵害だとよ。」は風説の流布に当たるおそれがあるから注意。
断定は判決が出てからに汁。
よくあるアメリカ流のふっかけ・ゆすりと推測してみる。
うまく行けば和解金ふんだくれるもんな。
284:デフォルトの名無しさん
06/07/04 21:10:50
時給１０００円でＪａｖａ教えてくださるかたを募集します
場所 所沢（池袋・高田馬場から直通）
ｉ－ｗａｎｔ－ｔｏ－ｓｔｕｄｙ－ｊａｖａ＠ｈｏｔｍａｉｌ．ｃｏ．ｊｐ
（アドレスは全角で書いてあるので半角に直してください）
よろしくおねがいします
285:デフォルトの名無しさん
06/07/04 23:56:57
>>281
すでに「おい、そのころには既にEOFがあったわけだが。
そのEOFにすら先行技術があるんだが？」と冷静なツッコミが
入っとるよ。
286:デフォルトの名無しさん
06/07/05 05:13:30
BerkeleyDB Java Editionつかってます
287:285
06/07/05 09:03:31
アンカーミスった。
>>282
だった。
288:デフォルトの名無しさん
06/07/10 22:01:42
SimpleORM
URLﾘﾝｸ(www.simpleorm.org)
whitepaperを眺めてみたらいい感じ。
クラスに定義したメタデータからテーブルを作ったりできるらしい。
新規開発にしか向かないかな？
289:デフォルトの名無しさん
06/07/17 21:22:59
教える対象は超初心者です。
専門学校などでJavaを勉強されていて夏休みだけ教えたいという方も歓迎です
290:284
06/07/17 21:28:22
教える対象は超初心者です。
専門学校などでJavaを勉強されていて夏休みだけ教えたいという方も歓迎です
291:284
06/07/17 21:46:20
いきなり缶詰ー＞架空請求スパムの送信
292:デフォルトの名無しさん
06/07/18 01:36:11
亜米利加の特許は先発明制だから、いくらでも先行特許あるよ。
293:デフォルトの名無しさん
06/07/18 03:38:48
>>290 = >>291
自分でマルチして、自分で突っ込んでる
294:デフォルトの名無しさん
06/07/18 18:28:56
HibernateのHQLで select sum(*) の返り値を
IntegerじゃなくてLongで取得したいのですが、いったいどうすれば…
295:デフォルトの名無しさん
06/07/18 20:19:24
>>293
IDも出ない板でよく言うよ
296:デフォルトの名無しさん
06/07/19 01:07:07
>>294
URLﾘﾝｸ(opensource.atlassian.com)
3.2での対応になる
297:デフォルトの名無しさん
06/07/19 02:32:50
>>296
ありがとうございます
丸一日、試行錯誤してしまいましたが
3.2.CR2入れることにします…
298:デフォルトの名無しさん
06/07/22 09:36:29
知らぬ間にこんなの追加されていた。
アノテーションにSQLを書くみたいだが。
URLﾘﾝｸ(download.java.net)
299:デフォルトの名無しさん
06/07/22 11:01:44
BeehiveのJDBC Controlみたいな感じか。
300:デフォルトの名無しさん
06/07/23 02:09:26
俺も同じようなコンセプトの Object/SQL mapper を作っているのだけれど、標準に搭載されるようじゃ用無しだなこりゃ。ｱﾊﾊ
こういうのなんだけどさ。
@SQL(value = "SELECT * FROM dept", bean = Dept.class)
public abstract List<Dept> readAll();
@SQL(value = {
"UPDATE emp SET salary = salary - {#arg[2]} WHERE id = {#arg[0].id}",
"UPDATE emp SET salary = salary + {#arg[2]} WHERE id = {#arg[1].id}",
}, type = TYPE.UPDATE
)
public abstract void moveSalary(Emp from, Emp to, int price);
完成したら公開しようと思っていたのだけれど、微調整したら公開しちゃおう。ｴﾍﾍ
301:デフォルトの名無しさん
06/07/23 09:05:28
>>300
標準のは、CachedRowSetを使っていて、CachedRowSetはJDBCドライバの対応が
必要だから、存在価値としてないわけじゃないと思うけどね。
しかし、どうせなら誰か.NETのDataSetをそのまま実装して欲しいな。
NinjaVAが実装しているけど、DataSetのソースが5000ステップくらいあるのと
微妙に違うので、いまいち使いづらい。
302:デフォルトの名無しさん
06/07/26 23:40:17
>>300
公開期待してます。
303:デフォルトの名無しさん
06/07/28 00:40:27
Hibernate Annotationで質問があります。
簡単なサンプルを作成して実行してみたところ以下のようなエラーが出ました。
Exception in thread "main" org.hibernate.MappingException: Unknown entity: sample.Employee
そこでhibernate.cfg.xmlから<mapping package="sample"/>と<mapping class="sample.Employee"/>
のタグを削除してnew AnnotationConfiguration().configure().addClass(Employee.class)と
したところ問題なく実行できました。
この場合どこが悪くて最初の方法で実行できなかったのでしょうか
使用したライブラリのバージョンは下のやつです。
hibernate-3.2
hibernate-annotations-3.2.0.CR1
304:300
06/07/28 01:33:19
とりあえずサンプルをちゃんと動くようにして、上げました。
BSD License です。
URLﾘﾝｸ(sourceforge.jp)
すいません、ドキュメントが一切ないです。サンプルのソースを見て下さい。
ognlとcglibが必要です。
こちらでは以下のバージョンで動かしています。他で動くかはわからないです。
サンプルを動かすには hsqldb が必要です。1.8.0 を使っています。
cglib-nodep-2.1_3.jar
ognl-2.6.7.jar
まだ無い機能、やってないこと
ログを取る機能
しっかりしたエラー処理
HSQLDB以外での動作確認
ドキュメントを書く
もっとしっかりしたサンプルを書く
ソース内のコメント
SQLの中の {#arg[0]} の部分。ここの {} の中に ognl が記述できます。methodの引数が arg という配列に入ってます。
305:300
06/07/28 01:43:02
補足事項
hsqldbで
CREATE TABLE dept (
id INTEGER NOT NULL IDENTITY,
name VARCHAR NOT NULL,
PRIMARY KEY(id)
);
としていて、
INSERT INTO dept (name) VALUES ('name');
としたら、id列に値が自動で入ります。
この時id列に入った値を、取り出してbeanにセットしようとしています。
id列に入った値を取り出す方法が、RDBMSによってマチマチ？なようです。
で、とりあえず、SQLアノテーションのtypeというパラメータで使い分けるようにして、
INSERTした直後にCALL IDENTITY()とやって、その値をセットする方法を、CREATE_IDENTITY
PreparedStatementでINSERTしたあと、PreparedStatement#getGeneratedKeysする方法を、CREATE_GENERATE
INSERTしっぱなしでbeanに値を入れるのを放棄する方法を、CREATE
としてますので、使う人は使いわけて下さい。
IDENTITYを設定した列が2コあったらどうなるんだ？とか、まとまり切っていませんので。
306:300
06/07/28 01:44:30
始めてオープンソースでソフトを公開しました。
ドキドキしています。
307:デフォルトの名無しさん
06/07/28 01:54:41
早速パクって儲けさせていただきました。無料で公開してくれてありがとう。
308:デフォルトの名無しさん
06/07/28 08:15:21
>>304
乙！
と思って、早速いろんなDBで動作確認…と思ったら、
リリース物件もソースコードリポジトリも空っぽですよ？
309:300
06/07/28 08:23:51
俺のアカウントからなら見られるのに……
俺sf.jpの使い方わかってないぽいので、しばしお待ちを……
スレ汚してすいません。
310:デフォルトの名無しさん
06/07/28 09:41:06
>>300
頑張れ。君に期待している。
311:デフォルトの名無しさん
06/07/29 00:47:50
>>300
私も期待しています。
頑張ってください。
312:デフォルトの名無しさん
06/07/29 01:58:50
>>308
DL出来るようになってるみたいだね
313:デフォルトの名無しさん
06/07/30 04:53:44
sfはリリースしてから実際にDLできるまでにラグがあるらしい
314:ストーカー
06/08/03 01:49:49
URLﾘﾝｸ(crudfactory.sourceforge.jp)
こんなんできてるYO!
315:デフォルトの名無しさん
06/08/03 11:29:37
メモリに入りきらないぐらいの巨大なテーブルをSELECTして、一件ずつ処理したいと思っています。
Hibernateを使おうかと考えていますが、ネットの入門を見ている限りSELECTした結果を一気に取得しているようです。
全件一気にオブジェクト化するとメモリが足りなさそうなのですが、こういう用途はJDBC使って1件ずつ取り出した方が良いんでしょうか？
316:デフォルトの名無しさん
06/08/03 11:56:03
1件ごとにSELECTすると効率が悪いから
何十件かまとめてSELECTするよろし。
それにそもそも、巨大なテーブルを全部変更するなら
ストアドプロシージャのほうが圧倒的に効率がいい。
317:315
06/08/03 12:48:31
書き方が悪かったですね、申し訳ないです。
SELECT * FROM TABLEして全件取得して、ResultSet.next()で1件ずつ処理したいって事なんです。
Hibernateの入門ページ見てると、検索結果がListで一気に戻ってきているようだったので。
つまり聞きたいのは、検索結果全件を一気にオブジェクト化するとメモリが足りないので、
検索結果全件の中から1件ずつオブジェクト化して処理できないかな？って事です。
ListのgetやIteratorのnext時にオブジェクト化されていたら問題なさそうなんですか。
って書いてたら聞くより本なり読んでちゃんと理解してから判断した方がいい気がしてきた・・・。
318:デフォルトの名無しさん
06/08/03 13:24:03
>>713
素のJDBCだと 一方向に読み込み専用 で取得すると
一気には取ってこないみたいだね
319:315
06/08/03 16:36:42
>>318
それをO/RマッピングでやってみたいんですがやっぱJDBC使わないとダメなんでしょうかね。
ふむむ、できないとしたら分割してSELECTするなり工夫が必要かぁ・・・。
320:デフォルトの名無しさん
06/08/03 16:52:08
>>315
Hibernate使ったこと無いけど、lazy initializationを有効にすると
取得したコレクションからオブジェクトを取得するときまで
インスタンス化を遅らせることができるそうだ。
URLﾘﾝｸ(www.hibernate.org)
つうかドキュメント読め。
321:315
06/08/03 17:14:37
>>320
おお、良い感じですね。
問題はいらなくなった読み込み後のオブジェクトがちゃんとゴミ掃除されるかどうかだけど・・・とりあえずいろいろ読んでみます。
㌧クス!!
322:デフォルトの名無しさん
06/08/07 18:33:15
Beanて、テーブル毎に一つ作るものでしょうか？
INSERT目的なら全カラム必要になるだろうけど、
SELECT目的なら一部のカラムのみで十分なケースってあると思うんです。
例：
BOOKというテーブルはID、名前、著者名、カテゴリ情報、概要等、
本に関する情報を多数持っているが、
検索結果に表示するのは名前だけで十分、という場合。
この時ID、名前以外の情報まで持ってくるのは非効率な気がするのですが、
このSELECT目的に別にBeanクラスを定義するというのはアリでしょうか。
class Book { 全カラム }
class BookForSearchResult { ID, 名前 }
それとも、この程度の効率はO/Rマッピングを使用する以上、
気にしない方がいいんでしょうか。
323:デフォルトの名無しさん
06/08/07 19:15:38
>>322
どうしても気になるのなら、IDと名前だけのビューを作って、
そのビューとBeanをマッピングしたらどうでしょう？
324:デフォルトの名無しさん
06/08/08 01:42:02
hibernate使ってたけどいろいろ面倒くさくなってきたのでCommonsDbUtilsに戻してしまった。
なんかすがすがしい気分になった。
325:322
06/08/08 11:09:26
>>323
なるほど、ビューを対象にするなら違和感ないですね。
カラムを限定するようなケースが発生するのは大概検索画面なので、
わざわざビューを作る、というのもアリが気がします。
ありがとうございます。
326:デフォルトの名無しさん
06/08/08 19:12:24
OJB 1.0.4を利用しようと思ってソースとバイナリを取ってきて
動かそうとしているのですが、junit test suiteがFailureを出します。
WinXP (SP1)
JDK 1.5.0_06
lib等は、
antは1.6.5を別途導入。junit.jarはojb1.0.4のをcopy
DBはデフォルトのhsqldb (入手したママ)
でるFailure (1件のみ)
testReportPathExpressionForExtent2
check size expected:<2> but was:<0>
(その他実行結果のファイルにはNOT_EXISTテーブルがないとかもでている)
OJBのドキュメント等やMLも読んだのですが、junit testについては
(hsqldb)についてはそのまま動くとのことで、どう修正すれば
動かせるのかどうかわからなくて困っています。
ここでいいのかどうかわからないのですが、よろしくお願いします。
327:デフォルトの名無しさん
06/08/09 00:20:58
まだ見てるかわからんが、HibernateならScrollableResultsがある。
ResultSetと同じようなカーソル的な使い方ができるので、
適度にevict()しながら処理すればいいと思われ。
328:デフォルトの名無しさん
06/08/17 18:09:46
正直O/Rまっぱーの利点がわからん。
簡単な表結合ならSQL書いちゃったほうが早いし
難しい表結合はO/Rまっぱーじゃ結局無理だし。
なにがいいのか俺にもわかるように説明してくれ。
DTO自動で作るだけならエクセルマクロで十分だし。
329:デフォルトの名無しさん
06/08/17 18:22:18
そのエクセルマクロ生成コードにむかついた人が張り切ってしまって
できたのがO/Rマッパー。
むかつかない人はそのままでいいよ。
330:デフォルトの名無しさん
06/08/17 18:29:30
＞簡単な表結合ならSQL書いちゃったほうが早いし
ORMの利点は、「SQLを書かなくていい」ではない。
＞DTO自動で作るだけならエクセルマクロで十分だし。
それを「車輪の再発明」と言う。
ダメエンジニアが行う愚行の一つ。
331:328
06/08/17 18:32:31
>>330
で、結局利点はなんなのでしょうか（＾＾；
332:デフォルトの名無しさん
06/08/17 18:35:56
>>329
個人の趣味で使うものってことでしょうか？？
仕事で使うもんじゃないってことでFA?
333:デフォルトの名無しさん
06/08/17 18:42:12
>>331
オブジェクトとSQLのマッピング作業をフレームワークがやってくれる点。
334:デフォルトの名無しさん
06/08/17 18:43:03
>>329のレスから>>332のような結論が出る時点でDQNエンジニア確定だな。
335:デフォルトの名無しさん
06/08/17 18:46:33
ぶっちゃけ俺DQNエンジニアだとおもう。
まっぱーの利点とか理解できないし。
だから教えてくださいお願いします。
>>333
マッピングってDTOつくって、ResultSetから値を取り出してDTOに入れていくってことですか？
ただそれだけですか？
そこでそんなにバグが出たり工数がかかったりしてるんですか？
336:デフォルトの名無しさん
06/08/17 19:01:57
>>335
検索だけじゃなくて、挿入・更新のときのマッピングもね。
DQNかも知れないエンジニアを大量に使わざるを得ないプロジェクトで、
テーブル数が数十個ある場合で、カラムの追加変更などがある場合でも
フレームワークにやらせるよりも手作業の方が早くて確実なら使う必要はないだろう。
337:328
06/08/17 19:10:21
それだけしか利点がないならやっぱ内の会社にはいらないのかもしれない。。
ほんとにそこでみんな困ってるの？？？
そのあたりって仮にまちがえてもテスト段階でバグ発見しやすい部分だと思うし
そもそもDTOに入れたり出したりするのなんてそんなに大変な作業でも
ないとおもうんですが・・・。
うちのシステムもテーブル150ぐらいあるし、
カラムの追加変更もときどきあるけど
一度に追加変更されるのって2、3テーブルぐらいのものだし
それだけのためにxml書いたりといった面倒な作業が
工数的、費用的ににペイするのかしら？？
あたらしいもの好きな人たちが趣味でやってる領域なのでは？
実際に業務に使ってるひといるの？？？
338:デフォルトの名無しさん
06/08/17 19:25:27
XMLファイルを手書きしてたらメリットは感じないたろうね。
トータルの記述量はあまり減らないし、かえって面倒と感じるだろう。
そこは自動生成するところだよ。
339:デフォルトの名無しさん
06/08/17 19:32:14
ORM=XML設定ファイル必須というわけでもない。
S2DAOや、Hibernate Annotation、EJB3はXMLによるマッピング不要だ。
340:328
06/08/17 19:39:49
XMLをテーブル定義から自動作成する工数と
DTOなど自分でコーディングする工数
システム開発全体にかかる工数から比較したら
これらが締めるのは微々たるものでは？
341:デフォルトの名無しさん
06/08/17 19:51:09
＞XMLをテーブル定義から自動作成する工数と
＞DTOなど自分でコーディングする工数
ちがう。
テーブル定義からXMLとDTOとを自動生成する工数と
DTOを自分でコーディングおよびSQLとDTOの値の受け渡し処理の
コードを書く工数とその部分をテストする工数の合計だ。
後者の方が早くて確実なら使う必要はない。
342:328
06/08/17 19:54:00
その2つだけをくらべたら後者のほうが遅くて不確実なんですが
OR mapperに潜んでいるバグのリスクや、
各OR mapperの使い方を覚える工数を考えたら
やっぱ使わないって判断かなあ。
そもそもわざわざ導入したところで削減できる工数が少なすぎるような気が。
あんだけ雑誌やネットで騒がれておきながら
メリットってこんだけなの？
なんかほかにメリットないのかしら・・。
343:デフォルトの名無しさん
06/08/17 19:54:11
そう感じてて、それで本当にいい！ ノープロブレム！
って思うなら、それでいいじゃねえか。
俺はDTOを自分で書くなんて冗談じゃねえが。
Hibernate Annotationでハッピーライフ。
344:328
06/08/17 19:57:38
いや、どう感じるかは問題ではなく
客観的な指標から判断して
どちらが生産性の向上につながるのかが知りたい。
なんでこれだけのものにみんな大騒ぎしてるんだろう？
なんかあるのでは？って思ってしまう。
345:デフォルトの名無しさん
06/08/17 20:02:51
生産性にまともな測定方法なんてﾈｰﾖ
むかつくやり方を続けると、精神衛生に悪くて生産性が下がる。
それだけ。
346:デフォルトの名無しさん
06/08/17 20:35:55
＞OR mapperに潜んでいるバグのリスク
おまいのところがGavin Kingより優秀な開発者を抱えてるならリスクとなり得るなｗ
347:デフォルトの名無しさん
06/08/17 20:47:21
>>345
それは真理だな。
>>344
なんにもないから安心しろ。
頑張って車輪を発明し続けてくれ。
348:デフォルトの名無しさん
06/08/17 21:04:21
>>346
マジレスすると、Kingよりも優秀な奴が一人いてもダメだと思う。
HibernateやS2DAOがどれだけの人に動作検証されているのかを考えると、
それ以上の動作検証ができて、はじめて
「OR mapperに潜んでいるバグのリスク」が自作コードより大きくなると言える。
349:デフォルトの名無しさん
06/08/17 21:37:15
>>348
自作コードの方が普通は仕様が小さいから、
同程度の品質を確保するのにそこまでの動作検証は要らないけどね。
350:デフォルトの名無しさん
06/08/17 22:30:32
ORマッパには、いままでの長い期間で発見されたパフォーマンス
改善手法がデフォルトで組み込まれている。
ORマッパの大部分は関連テーブルのレコードを自動的に取得
できる。
百人がよってたかってデバッグしたコードと、どっかの中小企業が
自分たちのしょぼいプロジェクト用に作って二人か三人でデバッグ
したコードでは、前者の方が信頼性が高い。
ただし１テーブルのデータちょっと取ってくるだけ、しかもテーブル間
リレーションもほとんどない、毎回SQLをコンパイルさせる程度の
負荷などまったく気にしない、とかなら別に使う必要はなし。
351:デフォルトの名無しさん
06/08/17 22:36:31
大量のデータをinsertするような、バッチ的処理には向いてないね。
あくまで、オンライントランザクション処理を簡易化するためのフレームワーク。
万能ではない。
352:デフォルトの名無しさん
06/08/17 23:09:32
まずはテーブルの構造からO/Rマッパー的に作る必要がある。
それができないプロジェクトは、リプレースするか、捨てるか。どっちかしかない。
353:デフォルトの名無しさん
06/08/18 00:54:27
>>328
とりあえず何か動かしてみたりはしたの？
Hibernateなら、ツール使えばスキーマ読み込んで勝手にクラス作成までやってくれるから
一度適当に使って試してみたら？
結局ツール適用のメリット有無なんて、対象システムや開発環境との相性だからな
354:デフォルトの名無しさん
06/08/18 01:31:01
>>176
忘れた頃に禿同
オレもエンティティにビジネスロジックを書きたくなってしまう。
GRASPじゃないけど、OO的に考えるなら、データに近いところへ
メソッドを寄せ集めておきたいんだよな・・・
自動生成されたエンティティをサブクラスするのはちとキモイしねぇ
355:デフォルトの名無しさん
06/08/18 07:19:44
>>176,354
＞自動生成されたエンティティをサブクラスする
ちょっと意味不明だけど
任意のクラスを継承したエンティティを自動生成できるツールがほとんどだよ
356:デフォルトの名無しさん
06/08/18 07:48:13
>>355
クラス継承によるロジック共通化をフレームワーク単位で行うと、クラスの拡張性が著しく損なわれるので
最近は避けられる傾向にある
最近DIコンテナを使った開発で多用されているのが、委譲による疎結合。
その場合はステートレスなロジッククラスが利用される。
これとドメインモデルとの相性がイマイチなのがORマッピング利用時の問題
ORマッパー自体がDIをサポートして、ロジックを委譲するオブジェクトを注入してEntityを作成することが出来れば
ドメインモデルでも疎結合でロジックを構築できるのでは？・・・という話
357:デフォルトの名無しさん
06/08/18 08:00:02
>>356
>>354からそこまで読み取れたらネ申だな。
358:デフォルトの名無しさん
06/08/18 08:42:51
>>176を先に読めよｗ
359:デフォルトの名無しさん
06/08/18 18:56:37
iBATIS2.2.0(β)
360:デフォルトの名無しさん
06/08/19 00:12:40
あれ？
iBATIS2.2.0って、ストアドプロシージャと
Beanとのマッピング出来るようになったん？
361:デフォルトの名無しさん
06/09/05 02:43:56
ついに1000体突破かよ
アイロボットみたいだな
株ロボもいつか夢を見るようになるのかなぁ
362:デフォルトの名無しさん
06/09/06 11:11:38
貼っとく
[ThinkIT] 第7回：それぞれのメリット／デメリット (1/3)
URLﾘﾝｸ(www.thinkit.co.jp)
363:デフォルトの名無しさん
06/09/08 15:08:40
質問なんですが
Hibernateでsessionキャッシュ上の永続オブジェクトに対して
オブジェクト単位での変更チェックは出来ないんでしょうか？
bool Session#isDirty(Object o, ...)みたいなものがあればいいのですが...
364:デフォルトの名無しさん
06/09/26 00:45:24
キましたね。iBATIS。
ストアドプロシージャとBeanのマッピングOK。
サンプル書いて確認とれました。
sqlMap.queryForObject(query, map);
ArrayList list = (ArrayList)map.get("out");
for(int i=0; i<list.size(); i++){ Bean bean = (Bean)list.get(i); bean.getId();}
SpringFrameworkと連携するときは使えないかもしれないけどね。
とりあえず、Map（HashMap）->ArrayList->Beanの順に格納されているので、
１コ１コ取り出さないといけないのがメンドイ。
つーか instanceofで確認取らせんな！( ﾟДﾟ)ｺﾞﾙｧ!!
365:デフォルトの名無しさん
06/09/26 01:16:45
あいばてぃす？
あいべいてぃす？
366:デフォルトの名無しさん
06/09/26 01:26:28
いーばてぃす
367:デフォルトの名無しさん
06/09/26 01:36:02
URLﾘﾝｸ(ibatis.apache.org)
ここ読むと
>We pronounce it: eye-BAT-iss
ってあるから、あいばってぃす？
368:デフォルトの名無しさん
06/09/26 02:22:18
シンクイットって登録しないと読めないから資料価値ない。
グーグルキャッシュに入らないマイコムにも言えるが。
エクセルマクロ生成コードにむかついた人が張り切ってしまってできたのがO/Rマッパーなのはいいが、漏れはO/RマッパーのXMLファイル作成にムカつくのはどうすれば良い？
誰かエクセルマクロからXML生成するツール作ってない？
つーかxlsファイル自体を読み込んでO/Rマッピングしてくれってのが、.NETのノリ？
369:デフォルトの名無しさん
06/09/26 02:44:42
＞誰かエクセルマクロからXML生成するツール作ってない？
当然みんなつくってんじゅねぇーの？
一々仕様書から写す手間を考えるとそりゃマクロで吐き出させるだろうし。
こういうのってオープンソースで一個作っちゃったほうがいいよーな気もするよな。
370:デフォルトの名無しさん
06/09/26 08:09:54
作ったらOSSとして公開でいいんじゃない？w
371:デフォルトの名無しさん
06/09/26 13:10:33
ソースはどこにうpされてるの？
372:デフォルトの名無しさん
06/09/26 20:32:49
会社で作ってて、パッケージ名までcom.なんとかになってるから、
さすがに公開はできんわｗ
373:364
06/09/26 21:23:18
SpringFramework + iBATIS でのPL/SQL連携を確認。
つーかさ、DBの問い合わせから戻ってきた値が
<parameterMap>のclass要素のオブジェクトにマッピングされるのはいいんだが、
public List findList(String query, HashMap map)throws DataAccessException
{ return (List)getSqlMapClientTemplate().queryForList(query, map); }
↑のコードの意味無いじゃん。↑のメソッドを ArrayList list = (ArrayList)dao.findList(query, map);
で呼び出すんだけど、結局引数に渡したmapオブジェクト変数に格納し直されるっていう動作はどーなのよ。
いいの？これ。
どーいう意味かの解説は URLﾘﾝｸ(canetrash.seesaa.net) にあるんだが、動作的にねぇ…？
結局引数に渡したmapからListを取り出して、さらにBeanを取り出して…。
メンドクサーですよ。O/R-Mapperってこんなんなん？いや、動作的にはO/R-Mappingなんだろうけどさ。
識者コメント＆ツッコミ・キボンヌ。
374:373
06/09/26 21:46:39
あー、でも URLﾘﾝｸ(www.h7.dion.ne.jp)
見ると
--------------
sqlMaps で SQL を実行する時のパラメータとして使えるクラスには次のものがあります。
・Bean
・Map
・プリミティブクラス（Integer など）
--------------
ってなってるから、だめだ。Map or Beanじゃないと。orz
375:デフォルトの名無しさん
06/09/27 07:55:54
O/Rマッパーじゃないけど、RailsのMigrateみたいなDBのバージョン管理できるJavaプロダクトって何かありますか？
あーゆーの欲しい。
376:デフォルトの名無しさん
06/09/29 01:08:11
>>368
blancoDb だろ。Excel O/R マッパー。
俺はそれを作ってる、いがぴょんっていう奴の顔がキモすぎて
試してもない。違うんかもしれんが。
377:デフォルトの名無しさん
06/10/07 04:01:15
やっぱHibernate最高ですよね？
うちの会社に導入しようと思っています。
いまどきＪＤＢＣでＳＱＬ直書きなんて氏ねばいいと思います。
378:デフォルトの名無しさん
06/10/07 04:23:21
導入前に氏んでいるわけだな。
379:デフォルトの名無しさん
06/10/07 08:56:57
>>377
Hibernateがいいときもあるし、JDBCでSQL書きがいいときもあるし、iBatisがいいときもある。
最高ではない。
380:デフォルトの名無しさん
06/10/07 09:48:02
まあいまどきJDBCのようなところはとりあえず入れたほうがいいな。
見聞を広げるちゅー意味でも。
381:デフォルトの名無しさん
06/10/07 11:13:58
同意。
Hibernate最高とか言っちゃわない程度には触っておいたほうがいいな。
382:デフォルトの名無しさん
06/10/07 11:46:24
適材適所。「最高」なんてものは無い。
383:377
06/10/08 10:47:35
いや、Hibernateは上級レベルの達人たちが
ものすごい工数をかけて作成したフレームワークだ。
Hibernateありきだ。
最初に。
もちろんHibernateではダメだというケースも
あるとは思うが、まずはHibernate最高と思っておいて
問題ないのでは？
384:デフォルトの名無しさん
06/10/08 11:14:28
JDBC APIだって上級レベルの達人たちが
ものすごい工数をかけて作成した仕様なのだが・・・
385:デフォルトの名無しさん
06/10/08 11:25:44
妄信してる信者の発言にしか聞こえない。
結局はどれが良いのか客観的に語ってよ。
386:377
06/10/08 11:26:36
いや、Hibernateも内部でJDBCを使っている。
どんなシステムでも大抵、JDBCを利用するための
フレームワークを作っているだろうが、
そういうフレームワークとしてHibernateに
勝てるわけがないということだ。
387:デフォルトの名無しさん
06/10/08 14:01:29
うちなんてHibernateどころかServletすら使えないよ
DBまわりはWrapperがあるけど
BroadVision6...
388:デフォルトの名無しさん
06/10/08 14:15:17
＞そういうフレームワークとしてHibernateに
＞勝てるわけがないということだ。
すげぇ盲信っぷりにﾜﾛﾀ。
389:デフォルトの名無しさん
06/10/08 18:44:47
まあ言い方はあれだけどｗ、
日本の会社が自社で作っていたものとは次元が違う存在というのは言うまでもない。
すべてのケースに適しているとはいえないが、
使ったこともないじゃORマッパーを語れないな。
俺はjar（というか使ってるクラス）があまりにも多すぎるところがいやだな。
入れたら起動も死ぬほど重くなるし、OutOfMemoryにもなりやすい。
サーバーにいくつもHibernateを使ってるWebAppがあったら目も当てられない。
390:デフォルトの名無しさん
06/10/08 19:11:56
そんな貧相な鯖で Java を動かすこと自体が間違ってる。
391:デフォルトの名無しさん
06/10/08 23:17:11
フレームワークは目的ではなく手段。
無駄な残業したくないなら要件にフィットするものを選ぼう。
冷静に、冷静に。
392:デフォルトの名無しさん
06/10/09 01:04:59
あれこれ選び分ける程の余裕もスキルもありません。
可能な限り「標準」で行きたいのだけど。
JPAはしばらく安定しないだろうなぁ・・・
393:デフォルトの名無しさん
06/10/09 03:36:02
>>386
Hibernate に詳しいようだから、使ってみた感想でいいから
他のいくつかの O/R マッパーと比較して何かいいか
教えてくれないか？
俺には何がいいかさっぱり分からんので。
394:デフォルトの名無しさん
06/10/09 04:56:36
まずいエサだがスレの内容には沿ってるな＞393
Hibernateのよさは、資料が多いことだな。
俺はCayenne > Hibernateだと思う。複雑なクエリを
HQLで書くのは俺には無理。
395:デフォルトの名無しさん
06/10/09 05:56:46
>>393
質問がO/Rマッパーの有用性は
396:デフォルトの名無しさん
06/10/09 06:29:22
ごめん、途中で送信した
O/Rマッパーの有用性はわかるけど、Hibernateの優位性がわからないのか
O/Rマッパーの有用性がわからないのか、どっちなんだ
前者ならJPA実装の中でも枯れてるしData Mapperパターンでは決定版に近いってレスになるし、
後者なら、そうですねってレスになる
397:デフォルトの名無しさん
06/10/09 11:29:44
O/R マッパー自体の有用性が分からない、つーのはスレ違いじゃね？
有用性があるのが前提で、優劣を議論するのがスレの趣旨じゃね？
398:デフォルトの名無しさん
06/10/09 19:50:13
>>397
適用範囲を把握するという意味では、
有用性自体を問うのもありだと思ふなり
399:デフォルトの名無しさん
06/10/14 10:05:46
ド短期製造、お前らなら何使う？
製造期間 10 日、マスタメンテ 3 機能。
DB 設計済み（複合キー）、検索条件は可変多し。
製造担当はたぶん JDBC 直以外知らない。
学習工数、製造工数の少なさを最優先。
JDBC 直、Hibernate、iBatis、DBUtils、、、
400:デフォルトの名無しさん
06/10/14 10:20:46
＞製造担当はたぶん JDBC 直以外知らない。
＞学習工数、製造工数の少なさを最優先。
10日間に学習工数も含めるのなら、断然JDBC直。
フレームワークは学習コストがそれなりにかかることを
認識しておかないと痛い目を見る。
それを認識できてない奴が「生産性が低い」と騒ぐんだ。
強いて何か覚えるなら、ORMよりもDbUnitでも覚えておいた方がいいんじゃね？
401:デフォルトの名無しさん
06/10/14 14:16:27
>>399
MS Access
402:デフォルトの名無しさん
06/10/14 14:50:21
短期なのに学習コスト込み？てか１０日？
ギャグのつもりじゃなかったらやめたほうがいいだろう。
403:デフォルトの名無しさん
06/10/14 15:28:56
>>399
JDBC 直
404:デフォルトの名無しさん
06/10/14 16:47:16
JDBC直よりは、closeし忘れとかを防止する意味で、
DBUtilsの方がいいんじゃない？
まあ、10日であることを考えたらJDBC直でもいっか。
悩んでいる暇があったら、早くやれって感じだ。
405:デフォルトの名無しさん
06/10/14 17:31:45
JDBC直でResultSetMetaDataとDatabaseMetaDataをひっぱって
全テーブル同じクラスで処理する。
406:デフォルトの名無しさん
06/10/14 18:07:12
>>399
JAVA止めて、お前がLLで作る
407:デフォルトの名無しさん
06/10/14 23:48:22
仮に実装担当者が「色々とORM知ってます」と言ってきても
ちょっとしたもんならJDBC直（or 学習コストがかからん DbUtils）で十分。
後々メンテ担当者がチェンジする時のリスクも小さかろう。
408:デフォルトの名無しさん
06/10/14 23:57:44
>>400
DbUnit も知らんとか言ってたな。
一応、俺が Struts 上にアクセス制御、セッション管理、ログ、エラー制御あたりの
共通部を 2 日ぐらいで俺が作って後は任せようかと思ってる。
Click か Wicket も考えたけど 10 日じゃこわいんでやめとこうと思ってる。
>>402
俺はフリーで複数案件やってて60 万で案件とろうとしてるだけだ。
60 万ぽっちじゃ、10 日ぐらいでやらんと割りにあわんだろ。
部下の勉強がてらに良いと思ったんだけど意見を聞きたかった。
>>404
JDBC 直で close し忘れ防止は Session in View パターンで
ServletFilter でも作るわ。
>>405
結果は Map に格納すんの？ リフレクションで Bean？
昔作ったような気もするけど、それだったら何かあるやつ使うかなー。
409:デフォルトの名無しさん
06/10/15 00:08:49
>>408
勉強がてらなら、もっと納期が厳しくない案件でやらせた方がよくない？
確実に作らせたいのなら、担当のスキルと日程をふまえて指示する側が見極めないとな
あと、DbUtilsにするんなら、1.0は色々問題があるからdevelop版を使ったほうがいい。
410:デフォルトの名無しさん
06/10/15 00:33:13
可変長の引数が可能ですが、引数取り出しの扱いがわかりません。
function! AllRead(...)
while args
r args
endwhile
endfunction
どうすればいいでしょうか？
411:デフォルトの名無しさん
06/10/15 00:50:59
>>409
thx。DbUtils か JDBC にするわ。
412:デフォルトの名無しさん
06/10/15 00:52:05
>>410
何のハナシをしているのかわかりません
413:デフォルトの名無しさん
06/10/17 13:36:28
Hibernate 3.2.0 GA
Hibernate Annotations も Hibernate EntityManager も同時に 3.2.0 GA
414:デフォルトの名無しさん
06/10/17 18:53:38
ガッはなんだガッは
415:デフォルトの名無しさん
06/10/17 23:30:51
Generally Available
416:デフォルトの名無しさん
06/10/18 00:07:08
>>414
ぬるぽ
417:デフォルトの名無しさん
06/10/22 21:05:50
以前ibatisで使った開発のときテーブルごとのクラスに結果を詰め込むようにしてたんだけど
結合テーブルのSQLなんかのとき都度それにあった結合テーブルクラス（必要なカラム以外もすべて定義）を使って結果を返していた
つまり結果は絶対SQLのと同じ表形式だったわけなんだけど
普通そういう設計するの？
418:デフォルトの名無しさん
06/10/22 21:10:26
複合キーのテーブルの場合代理のキーを作ってDB設計したほうがHibernateとかでは使いやすい
と同僚が言ってた。代理キーはシーケンスで振っていくようにするといってたけど
そうすっと一意制約が保障できないような気がするが、回避方法あるのかい？
419:デフォルトの名無しさん
06/10/22 21:19:31
>>418
UNIQUE制約ってしってるか？
PRIMARY KEYとは別にUNIQUE制約をかければいいだけだよ。
420:デフォルトの名無しさん
06/10/22 22:18:09
>>419
そりゃそうだ。なんできずかなかったんだろ。ありがとござんした
421:デフォルトの名無しさん
06/10/22 22:18:15
>>418
一意になるように代理キーで、作るべきだと思うけど。
422:デフォルトの名無しさん
06/10/22 22:19:52
ああ、勘違いした。複合キーが一意であることね。
ごめん
423:デフォルトの名無しさん
06/10/22 22:23:01
>>417
例えば、どうなってほしいの？
クラスを作るのが面倒ならば、Mapを使ってもよいと思うが、そうなるとタイプセーフではなくなる。
424:デフォルトの名無しさん
06/10/22 22:56:42
>>423
あーたとえばですね、親子関係のテーブルなんかの場合
親テーブルクラスに、子テーブルクラスを保持するフィールドもたせて
クエリーの結果をそういう感じで保持すんのかな？とおもって。
425:デフォルトの名無しさん
06/10/25 23:30:26
Hibernate で直に SQL 発行して結果を
Map のリストで受け取ることってできますか？
Hibernate を使わなければならず、
でも結果は Map で返さんとだめで、
entity クラスも作成できないんです。
426:デフォルトの名無しさん
06/10/25 23:31:47
保守
427:デフォルトの名無しさん
06/10/26 00:59:39
>>425
たぶん駄目じゃない。
Spring使ってるならJdbcTemplate。ないならDbUtilsでごまかしとけば。
428:デフォルトの名無しさん
06/10/26 01:38:43
>>427
助かりました。
JdbcTemplate#queryForList
でごまかせるような気がします。
429:デフォルトの名無しさん
06/10/26 02:16:00
>>425
Mapによるマッピングには対応している
URLﾘﾝｸ(www.hibernate.org)
430:デフォルトの名無しさん
06/11/02 00:22:59
dbutils 1.1 ってまだ開発中？
使いたいのだけど、1.0はだめだって聞いたんだけど。。
他のがいろいろでてきたからもう開発ストップしてるんかな。
431:デフォルトの名無しさん
06/11/02 02:12:45
>>430
dbutils、シンプルで使いやすいから愛用してるんだけど
あんまり使ってる人いないのかな？
432:デフォルトの名無しさん
06/11/02 03:48:26
何故だか各種ORMと比較されてショボイと思われてる感はあるかも。
個人的にはQueryRunnerがPreparedStatementを
基本、隠蔽する方向になってるのが何だか惜しいって印象。
まあ、そうしてもらうと楽な面も、もちろんあるんだけど。
433:デフォルトの名無しさん
06/11/03 02:24:54
>>431
俺も愛用している。
設定ファイルいらずだし、MapListHandlerの結果をJSP内のELで使うと超ラクで気に入ってます。
434:デフォルトの名無しさん
06/11/03 08:33:31
dbUtils、いいんだけどBeanHandler使うときのフィールド名とプロパティの
マッピングが普通とちがうのがちょっとなぁ。あれは直してくれんかな。
435:デフォルトの名無しさん
06/11/03 14:55:01
>>434
普通と違う？
436:デフォルトの名無しさん
06/11/03 18:02:24
booleanのときとか？
437:デフォルトの名無しさん
06/11/03 21:53:02
>>434
フィールド名/プロパティ名が2語以上から成るとき、DBでは通常アンダースコア連結、
Javaはキャメルケースで表記するでしょ？
他のORMにはそこを変換してくれるものもあるけど、dbUtilsは単にcase-insensitiveで
比較するだけだから、
SELECT ID_DATA AS IDDATA
とか、
public void setId_Data() {
とか書かないといけない。
438:デフォルトの名無しさん
06/11/03 22:48:00
DbUtilは、キャッシュも遅延ロードも無いし、
commons BeanUtilsのリフレクション使いまくりだから、目に見えて遅い。
大規模・高負荷なシステムでは使えない。
けど、シンプルで俺は好き。
自社のお問い合わせ送信フォームとか、
小規模なマスタメンテとかで使ってみたことがある。
439:デフォルトの名無しさん
06/11/03 23:38:04
ORM使ったこと無いので教えてください。
DbUtils以外のORMはリフレクションを使わずに、Beanにどうやって格納したりしているの？
キャッシュが高速なのは分かるのですが、逆に古いデータを読んでしまうことにならないかも気になります。
440:デフォルトの名無しさん
06/11/03 23:53:58
>>439
キャッシュとDBの同期化をどうするかというAPIも用意されている場合も多いので
アプリケーション側でも制御できるし、デフォルト設定も変更可能な多い。
リフレクションを使わず、バイトコードをゴニョゴニョしたりするフレームワークも多い。
441:デフォルトの名無しさん
06/11/03 23:57:27
>>439
＞キャッシュが高速なのは分かるのですが、逆に古いデータを読んでしまうことにならないかも気になります。
何か勘違いしてるんじゃないか。
442:デフォルトの名無しさん
06/11/04 00:37:41
>>440
バイトコードを変えることで、リフレクション使わずにセットしてたりするのか。
それは知らなかった。かなり高度なことをしているんだな。
>>441
こう考えているんだけど、勘違いしてると思った点を教えてくれれば幸い。
キャッシュを使えば、DBにアクセスすることなく、取得済みのデータを再利用するので、高速だと思っている。
「古いデータを～」と思ったのは、データがすでに更新されたのに、
更新前のキャッシュデータを使ってしまうことがないのか？ということを気にしている。
なんか間違ってるだろうか。
443:デフォルトの名無しさん
06/11/04 00:42:51
＞「古いデータを～」と思ったのは、データがすでに更新されたのに、
＞更新前のキャッシュデータを使ってしまうことがないのか？ということを気にしている。
ここの意味がよくわからん。
ひょっとして、複数のサーバでそれぞれ同一DBに対して
接続するとか、そういう使用法を考えてるわけ？
444:デフォルトの名無しさん
06/11/04 01:01:50
>>438
DbUtils から BeanUtils への依存関係はないんじゃない。
445:デフォルトの名無しさん
06/11/04 01:04:14
>>443
>>444じゃないけど、普通は考えるでしょ。
446:デフォルトの名無しさん
06/11/04 01:07:56
>>444
すまん。勘違いしていたらすい。
リフレクションAPI直叩きだね。
447:デフォルトの名無しさん
06/11/04 01:07:56
複数のサーバとは限らないけど、1つのDBに対して、複数の接続が発生するのが普通では？
キャッシュってのは、DBの複製的な情報を、アプリ側で保持するわけでしょ。
検索→キャッシュ生成→（他スレッドなどがDB更新）→キャッシュの値は更新前の値のまま
もちろん、ORMを使わず更新するとかが、論外なのは分かっているけど。
ここまで書いてきて気づいたのだけど、
1つのDB接続セッション内で、キャッシュされるのかと思ったけど、
全体でキャッシュを共有して持っているということ？
それならば、「更新前のデータを見ない」という意味は、理解できる。
448:デフォルトの名無しさん
06/11/04 01:30:13
そもそも>>443みたいな設計がおかしいんじゃないか？
それともEJBのことを指しているのか？だとしたら意味が違うと思うが
449:デフォルトの名無しさん
06/11/04 01:31:24
＞検索→キャッシュ生成→（他スレッドなどがDB更新）→キャッシュの値は更新前の値のまま
~~~~~~~~~~~~~~~~~~~~~~~
これ何よ。こんなことするなよ。
450:デフォルトの名無しさん
06/11/04 01:34:37
アノテーション使えるDbUtilsが欲しい…
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)