Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.4
2 ：
デフォルトの名無しさん：2005/12/16(金) 11:56:08
２げと？
とりあえず立てた。あとはﾖﾛ
ﾉｼ
5 ：
デフォルトの名無しさん：2005/12/16(金) 13:09:16
Mapping-Framework使いの皆さんに聞きたいんですが、
今回、Java⇔Oracleで、基幹システム(見積、受注、発注、出荷、在庫など)を
組むことになったのですが、
こういうのって意外と顧客独自な複雑な仕様があるので、テーブルもすごい何十個とかあります。
全てのテーブルのMappinngクラスを作ったりするもんなんですか？
複数テーブルとリレーション組んだりする時もその都度Mappinngクラス作るんですか？
なんか、結局SQL文コードに埋め込む形になっちゃいそうなんですが・・・
実際どうなんでしょうか？
>>7 通常は、クラスを自動生成したりするツールがあるので、テーブルの数はあまり問題じゃない。
問題は、顧客独自な複雑な仕様のほうだろ。それがO/Rマッパーでサポートできるかどうか。
というか、O/Rマッパー使うときは、O/Rマッパーを使うという前提でテーブル設計しないとつらいことが多い。
一般には、楽できるO/Rマッパーほどテーブル設計の自由度が低く、逆に自由度が高いO/Rマッパーだとあんまり楽にならない。
>複数テーブルとリレーション組んだりする時もその都度Mappinngクラス作るんですか？
O/Rマッパーによる。
あるシステム会社で、
.NETだったが、O/Rマッパーして、自動生成されたクラスがあるのに、
実際は、そのまま。SQL発行して、ﾚｺｰﾄﾞｾｯﾄみたいなものを使って取得してたりしてた。
こういのだけは、カンベン
10 ：
デフォルトの名無しさん：2005/12/22(木) 21:23:10
ホシュ
11 ：
デフォルトの名無しさん：2005/12/23(金) 17:56:04
EJB3のEntityManagerで、INSERTするときに、値にCURRENT_TIMESTAMPのようなSQLから取得する値を加えることは可能ですか？
値がnullのときにinsertに加えないようにする設定があったような気がする
13 ：
デフォルトの名無しさん：2005/12/24(土) 10:20:18
>>7 基幹システムって時点でテーブル何十個じゃすまないだろう。
基幹システム作った経験無ければ、パッケージに品。
15 ：
デフォルトの名無しさん：2005/12/24(土) 13:55:50
>>12 INSERT INTO HOGE（HOGE1, HOGE2, INSERT_DATE) VALUES (?, ?, CURRENT_TIMESTAMP)
のようなSQL文をpersistで作らせるのは無理でしょうか？
ほんとにいつも悩ましいのは、
複合キーでER設計するか？
楽観排他制御をサポートしているか？
ネイティブのSQLを使うか？
今んとこ、Hibernateがもっともトラブルが少ないね。俺のプロジェクトでは。
17 ：
デフォルトの名無しさん：2005/12/25(日) 13:04:36
ZEKEってどーなんだろ。
未踏のやつ。
18 ：
デフォルトの名無しさん：2005/12/25(日) 21:41:07
現在MySQL ＋ HibernateのWebアプリケーションがあり、
これをOracle10gに移行しようとしています。
MySQLではPKを自動インクリメントで取得していますが、
Oracleではシーケンスになるので、
MySQLで
<generator class="identity" />
ってなってるところを
<generator class="sequence">
<param name="sequence">シーケンス名</param>
</generator>
としてやればよいのでしょうか？
19 ：
デフォルトの名無しさん：2005/12/28(水) 02:11:48
>>19 原著が出たのは結構前なので、やっぱりHIBERNATE 2.xベースの解説なのかな。
3.xへの補足も入っているとうれしいんだけど。
ibatisがキャッシュしてしまう問題で、
sqlmapのflushDataCache()メソッドを使用したのですが
キャッシュが消えずに、２回目のsqlでエラーになってしまいました。
キャッシュを削除する方法はないでしょうか？
>>21 selectの抽出項目を条件により動的に変更する、を言っているの？
どうやらibatisではだめなようだね。
rezultクラスをHashMapにしても、最初のクエリーの項目が残り、
次回のクエリーで、初回の項目と違うとエラーになります。
Builderで再ビルドすれば、全てクリアできるので問題なし。
１クエリごとに生成するので大変だが・・・
one-to-one がまともになる予定ある?
>>24 remapResultとはどのようなことでしょうか。
名前から推測すると、多分その設定によるものだと思います。
ちょっと調べてみます。
>>26 ああ、バージョンは2.0.9以降じゃないとダメみたいで。
マッピングを作成するときに、一番手軽(作成するものが少ない)で、
一番メンテナンスしやすい(修正のほとんどが設定ファイルなど)のは
ダントツでibatisで間違いなし？？？
Cayenneもやればできる子
>>29 ただし既存のテーブルには弱いが。
Hibernateでも、自分で作成するものは少ないし。
>>29 カナ～リ大きなXMLを管理する覚悟は必要。特にテーブルの数が多い時。
29です。ibatis派です。
sqlはすばらしい言語なので、プログラムではsqlのすばらしさを邪魔しないフレームワークが
一番賢いと考えています。
つまり、sqlで対応できるところは、ロジックではなくsqlを修正する。
そのsqlの修正は、設定ファイル内のsqlそのものだけ、が一番よいと思います。
そのほうがsqlとjavaの特徴を最大限に引き出せるし、メンテが楽です。
俺は簡単かどうかに関係なく、クラスの数が多いのは好きではないです。
マッピング処理の為にクラスを作成するのは納得できないです。それが自動生成できるものだとしても。
いろいろなマッピングツールを見ましたが、特にEJBはひどいと思いました。簡単なことを複雑に考えようとしているし。
クエリの結果データをbeanにマッピングするたびにクラスを生成するツールは好ましいと思いません。
どうでしょうか、この意見
> sqlはすばらしい言語なので、
この仮定に同意できない。
>>34 リレーショナルデータベースさわるのにはとてもいいと思う。
リレーショナルモデルもきっちり作りこまれてるので、かなりいい。
>>33 > 特にEJBはひどいと思いました。
EJB2までの話。
> マッピングするたびにクラスを生成する
クラスは生成せんだろ。
型保証とIDEによる補完を考えると、Javaの場合はテーブルに対応するクラスがあったほうが楽だしメリットも大きいと思われ。
SQLの外だしにこだわるなら、HibernateやEJB使うときでも外出しにすればいい。
36 ：
デフォルトの名無しさん：2006/01/06(金) 10:37:14
>>33 ドメインモデルの設計をビシィとやる。もちろんその時は
RDBMSの存在など微塵も意識しない。
さて実装を考える段になって、既存のRDBMSの設計を
見ると、ドメインモデルと合致しない。
俺はiBATISが本領を発揮するのはこういう時だと思う。
だから、
＞マッピング処理の為にクラスを作成するのは納得できないです。
もしこれが『DB設計にクラス設計が影響されるのは納得できん』
ということなら君の意見に賛成する。
iBATISはDBとOOのミスマッチをSQLで吸収可能だからね。
>>35 HibernateやEJB３って、ibatisみたいにsqlをかけるのでしょうか。
独自のSQLだと思っていたのですが。古い情報ですか。
>>36 まさにその通りです。
sqlとjavaクラスの間に物理的な依存性を持たせるのは危険だと思いっています。
その依存性を切り離すのがまさにibatisなのかなぁと。
sqlそのものの結果をクラスに好きなようにマッピングできるのですから、すごい。
というか、ibatisが普通の考え方だと思うんですよね。
なんか、javaはより難しく考える傾向にあるような・・・・。
>>38 ただibatisのSQL設定ファイルはいわばテンプレートなんだがその能力が低い。
リストや配列のプロパティで、そのままtoString()を呼んでDBに登録したいがエラーになる。
前のレスにあったけど、velocityみたいなテンプレート機能があるといいけど。
それに、qつのクエリのマッピングが一つのオブジェクトしか対象にできないのが痛い。
S2Daoで、各テーブルに対応するJavaファイルを作るのって手でやるんでしょうか？
リバースエンジニアリングしてくれて、勝手に作ってくれたりします？
43 ：
デフォルトの名無しさん：2006/01/09(月) 20:25:16
S2、S2って最近うぜー
いちいちageるなうぜー
iBATIS_ToolsのAbatorを試した人、感想ｷﾎﾞﾝﾇ
eclipseのpluginらしいのだけど。。。
>>45 velocityみたいに、sqlmapの中で使えるtoolがほしい・・・
ibatisで結果をHashMapにセットすることができますが、
Beanの中にあるHashMapにデータをセットすると、そんなフィールドないとのエラーになります。
エラーを見ると、対象がHashMapなのに、setプロパティ名を探しに行っているみたいです。
HashMapをDynaBeanに変えてもだめでした。
これは仕様でしょうか。
気になるのが、queryForObjectではなく、
SqlMapClientBuilder.buildSqlMapClient(reader);でエラーになります。
エラー
Cause: com.ibatis.common.beans.ProbeException: There is no WRITEABLE property named 'test' in class 'java.util.HashMap'
sqlMap
<resultMap id="user" class="ibatis.User">
<result property="hashMap.test" column="HASHMAP_TEST" />
</resultMap>
<select id="select_hash" resultMap="user" >
select
'ssss' as HASHMAP_TEST
from dual
</select>
クラス
public class User {
private HashMap hashMap = new HashMap();
・
public class User {
private DynaActionForm hashMap = new DynaActionForm();
・
ibatisですがiterateの中でisEqualをかけるとエラーになりました。
無謀でしょうか・・・
<iterate prepend="WHERE" property="data" open=" ID IN (" close=")" conjunction="," >
<isEqual property="#data[]#" compareValue="1">
#data[]#
</isEqual>
</iterate>
>>47 HashMapに設定可能というのは、
resultMapのclassにHashMapを使える
というのであって、
HashMap型のプロパティに値を設定できる
訳ではないのではないかという気がします。
52 ：
デフォルトの名無しさん：2006/01/21(土) 17:14:07
Hibernateについて質問なんですが、テーブルAとテーブルBがあって、
テーブルAの主キー：A_ID、
テーブルBの主キー：B_ID、A_ID（複合キー）
という場合、テーブルBに対応するクラスBとそのマッピングファイルってどう書けばいいですか？
複合キーの一部が外部キーの場合にどう書いたらいいのか分からなくって・・・・・・。
ibatisでiteratorの入れ子は可能でしょうか。
入れ子のiteratorのpropertyのインデックスを指定しないと動作しないです。
>>52 HSQLDBのテストテーブルがちょうどそんな形になってる。
Hibernate Toolsにhbm.xmlを自動作成させたらこうなった。
<composite-id name="id" class="test.entity.ItemId">
<key-property name="invoiceid" type="integer">
<column name="INVOICEID" />
</key-property>
<key-property name="item" type="integer">
<column name="ITEM" />
</key-property>
</composite-id>
<many-to-one name="invoice" class="test.entity.Invoice" update="false" insert="false" fetch="select">
<column name="INVOICEID" not-null="true" />
</many-to-one>
Hibernateで他がロックしているかどうか取得する方法ってありますか？
他がLOCK TABLEしている時にHibernate側でupdateしようとすると、他が
コミットされるまで、止まってしまいます。
>>55 使えるDBは限られるけどorg.hibernate.Session#lock()に
LockMode#UPGRADE_NOWAITを指定すれば出来ると思われ。
ただし、他のトランザクションのロックをポーリングしたいって場合は、
設計の方に問題がある可能性がかなり高い。っつーか、ほとんど禁じ手。
トランザクションはユーザー入力を介在させずに短時間で完了させるべし。
57 ：
デフォルトの名無しさん：2006/01/27(金) 23:41:50
>>54 レスありがとうございます。
そのマッピングだと、複合キークラスが
class ItemId {
private Integer invoiceid;
private integer item;
}
で、ItemクラスのフィールドにItemIdクラスとInvoiceクラスのフィールドを定義する、
って感じで合ってますか？
>>57 合ってる。クラスもそのように自動作成された。
Hibernate in Actionに載ってたけど、many-to-oneタグのupdateとinsertをfalseにすることが重要みたい
>>58 ありがとうございます！
やってみます。
ちなみに、参考までに伺いたいのですが、Hibernate Toolsの自動生成のマッピングの品質（？）ってどうなんですか？
本とかネットでも手動でマッピング定義の解説が多いような気がするので、
もしかしたら、手動でマッピングしないとパフォーマンスに問題があるとか、
複雑なテーブルはマップできないとか、そういう事情でもあるのかな？って思って。
>>59 DBスキーマからマッピングファイルを作るのは、以前はMiddlegenを使うことが多かったみたい
本や雑誌の説明等にも、Middlegenの使い方がよく説明されている。
今のHibernate側の方針は、スキーマからマッピングファイル、永続化クラスの作成まで
Hibernate Toolsに全部任せようとしてるように見える
実際使ってみた印象は、テーブルが大量にある場合はとても便利だと思う。
特に複合主キーを使ってる場合は、主キークラスを自動で作ってくれるのがありがたい。
テーブルに外部キー制約をつけておけば、自動的にone-to-oneやmany-to-one等の関連定義もやってくれる。
反面、フィールドの型の定義がちょっと微妙で、char型やbyte、short、boolean型等を積極的に使ってくる。
プリミティブ型とラッパーオブジェクトの区別が曖昧。「not nullカラムのときはプリミティブ型」のように定義してほしかった。
また、TIMESTAMP型に対してjava.util.Dateを定義してしまうので、TIMESTAMPをversion管理に使いたいときは修正が必要。
テーブル名やカラム名にアンダーバーが入ってるときは、アンダーバーを自動的に排除してクラス、フィールドの名前を作成し
マッピングファイルのカラム名定義でマッピングしてくれる。
しかし、いちいちマッピングファイルに書くぐらいなら、NamingStrategyで定義した方がいいと思うので
あまりうれしくなかったりする。
結局、手で作るより便利なのは間違いないが、出来たファイルやクラスを一通りチェックする作業は必要だと思う。
Toolのカスタマイズ方法があまりわかってないので、もしかしたらもっと便利に使えるかも？
>>60 なるほど！
チェック作業は入るとしても、全部手書きよりは断然効率良さそうですね。
是非使ってみたいと思います。
いろいろとありがとうございました！
Hibernate Toolsは前使おうとしたが、
ファイルエンコードが指定出来ず苦労した記憶が・・・
（UTF-8のプロジェクトで使うのにMS932でしか生成できず）
さすがにもう改善されたのかな？
Hibernate Toolsを使ってDBから定義ファイルを生成するときに
many-to-manyカラムを生成する方法をご存じの方がいたら、教えてください。
koichikさんの日記にあるようなhibernateが実行しているsqlを整形して
表示するのってどうやるんですか？
show_sqlだとインデントまではしてくれないですよね。。。
>>64 つ hibernate.format_sql
67 ：
デフォルトの名無しさん：2006/02/08(水) 02:14:46
nHibernateはどうよ？
Collectionの扱いがちょっと面倒
自前でやれってか？
71 ：
デフォルトの名無しさん：2006/02/09(木) 08:04:25
>>69 他でも時々そういう意見目にするんだけど、
NHibernateよりADO.NET使う方がいい理由ってなんなの？
なんかはっきりとADO.NETの方がいい！！って理由あんのかなぁ？
ORMならADO使ったほうがよさげ
つかスレ違い
HibernateやEJB3.0,iBatis程度をありがたがるjava技術者は哀れだな。
ふむ、じゃあ何をありがたがろうか？
HibernateやEJB3.0,iBatisよりもADO.NETの方が優れている理由は、ORMとしての
実力は大きく変わらないが、Viewまで含めて.NETの機能が練られているところだろう。
いくらDAOのコーディング量が減っても、部分最適にしかならないから工数が減らない。
じゃあViewにWicketってことで終了。
Clickは？
所詮は寄せ集めだな。
フロントから裏までWebObjectsで終了じゃん。
>>80 それをいうと「寄せ集めと大差ないクオリティのXXX(値は各自の信仰に依存)って何よ?」って話になるからやめれw
漏れ寄せ集めの方が好きだぬ。
なんかeclipse VS netBeans(あるいはvisualStudio)の
議論を見てるみたい。目的目標出さずに道具の議論って
あんま意味ないよ。
84 ：
デフォルトの名無しさん：2006/02/14(火) 02:34:07
1000行のデータを1ページ50行ずつでページングしたりする時に、
各ページに必要なデータだけをDBからロードするようにしたいんだけど
この場合はどうやればいいんだ？
当方Hibernate3を使用してます。
Hibernate3初心者ですが、ちょっと教えて下さい。
many-to-one のﾏｯﾌﾟで、もし該当ﾃﾞｰﾀが存在しなくても怒られない方法、
知りませんか?
例えば
<class name="item">
<id name="id"/>
<many-to-one name="bid"/>
</class>
<class name="bid">
<id name="id"/>
<pro name="amount"/>
</class>
これで
from Item item left join fetch item.bid をやって、
取得したリストを表示させると、bidを取得できなかったitemの
item.bid.amountをgetすると、
LazyInitializ E org.hibernate.LazyInitializationException TRAS0014I: 次の例外がログに記録されました。 org.hibernate.LazyInitializationException: could not initialize proxy - the owning Session was closed
と、ｱﾎﾞﾝです。
session閉じて分離ｵﾌﾞｼﾞｪｸﾄになってんだから、良いじゃん、
と思うんだけど、教えて下され。
not-null="ignore"
OracleがJBoss買収したら、TopLinkとHibernateは一つになるのか？
あと、JBoss CacheをOracleがどう使うのか気になるな
EJB3でTopLinkとHibernateはひとつになってる希ガス
APIが一つにまとまったからね。
TopLinkの「放出されていない部分」っていうと、現状JDeveloperに
載ってるGUIツールの部分や分散環境対応部分が大きいのだっけ？
oc4jとJBossコンテナはどう棲み分けるのかなぁ、Oracleって
GlassFishも支援してるから、まるでOracle一つの内で三つ巴に
なってるみたいなイメージだね。
買収成功祈る＞Oracle
WebアプリでHibernate EntityManagerを試してみたいんだけど、
persistence.xmlはどこにおけばいい？
アプリルート/META-INF に置いても読み込めません・・・orz
Persistence.createEntityManagerFactory("em1");
でコケます。
No Persistence provider for EntityManager named em1
とスタックトレースに出力されます。
（"em1"はpsersistence.xmlの<persistence-unit>要素のname属性に指定した名前）
WEB-INF/classesに置いてみても同じです。
Ejb3Configurationを使ってhibernate.cfg.xmlを読み込んでEntityManagerFactoryを
作る方法は成功しました。
環境はJDK1.5.0/Tomcat5.5.15/Hibernate3.1.2/hibernate-entitymanager-3.1beta6 です。
なんで唯一試すのがMETA-INFなんだろう・・・
>>93 スミマセン。
＞ WEB-INF/classesに置いてみても同じです。
と書いたように、他にはWEB-INF/classesも試しています。
>>92 WEB-INF/classes/META-INF/persistence.xml
classpath内の「META-INF/persistence.xml」を検索しているみたい
WARのMETA-INFに入れても認識しないので注意
>>95 うぉぉぉぉぉ！！！！！
激しくサンクスっ！
うごきましたー！
97 ：
デフォルトの名無しさん：2006/02/26(日) 16:58:56
SpringのgetHibernateTemplate().findで検索をかけたら、NoClassDefErrorが
発生しました。
loadAllだと問題なく抽出されるし、クラス名もちゃんとフルパスで指定
してるんですが、何が間違ってるんでしょうか。
>>97 さすがに、HibernateとSpringのバージョンくらいは書いた方が良いのでは・・・？
これは失礼いたしました。
spring1.2.6とhibernate3です。
Hibernateに関してですが、マッピングファイルに
<version name="version" unsaved-value="negative"/>
を記述して、バージョン管理をしていますが、このバージョンを
上げずに更新をするという処理は可能なのでしょうか。
一般的にはこのような処理は行わないと思いますが、2つのシステム
で同じテーブルを読みに行くとき、他方のシステムは特定のカラムを
更新された場合、更新の検知は不要と考えており、上記のような処理
ができないかと考えました。
101 ：
デフォルトの名無しさん：2006/03/01(水) 23:30:21
>100
細かい粒度でクラスを書き、<component> でマッピングしましょう。
とかベストプラクティスに書いてあるから、Aシステムで更新するカラムと
Bシステムで更新するカラムを別クラス（1テーブル）にしたら？
とかいってみちゃったりして。
僕は上記の方法をとらないときはからなずバージョンによるロックかけるよ。
>> 101
ありがとうございます。
二つのクラスにしてみます。
>> 102
テーブルtにf1,f2,vというカラムがあって、
vがバージョン番号だとすると、Aシステムは、
f1,f2を更新する可能性があって、Bシステムは、
f1のみ更新します。
f1を更新した際は、システムA,B共にf3を更新します。
ですから、Aシステムがf2のみを更新する際は、
排他制御は必要ないと考えたのですが、いかがでしょうか？
104 ：
デフォルトの名無しさん：2006/03/02(木) 11:03:14
>103
1)Bシステム：データ取得（f1=a,f2=b,v=1)
2)Aシステム：データ取得（f1=a,f2=b,v=1)
3)Bシステム：データ保存（f1=a→y,f2=b,v=1→2)
4)Aシステム：データ保存（f1=a,f2=b→x,v=1)
排他制御死ぬほど必要じゃね？
3)がせっかく入力したf1はどこいくんだ？
105 ：
デフォルトの名無しさん：2006/03/02(木) 11:06:55
>100
100よ！私101だが、俺てっきりAシステムはf1のみ更新、Bシステムはf2のみ更新
を行うと思ってたからcomponentのはなしなんかしちゃったよ。
AとBで更新するカラムがかぶってるならテーブル１個で普通にバージョンによる
排他制御してくれ。理由は104が知っている。
106 ：
デフォルトの名無しさん：2006/03/02(木) 11:07:43
↑
誤：テーブル１個
正：テーブル１個、クラスも１個
107 ：
100：2006/03/02(木) 17:15:09
ごめんなさい。記述が間違っていました。
× f1を更新した際は、システムA,B共にf3を更新します。
○ f1を更新した際は、システムA,B共にvを更新します。
同じカラムを更新する場合はバージョンを両システムとも上げます。
>>104 4) のところでupdate文にwhere v=1 が含まれると思いますので、
エラーにならないでしょうか？
>>105 両システムの更新するカラムがぶつかっている場合、ぶつかっている
箇所のみ排他処理をするのではまずいですか？
>>107 dynamic-updateを使うってこと？
自分のとこでは使ってないから、dynamic-updateが確実なのかどうかよくわからないけど
その場合でも、Aシステム用のクラスにはVersionカラムを定義せず、
ナンバーアップも排他制御も全て手作りで書くのが無難だと思う
業務的に必要なら仕方ないけど
更新前に余計にSQL発行するわけでもないし
そこまでして排他制御を避ける理由がよくわからないな
109 ：
108：2006/03/03(金) 00:19:54
× 排他制御を避ける理由
○ バージョニングを避ける理由
110 ：
100：2006/03/03(金) 09:25:31
>>108 バージョニングを避ける理由は、例として、
1) Bシステム : データー取得 (f1=a,f2=b,v=1)
2) Aシステム : データー取得 (f1=a,f2=b,v=1)
3) Bシステム : ユーザーがデーターの入力中
4) Aシステム : データー保存 (f1=a,f2=b→x,v=1→2)
5) Bシステム : 更新時エラー(バージョンが違うため)
3のデーター入力は入力項目が多いです。
4の更新内容は、Aシステムのみが使用するデーターカラム
の更新のみで、Bシステムの動作には影響しません。
ユーザーの作業効率を考えると、システムに影響がないの
であれば、5にてエラーとしない方がよいと考えました。
111 ：
デフォルトの名無しさん：2006/03/03(金) 18:29:20
>110
ﾁﾐのいってることはへんでないヵ？
(103)にて
>Aシステムは、f1,f2を更新する可能性があって、Bシステムは、f1のみ更新します。
(110にて)
> 3(=Bシステム)のデーター入力は入力項目が多いです。
ゆえにf1はたくさんの入力項目である。したがってAシステムも（人間が手で入力するのか自動で登録するのかは全く別として）
たくさんの項目を設定する。
だ か ら 、 たくさんの項目を設定したAシステムのf1が、ちまちま手入力したBシステムで入力したf1によってけされてしまうだろ？大問題ではないの？
それどころかAシステムでバージョンチェックしなかったらAシステムを同時に２人で使ったらデータが後勝ちしちゃうんだぞ。
そんなのDB使うときのポリシーとして許されるものじゃないんじゃない？
だめだ。どう考えてもバージョンチェックによる排他制御は必須としか思えない。
>
>>104 > 4) のところでupdate文にwhere v=1 が含まれると思いますので、
> エラーにならないでしょうか？
ヴァージョンチェックを有効にしたらそりゃエラーになるよね。ただ、Aシステムはバージョンチェックをしたくないんでしょ？
だからエラーチェックをしない前提だからべつにどうでもいいんじゃない？どうでもいいから単純にバージョンあげわすれただけ。
ちゃんとバージョンは4)のところで1→2にあげましょう。
112 ：
100：2006/03/03(金) 18:46:20
>>111 > だめだ。どう考えてもバージョンチェックによる排他制御は必須としか思えない。
両システムが更新するカラム(f2)のみ排他制御を入れるのではまずいでしょうか？
> Aシステムはバージョンチェックをしたくないんでしょ？
Bシステムのみ使用するカラムはバージョンチェックをしないという方針です。
他の箇所はバージョンチェックします。
113 ：
デフォルトの名無しさん：2006/03/03(金) 21:38:04
>112
おい！、103の書き込みをちゃんと見ろ！
両方更新するカラムはf1だろ！
Bシステムのみ使用するカラムなんてないだろ！
前提条件をころころかえるんじゃないよ。
わけがわからなくなるだろ！
114 ：
デフォルトの名無しさん：2006/03/05(日) 11:43:39
Hibernateってサニタイジングは自分でやらなきゃいけないの？
>>114 DBごとの駄目文字を上手いこと自動変換してくれるか、ってこと？？
>>115 狭い意味だと文字列末尾の'\0'を取り去ることだけになっちゃうね。
広い意味だといくらでもひろがっちゃうし。
>>114 というわけで、どこまで考えてるのかを、お願い。
PreparedStatementでやってくれる程度の処理
118 ：
デフォルトの名無しさん：2006/03/06(月) 18:53:18
Hibernateで、SQLのgroup byみたいなことするのって、SQL直書きでQueryクラスとかに渡すしかないのでせうか？
criteriaはそんなこともできんのですか？
119 ：
デフォルトの名無しさん：2006/03/06(月) 19:06:13
お願いします！わかる人答えてください！
掲示板に書き込みしたのをパスワード入力して
消したら完全に消えるんですか？？？ＩDとか
>>119 スレタイ読んで出直してくださいね。どこでも質問すればいいってもんじゃないです。
122 ：
デフォルトの名無しさん：2006/03/07(火) 10:25:40
返答どもです。
Hibernateのサイト見てやったらObjectの配列のListを返すとかいう美しくない結果にたどり着きましたが、それをとっかかりに以下の答えにたどり着きました。
これでClassA型で値が返ってきました。
//テーブルA(マスタ。ClassA)のうち、テーブルB（トランザクション。ClassB）にひとつ以上参照している行が存在するものを取得。返り値はClassA型のList
Criteria crit = getSession().createCriteria(ClassA.class);
crit.createCriteria("classB");
crit.setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY);
ありがとうございました。
ibatisのタイプハンドラには、String[]は型として使用できないのでしょうか。
TextSS のWindowsXP(Professional)64bit対応化おながいします
もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？
そういや64bitにネイティブ対応している２ｃｈブラウザてありましたっけ？
hibernateを使おうと考えています。
既存のマスタが論理削除で管理されている場合、
論理削除チェックはどこでやるもんなんでしょう？
127 ：
デフォルトの名無しさん：2006/03/23(木) 23:23:50
当方マカーです（ごめんなさい）
Hibernate3を使い始めたんですが、hbmを作るのが面倒です（PostgreSQLでテーブル100個ぐらいある）。
eclipseにプラグインを入れてもエラーで墜ちまくるので実用的じゃなさそうです。
eclipse以外に、PureJavaでつくられたツールとかでテーブルを観て自動的にHibernate3用のhbmをつくってくれるものありませんか。
HibernateでDTOパターンを使い、更に排他制御を行いたい場合
バージョンカラムを含めた形でDTOに値をコピーし、
更新時に再びDTOから永続化クラスに詰め直してupdateする・・・という手順でいいの？
遅延ロードを設定していて、値を取得していない関連オブジェクトがフィールドにある場合、どう扱ったらいいのだろうか？
今頃なんだけど、OpenSessionInViewってどうなのかな？
個人的にはDAOから取り出したオブジェクトはDBから縁が切れていてほしい
んだよね。なんかJSPで画面出してるときに、ここでDBになんかあったらど
うしようとか考えるのが気持ち悪いというか。
とはいえDAOで似たような中身のオブジェクトに詰め直すというのも冗長だし。
みんなどうしてるの？
133 ：
デフォルトの名無しさん：2006/04/09(日) 13:16:57
リクエストのたびにhibernateのSessionつくってフェラチオして
そのあとSessionをすぐにクローズしてる。Sessionはなるべく短く、短く。
すまん、フェラチオ→フェッチ だ orz
>>133-134 ( ﾟдﾟ)
＿(__つ/￣￣￣/＿
＼/ /
￣￣￣
( ﾟдﾟ )
＿(__つ/￣￣￣/＿
＼/ /
￣￣￣
( ﾟ∀ﾟ )ｱｰｯﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬ
＿(__つ/￣￣￣/＿
＼/ /
￣￣￣
相当短いんだろうな
138 ：
133：2006/04/09(日) 21:22:50
すまねぇなぁ(;´д｀)
フェまで入力してATOKだとtabで自動変換するからそのままreturnおしたのさorz
普段どういう文章打っているかがバレバレだぜ～
短く、短く
今はかってみたら16cmだった。ふつう？
>>140 日本人としてはちょっと長めらしい・・・。
なんて話はさておき、
Hibernateでは主キーがないテーブルのマッピングはできないんだな。
まあ当然なんだろうけど・・・。
Hibernateフェチ
>>133 てめえ人様の腹を捩らすとは何事だｺﾞﾙｧ
>>140 お前金持ちだろ。
ピーナッツ食いまくって水ばっか飲んでるだろ。
それにオナニー回数も少なめだな？
チンポの長さと将来成功することと何か関係があるらしいぞw
147 ：
132：2006/04/10(月) 18:02:27
少しはまじめな話題を振ったつもりだったのに
133のバカチンコのおかげで……orz
CayenneがApache Incubatorに入ったね。
HibernateもJBOSSの支援を受ける中、ObjectStyleだけで支えるのは大変だと
いうことかな。
おれはこのORマッパー、結構好きなんで、Apache加入後のiBatisのように、
着実に進歩していって欲しい。
とりあえず1.2は結構いい。
149 ：
デフォルトの名無しさん：2006/04/13(木) 18:22:12
>132
>133
OpenSessionInViewでもリクエストのたびにSessionはクローズしているとおもうが。
ただモデル（もしくはコントローラ）でクローズするか、View層でクローズするかの違い。
だからどっちでおこなってもSessionは短い、短い。
こんな事象のときにOpenSessionInViewは効果を発揮する。
【前提】
A-B-Cと各々1:n関連したテーブルがあり、画面ではその全てを表示する。
【OpenSessionInViewを使用したら】
HQLは「from A」でOK。あとはView層でかってに遅延ロードによってBとCはロードされる。
【普通にやる場合】
HQLは AとBとCをJoinしなければならない。
または、「From A」として取得した結果をループでまわして遅延ロードを発生させなければならない。
まあ、こんな場合はOpenSessionInViewをつかったら楽々ですよ。
DAOから取得したA EntityクラスをFormにつっこんだら終わりだもんね。
150 ：
149：2006/04/13(木) 18:40:57
続き
でも問題はあるのだよ。
【問題１】
遅延ロードは沢山のSQLを出力するから嫌いだ。
じつは、ふつうに遅延ロードをやると確かに遅延しない場合に比べて遅ーいばあいがあるね。
でも、以下のありがちな前提条件と、mappingの設定方法が合わさると、はやいのだ。
【前提条件】
１．次の１０件みたいなページング機能が要求されている。
そしてその実装はHQLではなく、汎用的にView層で行っている。
２．HQLまたはSQLでJoinするとえらく複雑でOracleのほうでコストがすごい。
【対処】
前提１の対処
ページングがあるってことは、遅延ロードは１０件分しかしなくていいよね。
でも遅延しなけりゃデータ数分Javaのメモリまでは展開されるんだからデータ件数によって
は遅延のほうがはやくなる。
それでも１件１件SQLが発生するのに抵抗がある人は、Hibernate-mappingの<Set>タグの
Attributeで「batch-size」ってのがあるんで、ここを20とかにすれば20行一挙に取得するSQLが
発行される。これは便利。
前提２の対処
遅延なしでOracleのコストがかかっている場合は、SQLを単純になるように分割したら
分割したほうが速くなる
ほら、共有プールのサイズとかあんまとれなくて、SQLであるコスト超えたら突然すごく
遅くなる場合あるじゃん。そんなときはjoinはずすとコストが下がるからサクサクと結果が
かえるようになる（こともあるよね）
151 ：
149：2006/04/13(木) 19:13:51
つづき
【問題２】
一覧表示系は問題ないが、一覧入力系で、かつカンマ区切りの数値や日付の入力がある。
【前提】
OpenSessionが機能してうれしいのは唯一View層での遅延ロードなのだから、そういう前提にする。
A-Bという1:nの関連があり、画面はAとBを同時に入力、Bのほうに数値と日付の入力がある。
JSFを使うとコンバータの機能があるから、多分簡単に解決する。だから前提はStrutsとする。
【対処】
Strutsで実装すると、カンマ区切りの金額、日付に対応するFormのAtributeはStringになると
思いますが、Bは遅延ロードの前提で、かつDBではNumber型やDate型なのでJavaの型は
BigDecimalとDate型とかにならざるをえません。
でもValidateのためにStringは別途必要です。
HibernateではCustom型を定義できるので、BigDecimalとDateの型のカスタム型を作成して、
カスタム型はBidDecimalとString型を内部では同時にもつように定義しておけば、
・ValidateはStringのほうで行い
・うまくBigDecimalに変換できるのであれば内部のBigDecimalのほうに値を移行
・あとはForm内のEntityをSaveすれば、DBに保存するようにUserTypeのコーディングを行う。
こんなことをやれば、コーディングレス（FormのStringからEntityへデータを移送するコードを
数値・日付のプロパティ分似たようなロジックを作ることがなくなる）で一覧入力系の
実装が可能。
まあ逆にそこまでしないと一覧入力系で遅延ロードの恩恵が得られないので、一覧入力系は
遅延ロードに頼らないというのも１つの手かもね。
152 ：
130：2006/04/14(金) 21:56:30
DBのデータ件数が少ない場合、別にPreparedStatementでも
そこまで実行速度的に変わらんので、SQL直書きでもいいかな、と。
いちお、SSQLLibってのがあるらしい。
結局（PL/SQLだと）自分でResultSetをBeanにマッピングしないとダメか・・・。
StoredProcedureとBeanのマッピングってHibernateでもムリなん？
Hibernate使ったこと無いので。
>>133 (*^ーﾟ)b ｸﾞｯｼﾞｮﾌﾞ!!
（133の次のナチュラルな下ネタを待っているのはオレだけすか？）
他人が作成した既存のものを改修することになったのですが、iBatisのsqlmapを使用しているプログラムでした。
sqlmapconfig.xmlには、こんな風に書かれていました
＜transactionManager type="JDBC"＞
＜dataSource type="JNDI"＞
＜property name="DBJndiContext" value="java:comp/env/jdbc/test"/＞
＜/dataSource＞
＜/transactionManager＞
＜sqlMap resource="sqlMap/test.xml"/＞
これで１データソースに対してクエリを発行していると思うのですが、
これを2種のデータソースを使い分けるように変たいと思っています。
そもそもデータソース2種を使い分けることが可能なのでしょうか？
>>154 TomcatなどのServlet Container レベルで考えると、JNDI経由で複数のDataSourceを取ることはできる。
> ＜dataSource type="JNDI"＞
> ＜property name="DBJndiContext" value="java:comp/env/jdbc/test"/＞
> ＜/dataSource＞
この辺の記述はまさにServlet Containerの設定をそのまま持ってきてるようにも見えるので
（「java:comp/env/jdbc/test」というあたり）、iBatisでも出来るんだろうと思う。
でもiBatis使ってないのでその先は分からない。
156 ：
デフォルトの名無しさん：2006/04/24(月) 00:53:53
Javaじゃなくて申し訳ないんだけど、NHibernateでCollectionマッピングってみんな何使ってやってる？
Setとかの代わりの定番ってある？
157 ：
デフォルトの名無しさん：2006/04/24(月) 01:50:24
>>154 String resource1 = "resources/sqlmapconfig1.xml";
Reader reader1 = Resources.getResourceAsReader (resource);
SqlMapClient sqlMap1 = SqlMapClientBuilder.buildSqlMap(reader1);
String resource2 = "resources/sqlmapconfig2.xml";
Reader reader2 = Resources.getResourceAsReader (resource);
SqlMapClient sqlMap2 = SqlMapClientBuilder.buildSqlMap(reader2);
try{
sqlMap1.startTransaction();
sqlMap2.startTransaction();
・・・
sqlMap1.commitTransaction();
sqlMap2.commitTransaction(); (*)
}catch(Exception ex){
sqlMap1.rollbackTransaction();
sqlMap2.rollbackTransaction();
}finally{
sqlMap1.endTransaction();
sqlMap2.endTransaction();
}
とかは駄目？ (*)のところで異常が起きると変な事が起きそうだけど
ミッションクリティカルなシステムぢゃなきゃだいじょうぶでしょう・・・
158 ：
デフォルトの名無しさん：2006/04/25(火) 23:26:42
Hibernateって何て読むんですか？
冬眠って読むんだよ
162 ：
デフォルトの名無しさん：2006/04/26(水) 14:39:18
>158
はぁい、ばーねいと！ （やあ、ばーねいと）
あい、ばーてぃす！（いいえ、わたしはばーてぃすです。）
カイ！ エ～ン ･ﾟ･（ﾉД`）･ﾟ･
ハーイバネット、ハーイバネットぉ～♪ 夢のハイバーネットたかたぁ～♪
Hibernateって、マッピングするときBean指定しないとダメなんですか。
ibatisではHashMapが使用できて、key=カラム名、value=値 で取得可能なのですが。
いや別にMapが欲しいだけならDbUtilだけでいいんだし....
167 ：
デフォルトの名無しさん：2006/04/26(水) 23:13:32
だれかJavaドメインモデルの実践的な実装を解説した書籍を教えてください。
サービス、ドメイン、ＤＴＯ、エンティティなど単語はよく聞きますがＵＭＬ
図ばっかりの本がおおくて実際のソースコードで実感できるものを見たことが
無いので。。。
>>165 Mapでも取得可能。DOMのElementに値を詰めて返すことも出来る
ドメインモデルって難しい言葉を意識するから難しく感じるんであって、
要するにあれって「ただのまっとうなオブジェクト」ってことなんじゃないの？
「USERテーブルの行をロードしたデータ」じゃなくて、「ユーザー」という
「もの」を表したオブジェクトって考えようよ、というのがドメインモデルの
ベースにあるところじゃないかと。
オブジェクトだと考えたら、「ユーザーの登録を抹消する」なら「じゃあ
unregisterメソッドを読んだら抹消するってことで」と自然に思うじゃん。
裏でどんなSQL投げようが、ファイル読もうがセッションをごにょごにょ
しようが、抹消してくれればしったこっちゃないでしょう。それがオブジェ
クト指向ってもんだ。
ＤＢを前提に考えちゃうと「ユーザを抹消するってことは、まず関連付けられた
契約レコードをすべて抹消したあと、ステータスをごにょごぎょして、
ユーザーのレコードの削除フラグをオン。それを効率良くするには、関連
レコードをジョインして....」とか考えてしまって、それをそのままべたっと
コードに書いてしまいがち。
オブジェクト指向的には、ユーザーというオブジェクトの「抹消」という
命令を呼び出したら勝手にごにょごにょして抹消してくれりゃいいわけ
で、その抹消メソッドが裏で勝手に契約レコードを抹消してステータス
変更してくれりゃいいじゃん、それがオブジェクトってもんだろ？
契約だってオブジェクトなんだから、ユーザーオブジェクトの抹消メソッド
のなかで、契約オブジェクトの契約解除メソッドよべばいいじゃん。
ってのがドメインモデルじゃないかな。
↓さあ景気良くいこう
170 ：
デフォルトの名無しさん：2006/04/27(木) 00:16:08
> ドメインモデルって難しい言葉を意識するから難しく感じるんであって、
> 要するにあれって「ただのまっとうなオブジェクト」ってことなんじゃないの？
おそらくそういうことなんだろうな～とは思ってるんですが、「サービス」とか
いうやつの位置付けがようわからんです。なんでも人によると「薄いのが良い」
とかいう意見を見受けますが”じゃなんなんだい！”みたいな
おれはサービス層については、下のような用途かなあと思う。
・業務的には複数のモデルにまたがった業務処理を一括して行うためにある。
例：発送処理 おそらく「商品」と「発送業者」と「在庫」くらいの複数のモデルが
関わる予感がする。
・プログラム的視点では、トランザクション境界を定めるためにある。
サービス層の一つのメソッド呼び出しが１トランザクションになるようにする、
という感じで。いろんなモデルをごにょごにょした結果、裏でいろんなＳＱＬが
走るわけだけど、それを一つのトランザクションにまとめる、という感じだろうか。
172 ：
デフォルトの名無しさん：2006/04/27(木) 00:58:31
> ・業務的には複数のモデルにまたがった業務処理を一括して行うためにある。
> 例：発送処理 おそらく「商品」と「発送業者」と「在庫」くらいの複数のモデルが
> 関わる予感がする。
EntityやDAOの呼び出しロジックをサービスにまとめるってことで総括して良いん
でしょうか。もっとシンプルに言うなら、ビジネスロジックの担当がサービスなん
だっていうことなんでしょうか。
データベースアプリを組むときには、ほとんどドメインモデルは必要ない。
データベースアプリというのが何を指しているのかよくわからないが、
データベースを使ったアプリという意味なら、データベースを使ったアプリで
ドメインモデルを使わなけりゃいつ使うのかと。
>>172 １行目はそうだと思う。
２行目は微妙。たとえば売り上げオブジェクトの「未回収」メソッドを呼んだら
赤伝オブジェクトが生成されて、台帳オブジェクトに追加されるとしたら、
これは立派なビジネスロジックなわけだが、この処理を書くところはあくまで
「売上」オブジェクトであるべきだよな。
だって「未回収」メソッド呼んだら裏でごにょごにょやる内容が赤伝生成だったり
台帳更新だったりするわけで。
仮に台帳更新をしたらどっかの担当者にメールを送らないといけないとしても、
台帳の更新メソッドが呼ばれたら、メーラーオブジェクトの送信メソッド呼ぶように
してりゃいいわけで、結局外からみれば、売上の「未回収」を呼ぶだけで台帳に
赤伝が入って担当者にメールが飛ぶ、というビジネスロジックが実行される。
だったらロジック実行には売上オブジェクトだけあればＯＫだよな？
こんな感じで結構な数のビジネスロックはドメインモデル内で実行可能だと思う。
でも処理実行後に、たとえば現在の赤伝数とか、赤伝発行後の売上高だとか
を取得して画面に返さないといけないとしたら、これはあくまでウェブアプリ
ケーションの都合で実行するんであって、ビジネスロジックとは関係ない。
でも同じトランザクション内で赤伝数のカウントしたり、売上高計算したり
しないといけなかったりもする。
となると、サービスとして一つのトランザクション境界としてまとめるのが
一番やりやすいかなあ、と思うな。
まあでもぶっちゃけて言うと、Springとか使うとメソッド呼び出しと応答までを
トランザクション境界にする機能があって便利なんで、それを利用するためだ
けにサービス用意して、サービスを呼び出したら即モデルのメソッド一つ呼んで
終わり、なんてこともある。だってプログラム的にトランザクション制御する必要な
くて楽だからさあ。
O/Rマッピング使っていると、エンティティに情報があるんだから
ドメインモデルとしてロジックを書きたくなるんだけど
現在のDIコンテナは、ステートレスなトランザクションスクリプトを扱う方が便利だから
そこにちょっとしたズレを感じたりしている
エンティティにストラテジーをDI出来たりするO/Rマッピングツールが出たら便利そうなんだが
177 ：
デフォルトの名無しさん：2006/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を並べたい、みたいな感じ
>>168 すんません。
参考サイトとか教えていただけないでしょうか？
>>179 つ「言いだしっぺ必敗の法則」
ということで翻訳よろしくｗｗ
>>180 つ「言いだしっぺ必敗の法則」
それやると誰も何も言いださんくなるよ。
おれの前の会社がそーだったよ。
もともとNetNews（それもfj）とかの世界で人を黙らせるための
ものだからな＞言いだしっぺ
あれはある意味2chの対極にある世界だった。
>>181-182 つか、冗談だからｗ ちゃんと"ｗｗ"つけてるじゃん。
というか、前の翻訳は誰がやったんだ？
最近 2ch のせいで「www」とかいうアドレスをみると
笑えてくる。
186 ：
デフォルトの名無しさん：2006/05/02(火) 19:19:08
187 ：
デフォルトの名無しさん：2006/05/02(火) 23:31:28
すいません、.NETで申し訳ないんですが、質問させて下さい。
.NETでORMに詳しい人が集まってそうなスレが見当たらなかったもので・・・。
NHibernate Best Practices with ASP.NET, Generics, and Unit Tests
http://www.codeproject.com/aspnet/NHibernateBestPractices.asp 上のサイトのサンプルに、NHibernateでのOpenSessionInViewパターンの実装例があるのですが、
リクエスト開始時にbeginTransaction、リクエスト終了時にcommitTransactionとsessionCloseを行っています。
この作りだと、もしリクエスト中に例外が発生した場合、Transactionはどうなるのでしょうか？
JavaのFilterと全く同じ仕組みが無いのでこうしてるのかとは思うのですが、これで問題が無いのかどうかがイマイチわかりません。
一応、Session管理クラスの中を見ると、commit時に例外キャッチしたらrollbackするようにはなっているんですが、
Transaction中に例外が起きた場合にcommitが成功してしまうケースってありえないんでしょうか？
それともTransaction中に例外が発生した場合には、必ずcommitで例外が送出される仕組みなんでしょうか？
188 ：
デフォルトの名無しさん：2006/05/03(水) 23:31:55
jarファイルの中のdaoからHibernateを利用しようと考えてるんだけど
マッピングxmlやhibernate.cfg.xmlって普通どこに配置するのがメジャー？
ibatisって、jspみたいに自作のタグを使用できないのでしょうか？
普通にjspのカスタムタグを使えばいいんじゃないでしょうか....
191 ：
ＪＡＶＡ初心者：2006/05/13(土) 23:44:13
こんにちは。いつもいろいろ教えてくださいましてありがとうございます。
今日はＴＯＲＱＵＥに関する質問です。
ＴＯＲＱＵＥについて、まだ使用経験がないのですが、今度使わなくてはいけなくなりました。。。。
でも、なにせ資料が少ないので。。。。
ＤＢの中でプライマリーキー（ここではＩＤ）の一番大きい数をしるのは
そうやってやればいいでしょうか？
たとえば、ＩＤが今は１０番まで使われていたとして、その１０番というのを
知る方法が知りたいのです。ＳＱＬだと、ＳＥＬＥＣＴ ＭＡＸみたいなので
ＧＥＴできると思いますが。。。。。
よろしくお願いしますｍ＿＿ｍ
192 ：
191：2006/05/13(土) 23:52:50
>>190 すいません。ちがいます。
sqlのxmlファイルに、ibatis用の拡張タグを使用できる仕組みになっているかを確認したかったです。
195 ：
194：2006/05/16(火) 10:07:24
連投ｽﾏｿ
SqlMapClientBuilder#buildSqlMapClientに
velocityを喰わせることは出来るかもね。
やったことないケド
いつも参考にさせていただいてます。
現在Javaで作成している基幹系アプリケーションで、ランタイム上で
テーブルの作成・修正・削除を行う必要があります。
この場合、O/R Mapping Frameworkは向かないでしょうか？
今のところ、JavassistなどでAnnotation付きのクラスファイルを生成して、
それをHibernateのConfigurationに動的に読み込ませれば良いのでは？
と考えていますが、まだ実現に至らずです。
どなたかノウハウをお持ちでしたら、ぜひ教えてくださいm(_ _)m
>>196 > ランタイム上でテーブルの作成・修正・削除
ていうか何そのキチガイ設計。
キチガイが作ったのを引き継がされたの？
199 ：
196：2006/05/17(水) 22:48:44
お二方、回答ありがとうございます。
>>197さん
提示していただいたリンク先の方法を確認しました。
生成したクラスコードからテーブルを自動的に生成する
必要があります。
そのため、この方法は利用できないと判断しました。
>>198さん
キチガイですいません orz
まだまだ勉強が足りないと痛感してます。
200 ：
196：2006/05/17(水) 22:49:27
196です。
今回の案件では、ユーザが自由に編集できるクラスと
そのオブジェクトを永続化してRDBに登録するアプリケーションを
作成します。
クラス自体の生成、修正（継承先の変更等）、削除だけでなく、
クラスのフィールドの追加、修正、削除もサポートする必要が
あります。
クラスの編集によって、オブジェクトを格納するテーブルも
修正しなければいけないため、アプリケーション上で動的に
テーブルを操作する方法を質問しました。
できるだけO/Rマッピングツールを使うように言われていますが、
今回の目的だと、素直に動的にSQLを生成して操作した方が
良いような気がしており、エキスパートの方々のご意見を伺おうと
思いました。
個人的には、今回の案件だと、RDBMSの種類やバージョンに
よる方言を吸収して、コネクションプーリングなどを提供する
ツールなら何でもいいような気もしますが、中小の下請けなので
強く言い出せません orz
乱文長文失礼しました。
ユーザがクラスを動的に生成・変更できるってことは
バイトコード操作使いまくりか…
正直Javaでやるのが間違ってると思われ。いまからLispハッカー
探せ。奴らは毎日そういうことやってる。
((((((((((((；ﾟДﾟ))))))))))))ﾘｽﾘｽﾌﾟﾙﾌﾟﾙ
>>199 データベースさえcreate文で作ってしまえばいいんじゃねぇの？
そしたらあとはマッピングクラス生成してマッピングっていうのをやってくれて望みどおり
204 ：
デフォルトの名無しさん：2006/05/17(水) 23:43:52
クラスをシリアライズしてvarchar2(4000)
くらいの列につっこむようにするとかは？
205 ：
196：2006/05/18(木) 00:27:31
お騒がせしてます。196です。
>>201さん
すいません、
>>200の説明で、大変な御幣がありました。
>今回の案件では、ユーザが自由に編集できるクラスと
>そのオブジェクトを永続化してRDBに登録するアプリケーションを
>作成します。
ここで言うクラスとオブジェクトはJavaのものではなく、OWLのものでした。
先方さんは、
OWLのクラス・インスタンス ⇔ Javaのクラス・インスタンス ⇔ DB
という処理を希望されています。
OWLだと、トリプルの構造をそのままテーブルに格納すれば良いと
思っていましたが、メインは検索処理でインスタンス数が多いそうで、
そのようなテーブルスキーマだと速度が出ないと判断しました。
206 ：
196：2006/05/18(木) 00:37:18
連投すいません。196です。
>>203さん
DDLだけConnectionを直接取得してSQLで行うことも検討しています。
このとき、対応するマッピングクラスをConfigurationに設定した場合、
既にbuildされたSessionFactoryに変更を反映する方法が分かりませんorz
独自にFactoryの実装を行えば動作しそうな気もしますが・・・
>>204さん
BLOBにシリアライズしたクラスコードとオブジェクトを挿入することも考えました。
この場合、index用のデータをテーブルの別のフィールドに格納しておけば
検索速度も上がるのかなと思いますが、保守やシステムのアップグレードが
大変そうで躊躇しています。
相変わらず長文ですいませんorz
最近謝ってばかりだ…
OWL？ Lispハッカー以上に気の狂った世界に踏み込んでるな。
漏れにはわからん世界だが、RDBMSの性能のことならわかる。
いまのPCの性能で、行数が多すぎて性能が出ないなんて
話は猛烈なレアケース。
いろいろごちゃごちゃ理由がつくんだろうが、RDBMSはごちゃごちゃ機能を
つけてて、必ず対策があるようにできてる。RDBMSのマニュアル調べてみろ。
208 ：
196：2006/05/18(木) 01:15:01
>>207さん
OWLのクラス階層の編集を可能とするため、上位クラスの変更を下位クラスにも
反映させる必要があります。
また、個々のクラスのインスタンス数は大したことはないですが、想定している
インスタンス数が全体で100万のオーダーであるため、それを一つのテーブルで
OWLのトリプル単位でばらして格納するよりは、クラス単位でテーブルを生成して
そこに持たせた方が良いのでは、と考えました。
（複雑なデータ型の問題ももちろんあります）
O/R Mapping Toolを使わずに、自前で作成した方が良いのかもしれません。
とりあえず、仕様を含めて、RDBMSをもう一度勉強しなおしてきます。
ご指摘ありがとうございました。
あぁ、今夜もクラス階層を構築している夢を見そう orz
ところでOWLってなに？
腹がよじれた失意体前屈？
Javaのインスタンスを生成する必要がわからん……
211 ：
デフォルトの名無しさん：2006/05/18(木) 10:39:25
>>205 >OWLのものでした。
BC++のObjectWindows Libraryかと思った
>>194 本当にすいません。
タグはタグでも、<select>内に書ける<equal>などのタグです。
スキーマの緩いXML-DBを使った方がよかったりして。
215 ：
196：2006/05/18(木) 22:14:30
>>210さん
OWLのクラスをJavaのクラスに、OWLのプロパティをJavaのクラスのフィールドに
見立てようと思っていました。
そうすると、OWLのインスタンスはJavaのフィールド値の集合で表せるかな、と。
>>211さん
OWLはWeb Ontology Languageの方です。
不注意で誤解を与えて申し訳ない。
>>214さん
今回は検索系がメインらしいので、XML-DBだと速度面が不安です。
先方さんの話をよく聞くと、各RDBMSのSQLの方言を吸収できて、かつノウハウが
多く得られるようなミドルウェアなら何でも良さそうです。
何かの記事で読んだC-JDBCとか気になりますが、スレ違いなのでやめておきます。
皆様、お付き合いいただきありがとうございました。
>>215 OWLってのの具体的な事は全くわからんが、
最初の３行が間違ってる気がするな。
性能要求が厳しいのにRDBMS依存を避けろ、か…
キチガイの相手は大変だな。
おそらく全部ぐだぐだになって成果物ゼロで終わると思うが、
金はしっかり取れよ。
218 ：
196：2006/05/19(金) 00:29:06
196です。また来てしまい、すみません orz
>>216さん
OWLのクラスとプロパティのそれぞれに、独自のAnnotationをつける仕様なので、
（１）OWLのクラスのAnnotation用テーブル
（２）OWLのプロパティのAnnotation用テーブル
（３）OWLのクラスとOWLのプロパティの対応情報テーブル
（４）各クラスのインスタンス用テーブル（カラム名は各プロパティ名）
の４種類のテーブルを作成するように設計しました。
大学出立てで経験が浅いので、どの辺がマズいかはわかりませんorz
>>217さん
汎用性と性能は両立しないのは分かっていますので、そこそこのものを提供しようと
思っています。
情報収集の最中に発見したのですが、Seasarファウンデーション傘下のTuigwaaが
Hibernate使用＆DDLサポートとなっていました。
ダイコン？とかよく分からないですが、参考になるかもしれないので今週末の休みに
ソースを読んでみようと思います。
>>218 ＞OWLってのの具体的な事は全くわからんが
おまえ日本語読める？
>>219 顧客がイカレてるせいで、こいつもおかしくなってるんだろう。
金だけはしっかり取れよ。
>>159 ヒルベルト変換、ヒルベルト包絡線を思い出した
何が悪いとはっきり言うつもりはないが、もうちょっとまともに検討しないと大火災になるぞ、そのプロジェクト。
もうなってるようにしか見えないっす
LDAPとかのがまだマシなような。
何から何まで不毛な要件で、かつゴールもなんら魅力が無いと来た。
世の中色んな案件あるんだね。
dbutils結構いいかも。
Mapに詰め込むだけでもMappingといやーMappingだが
Beanに詰めることも出来るよ。一応。
ちんこがBeanBeanでつ
〃∩ ∧＿∧
⊂⌒（ ・ω・） はいはいわろすわろす
｀ヽ_っ⌒/⌒ｃ
⌒ ⌒
Cayenneで部分読みしたいんですがどうすればわかりません。
サンプルが落ちているところをご存知の方いませんか？
233 ：
231：2006/05/29(月) 11:43:03
234 ：
デフォルトの名無しさん：2006/05/31(水) 14:58:57
参照系だけの場合、HibernateとJDBC直書きとどっちがパフォーマンスいいですか？
キャッシュの設定によってはHibernateのが早かったりする？
ストアド化しろ
つうか素でHibernateのほうが速いだろ。
それはほとんどない。
どういう設定をしたら参照がJDBCより遅くなるのかと。あらゆる局面で
lazyオフでキャッシュなしか？
>>238 いくつかは考えられるだろ。
・最初の一回目の検索の場合（Hibernateが該当するオブジェクトをまだロードしていない状態）
・ストアドプロシージャを呼び出す場合（Javaアプリ側でなんとかするより、ストアド使った方が速い場合が多い）
240 ：
234：2006/06/03(土) 00:48:56
みなさんレスありがとうございます。
ちなみに、バッチ処理で1回のみですがテーブル全件舐めたりします。
1回きりの場合だとHibernate導入するメリット無さそうですね・・・（パフォーマンス面で）。
ストアドである程度書いてJDBCで呼ぶってのが理想的みたいですが、ストアドで作るとメンテできん！って怒られます。
バッチでストアド無しでパフォーマンス高くする手ってなんかないですかね～・・・。
バッチ処理でHibernateを利用する理由はほとんど無いな。
O/R-Mappingでやってることって、結局
・バックグラウンドでSQLを作って投げる
・返ってきたresultsetをbeanに自動的にマッピングしてcollectionに詰めて返す
が本質だよね？
そう考えると、DbUtilとかでも十分なのかな。。。
うちの会社、こういう新しい？技術とかの導入に消極的だし、
新しい知識を積極的に勉強しようっていう技術者も少ない。。。
個人的にはiBATISあたりがよさげなんですが、使ってる人いますか？
243 ：
デフォルトの名無しさん：2006/06/03(土) 16:15:01
キャッシュとか遅延ロードが主なメリットじゃない？
関連テーブルの紐付けが嬉しい。
245 ：
デフォルトの名無しさん：2006/06/03(土) 16:46:05
今一これの利点が分からないんだけど
いちいちXMLとかに定義しないと使えないわけ？
extends MySQLObjectとかしてささっとプロパティだけで完結して欲しい。
>>242 関連テーブルを自動的に取ってきてくれるという重要な機能が
あるでしょ（これはDbUtilにはない）。
最近はどこのO/Rマッパーもテーブルからのクラス自動生成機能持ってる
ＪＰＡ使えばXMLファイルはもういらない
>>247 ふーん。いいね、組み込みDBとかで気軽に永続化できるようになると
ゲームとかも作りやすくなっていいかなぁ
>>245 MiddlegenでもXDocletでも、Hibernate Annotationでも、好きなの使え。
JPAの解説記事少ないなあ。
みんなxmlでしこしこやってるの？
>>240 いまPro EJB3を読んでるところだと思われ。
でもなんでそこでxmlが出てくるのかわからない。
>>251 Java Persistence APIってなんなの？
ORまっぱの仕様
>>254 jspタグライブラリでも使用できるらしいけど。
ってことは、jspでＤＢアクセス用ってことか・・・。不要じゃん
256 ：
デフォルトの名無しさん：2006/06/09(金) 16:54:17
それはJPAを使うタグライブラリのこと
JPAの仕様とは関係ない
JPAは、HibernateやTopLinkを元にしたO/Rマッピングの標準仕様のこと
>>255 JSPタグライブラリにJDBCタグライブラリがあるが、JDBCはJSPでDBアクセス用か？
そう。
アホな流れになってるな。
子供か！！
そう。
261 ：
デフォルトの名無しさん：2006/06/13(火) 22:09:47
Hibernate2xで関連テーブル使ってmany-to-manyでマッピングしてる時、bagとかのwhere属性で関連先のテーブルのカラムに対する条件って書けますか？
普通にカラム名と条件書くと関連テーブルにそんなカラムねーよ！！って怒られちゃうんですが・・・。
能動的にコーディングできるってだけで、O/Rマッパーはチューニングに向いてないんだな
少なくとも、困ったときに直にSQL書いて実行できるようなフレームワークじゃないと、
使えないなあというか使うの怖いなあ。
まあそのときだけJDBC使えって話はあるけど。
Hibernateは問題ないな。
でも直に書けるフレームワークは、普段から直に書く様に成って、後で困る罠。
>>266 そういう開発者、いそうだね。特に新規に導入するとき、わからない→直書きってされそう
でもハマった時の最後の手段として、SQLとかJDBC APIとかとも上手く連携してくれるのがいいなぁ。
プログラマとしては逃げたくなくても、サラリーマンとしてそういう手段に逃げちゃう時が多々あるんで・・・・・・。
269 ：
デフォルトの名無しさん：2006/06/17(土) 11:50:26
Hibernate3とEJB3、これから作るシステムに入れるならどっちがおすすめ？
今までどおりの使い分け
ゲームで使えそうなORMはHibernateくらいかい？組み込みたいのでオススメを聞きたい
>>269 EJB3を使ってJPAの実装としてHibernateを利用
>>271 つうか、これからはJPAという標準になるんだから、ゲームで使うくらいならTopLinkもHibernateも大差なかろう。
274 ：
269：2006/06/18(日) 01:32:50
>>270 今までEJBって使った事ないんですが、使い分けってどんな基準ですか？
>>272 なるほどー。
使い分けってよりJPAの実装としてHibernateを選択って感じなんですね。
>>274 いままで使ってなかったのはEJB2
EJB3とは別物。
ORマッピング使うなら、EJB3で十分。
実質的にはHibernateの仕様がEJB3になったわけだから、EJB3とHibernateをどう使い分けるかということが、そもそもナンセンスということになる。
>>275 リモートで呼び出せるかどうかのみ違う。
使い分けはそこだけかな。
JPA仕様とそれぞれのORマッパーって結構違うんじゃない？ Hibernateについては同感だけど。
たとえばCayenneもJPAをサポートするといって準備しているけど、Cayenneの
発想とJPA(Hibernate)のやり方（というか考え方）って結構違うように思う。特に
トランザクションを意識させない設計とか、どうすんだろ、と思う。
TopLink(Grassfishに組み込みのやつ）とかはどうなんだろうか。
278 ：
275：2006/06/18(日) 03:47:22
>>277 HibernateもCriteriaとかProjectionとかがEJB3に取り入れられてなくて残念なんだけど、ORマッピングのプログラムインタフェースの部分だけを見ればJPA準拠ならHibernate互換ということになるんじゃないかな、と思ってます。
279 ：
275：2006/06/18(日) 03:53:08
>>277 重箱の隅だけど、GlassFishね。草みたいな魚じゃなくて、ガラスみたいな魚。
TopLinkは、JPAの実装として使う限りでは、個性を感じない。
もちろん、どのJPA実装も、JPAの実装として使う限りでは個性を感じないというのは当たり前の話ではあるんだけど。
パフォーマンスの差とかあるのかな？
281 ：
275：2006/06/18(日) 08:08:21
それぞれの固有の機能を使わない限りは、無視できるほどの違いしかないと思う。
でも実測値がほしかったら、実サーバーで確認するのんが確実
>>282 特許侵害しているとして訴えられただけだろう。
まだまだ一方的な主張の段階。
「特許侵害だとよ。」は風説の流布に当たるおそれがあるから注意。
断定は判決が出てからに汁。
よくあるアメリカ流のふっかけ・ゆすりと推測してみる。
うまく行けば和解金ふんだくれるもんな。
284 ：
デフォルトの名無しさん：2006/07/04(火) 21:10:50
時給１０００円でＪａｖａ教えてくださるかたを募集します
場所 所沢（池袋・高田馬場から直通）
ｉ－ｗａｎｔ－ｔｏ－ｓｔｕｄｙ－ｊａｖａ＠ｈｏｔｍａｉｌ．ｃｏ．ｊｐ
（アドレスは全角で書いてあるので半角に直してください）
よろしくおねがいします
>>281 すでに「おい、そのころには既にEOFがあったわけだが。
そのEOFにすら先行技術があるんだが？」と冷静なツッコミが
入っとるよ。
BerkeleyDB Java Editionつかってます
287 ：
285：2006/07/05(水) 09:03:31
289 ：
デフォルトの名無しさん：2006/07/17(月) 21:22:59
教える対象は超初心者です。
専門学校などでJavaを勉強されていて夏休みだけ教えたいという方も歓迎です
290 ：
284：2006/07/17(月) 21:28:22
教える対象は超初心者です。
専門学校などでJavaを勉強されていて夏休みだけ教えたいという方も歓迎です
291 ：
284：2006/07/17(月) 21:46:20
いきなり缶詰ー＞架空請求スパムの送信
亜米利加の特許は先発明制だから、いくらでも先行特許あるよ。
293 ：
デフォルトの名無しさん：2006/07/18(火) 03:38:48
HibernateのHQLで select sum(*) の返り値を
IntegerじゃなくてLongで取得したいのですが、いったいどうすれば…
>>296 ありがとうございます
丸一日、試行錯誤してしまいましたが
3.2.CR2入れることにします…
BeehiveのJDBC Controlみたいな感じか。
300 ：
デフォルトの名無しさん：2006/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);
完成したら公開しようと思っていたのだけれど、微調整したら公開しちゃおう。ｴﾍﾍ
>>300 標準のは、CachedRowSetを使っていて、CachedRowSetはJDBCドライバの対応が
必要だから、存在価値としてないわけじゃないと思うけどね。
しかし、どうせなら誰か.NETのDataSetをそのまま実装して欲しいな。
NinjaVAが実装しているけど、DataSetのソースが5000ステップくらいあるのと
微妙に違うので、いまいち使いづらい。
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：2006/07/28(金) 01:33:19
とりあえずサンプルをちゃんと動くようにして、上げました。
BSD License です。
http://sourceforge.jp/projects/crudfactory/ すいません、ドキュメントが一切ないです。サンプルのソースを見て下さい。
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：2006/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：2006/07/28(金) 01:44:30
始めてオープンソースでソフトを公開しました。
ドキドキしています。
早速パクって儲けさせていただきました。無料で公開してくれてありがとう。
>>304 乙！
と思って、早速いろんなDBで動作確認…と思ったら、
リリース物件もソースコードリポジトリも空っぽですよ？
309 ：
300：2006/07/28(金) 08:23:51
俺のアカウントからなら見られるのに……
俺sf.jpの使い方わかってないぽいので、しばしお待ちを……
スレ汚してすいません。
310 ：
デフォルトの名無しさん：2006/07/28(金) 09:41:06
>>300 私も期待しています。
頑張ってください。
sfはリリースしてから実際にDLできるまでにラグがあるらしい
314 ：
ストーカー：2006/08/03(木) 01:49:49
メモリに入りきらないぐらいの巨大なテーブルをSELECTして、一件ずつ処理したいと思っています。
Hibernateを使おうかと考えていますが、ネットの入門を見ている限りSELECTした結果を一気に取得しているようです。
全件一気にオブジェクト化するとメモリが足りなさそうなのですが、こういう用途はJDBC使って1件ずつ取り出した方が良いんでしょうか？
1件ごとにSELECTすると効率が悪いから
何十件かまとめてSELECTするよろし。
それにそもそも、巨大なテーブルを全部変更するなら
ストアドプロシージャのほうが圧倒的に効率がいい。
317 ：
315：2006/08/03(木) 12:48:31
書き方が悪かったですね、申し訳ないです。
SELECT * FROM TABLEして全件取得して、ResultSet.next()で1件ずつ処理したいって事なんです。
Hibernateの入門ページ見てると、検索結果がListで一気に戻ってきているようだったので。
つまり聞きたいのは、検索結果全件を一気にオブジェクト化するとメモリが足りないので、
検索結果全件の中から1件ずつオブジェクト化して処理できないかな？って事です。
ListのgetやIteratorのnext時にオブジェクト化されていたら問題なさそうなんですか。
って書いてたら聞くより本なり読んでちゃんと理解してから判断した方がいい気がしてきた・・・。
>>713 素のJDBCだと 一方向に読み込み専用 で取得すると
一気には取ってこないみたいだね
319 ：
315：2006/08/03(木) 16:36:42
>>318 それをO/RマッピングでやってみたいんですがやっぱJDBC使わないとダメなんでしょうかね。
ふむむ、できないとしたら分割してSELECTするなり工夫が必要かぁ・・・。
321 ：
315：2006/08/03(木) 17:14:37
>>320 おお、良い感じですね。
問題はいらなくなった読み込み後のオブジェクトがちゃんとゴミ掃除されるかどうかだけど・・・とりあえずいろいろ読んでみます。
㌧クス!!
Beanて、テーブル毎に一つ作るものでしょうか？
INSERT目的なら全カラム必要になるだろうけど、
SELECT目的なら一部のカラムのみで十分なケースってあると思うんです。
例：
BOOKというテーブルはID、名前、著者名、カテゴリ情報、概要等、
本に関する情報を多数持っているが、
検索結果に表示するのは名前だけで十分、という場合。
この時ID、名前以外の情報まで持ってくるのは非効率な気がするのですが、
このSELECT目的に別にBeanクラスを定義するというのはアリでしょうか。
class Book { 全カラム }
class BookForSearchResult { ID, 名前 }
それとも、この程度の効率はO/Rマッピングを使用する以上、
気にしない方がいいんでしょうか。
>>322 どうしても気になるのなら、IDと名前だけのビューを作って、
そのビューとBeanをマッピングしたらどうでしょう？
hibernate使ってたけどいろいろ面倒くさくなってきたのでCommonsDbUtilsに戻してしまった。
なんかすがすがしい気分になった。
325 ：
322：2006/08/08(火) 11:09:26
>>323 なるほど、ビューを対象にするなら違和感ないですね。
カラムを限定するようなケースが発生するのは大概検索画面なので、
わざわざビューを作る、というのもアリが気がします。
ありがとうございます。
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)についてはそのまま動くとのことで、どう修正すれば
動かせるのかどうかわからなくて困っています。
ここでいいのかどうかわからないのですが、よろしくお願いします。
まだ見てるかわからんが、HibernateならScrollableResultsがある。
ResultSetと同じようなカーソル的な使い方ができるので、
適度にevict()しながら処理すればいいと思われ。
正直O/Rまっぱーの利点がわからん。
簡単な表結合ならSQL書いちゃったほうが早いし
難しい表結合はO/Rまっぱーじゃ結局無理だし。
なにがいいのか俺にもわかるように説明してくれ。
DTO自動で作るだけならエクセルマクロで十分だし。
そのエクセルマクロ生成コードにむかついた人が張り切ってしまって
できたのがO/Rマッパー。
むかつかない人はそのままでいいよ。
＞簡単な表結合ならSQL書いちゃったほうが早いし
ORMの利点は、「SQLを書かなくていい」ではない。
＞DTO自動で作るだけならエクセルマクロで十分だし。
それを「車輪の再発明」と言う。
ダメエンジニアが行う愚行の一つ。
331 ：
328：2006/08/17(木) 18:32:31
>>330 で、結局利点はなんなのでしょうか（＾＾；
>>329 個人の趣味で使うものってことでしょうか？？
仕事で使うもんじゃないってことでFA?
>>331 オブジェクトとSQLのマッピング作業をフレームワークがやってくれる点。
ぶっちゃけ俺DQNエンジニアだとおもう。
まっぱーの利点とか理解できないし。
だから教えてくださいお願いします。
>>333 マッピングってDTOつくって、ResultSetから値を取り出してDTOに入れていくってことですか？
ただそれだけですか？
そこでそんなにバグが出たり工数がかかったりしてるんですか？
>>335 検索だけじゃなくて、挿入・更新のときのマッピングもね。
DQNかも知れないエンジニアを大量に使わざるを得ないプロジェクトで、
テーブル数が数十個ある場合で、カラムの追加変更などがある場合でも
フレームワークにやらせるよりも手作業の方が早くて確実なら使う必要はないだろう。
337 ：
328：2006/08/17(木) 19:10:21
それだけしか利点がないならやっぱ内の会社にはいらないのかもしれない。。
ほんとにそこでみんな困ってるの？？？
そのあたりって仮にまちがえてもテスト段階でバグ発見しやすい部分だと思うし
そもそもDTOに入れたり出したりするのなんてそんなに大変な作業でも
ないとおもうんですが・・・。
うちのシステムもテーブル150ぐらいあるし、
カラムの追加変更もときどきあるけど
一度に追加変更されるのって2、3テーブルぐらいのものだし
それだけのためにxml書いたりといった面倒な作業が
工数的、費用的ににペイするのかしら？？
あたらしいもの好きな人たちが趣味でやってる領域なのでは？
実際に業務に使ってるひといるの？？？
XMLファイルを手書きしてたらメリットは感じないたろうね。
トータルの記述量はあまり減らないし、かえって面倒と感じるだろう。
そこは自動生成するところだよ。
ORM=XML設定ファイル必須というわけでもない。
S2DAOや、Hibernate Annotation、EJB3はXMLによるマッピング不要だ。
340 ：
328：2006/08/17(木) 19:39:49
XMLをテーブル定義から自動作成する工数と
DTOなど自分でコーディングする工数
システム開発全体にかかる工数から比較したら
これらが締めるのは微々たるものでは？
＞XMLをテーブル定義から自動作成する工数と
＞DTOなど自分でコーディングする工数
ちがう。
テーブル定義からXMLとDTOとを自動生成する工数と
DTOを自分でコーディングおよびSQLとDTOの値の受け渡し処理の
コードを書く工数とその部分をテストする工数の合計だ。
後者の方が早くて確実なら使う必要はない。
342 ：
328：2006/08/17(木) 19:54:00
その2つだけをくらべたら後者のほうが遅くて不確実なんですが
OR mapperに潜んでいるバグのリスクや、
各OR mapperの使い方を覚える工数を考えたら
やっぱ使わないって判断かなあ。
そもそもわざわざ導入したところで削減できる工数が少なすぎるような気が。
あんだけ雑誌やネットで騒がれておきながら
メリットってこんだけなの？
なんかほかにメリットないのかしら・・。
そう感じてて、それで本当にいい！ ノープロブレム！
って思うなら、それでいいじゃねえか。
俺はDTOを自分で書くなんて冗談じゃねえが。
Hibernate Annotationでハッピーライフ。
344 ：
328：2006/08/17(木) 19:57:38
いや、どう感じるかは問題ではなく
客観的な指標から判断して
どちらが生産性の向上につながるのかが知りたい。
なんでこれだけのものにみんな大騒ぎしてるんだろう？
なんかあるのでは？って思ってしまう。
生産性にまともな測定方法なんてﾈｰﾖ
むかつくやり方を続けると、精神衛生に悪くて生産性が下がる。
それだけ。
＞OR mapperに潜んでいるバグのリスク
おまいのところがGavin Kingより優秀な開発者を抱えてるならリスクとなり得るなｗ
>>345 それは真理だな。
>>344 なんにもないから安心しろ。
頑張って車輪を発明し続けてくれ。
>>346 マジレスすると、Kingよりも優秀な奴が一人いてもダメだと思う。
HibernateやS2DAOがどれだけの人に動作検証されているのかを考えると、
それ以上の動作検証ができて、はじめて
「OR mapperに潜んでいるバグのリスク」が自作コードより大きくなると言える。
>>348 自作コードの方が普通は仕様が小さいから、
同程度の品質を確保するのにそこまでの動作検証は要らないけどね。
ORマッパには、いままでの長い期間で発見されたパフォーマンス
改善手法がデフォルトで組み込まれている。
ORマッパの大部分は関連テーブルのレコードを自動的に取得
できる。
百人がよってたかってデバッグしたコードと、どっかの中小企業が
自分たちのしょぼいプロジェクト用に作って二人か三人でデバッグ
したコードでは、前者の方が信頼性が高い。
ただし１テーブルのデータちょっと取ってくるだけ、しかもテーブル間
リレーションもほとんどない、毎回SQLをコンパイルさせる程度の
負荷などまったく気にしない、とかなら別に使う必要はなし。
大量のデータをinsertするような、バッチ的処理には向いてないね。
あくまで、オンライントランザクション処理を簡易化するためのフレームワーク。
万能ではない。
352 ：
デフォルトの名無しさん：2006/08/17(木) 23:09:32
まずはテーブルの構造からO/Rマッパー的に作る必要がある。
それができないプロジェクトは、リプレースするか、捨てるか。どっちかしかない。
>>328 とりあえず何か動かしてみたりはしたの？
Hibernateなら、ツール使えばスキーマ読み込んで勝手にクラス作成までやってくれるから
一度適当に使って試してみたら？
結局ツール適用のメリット有無なんて、対象システムや開発環境との相性だからな
>>176 忘れた頃に禿同
オレもエンティティにビジネスロジックを書きたくなってしまう。
GRASPじゃないけど、OO的に考えるなら、データに近いところへ
メソッドを寄せ集めておきたいんだよな・・・
自動生成されたエンティティをサブクラスするのはちとキモイしねぇ
>>176,354
＞自動生成されたエンティティをサブクラスする
ちょっと意味不明だけど
任意のクラスを継承したエンティティを自動生成できるツールがほとんどだよ
>>355 クラス継承によるロジック共通化をフレームワーク単位で行うと、クラスの拡張性が著しく損なわれるので
最近は避けられる傾向にある
最近DIコンテナを使った開発で多用されているのが、委譲による疎結合。
その場合はステートレスなロジッククラスが利用される。
これとドメインモデルとの相性がイマイチなのがORマッピング利用時の問題
ORマッパー自体がDIをサポートして、ロジックを委譲するオブジェクトを注入してEntityを作成することが出来れば
ドメインモデルでも疎結合でロジックを構築できるのでは？・・・という話
iBATIS2.2.0(β)
あれ？
iBATIS2.2.0って、ストアドプロシージャと
Beanとのマッピング出来るようになったん？
361 ：
デフォルトの名無しさん：2006/09/05(火) 02:43:56
ついに1000体突破かよ
アイロボットみたいだな
株ロボもいつか夢を見るようになるのかなぁ
質問なんですが
Hibernateでsessionキャッシュ上の永続オブジェクトに対して
オブジェクト単位での変更チェックは出来ないんでしょうか？
bool Session#isDirty(Object o, ...)みたいなものがあればいいのですが...
キましたね。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で確認取らせんな！( ﾟДﾟ)ｺﾞﾙｧ!!
あいばてぃす？
あいべいてぃす？
いーばてぃす
367 ：
デフォルトの名無しさん：2006/09/26(火) 01:36:02
シンクイットって登録しないと読めないから資料価値ない。
グーグルキャッシュに入らないマイコムにも言えるが。
エクセルマクロ生成コードにむかついた人が張り切ってしまってできたのがO/Rマッパーなのはいいが、漏れはO/RマッパーのXMLファイル作成にムカつくのはどうすれば良い？
誰かエクセルマクロからXML生成するツール作ってない？
つーかxlsファイル自体を読み込んでO/Rマッピングしてくれってのが、.NETのノリ？
＞誰かエクセルマクロからXML生成するツール作ってない？
当然みんなつくってんじゅねぇーの？
一々仕様書から写す手間を考えるとそりゃマクロで吐き出させるだろうし。
こういうのってオープンソースで一個作っちゃったほうがいいよーな気もするよな。
作ったらOSSとして公開でいいんじゃない？w
ソースはどこにうpされてるの？
会社で作ってて、パッケージ名までcom.なんとかになってるから、
さすがに公開はできんわｗ
373 ：
364：2006/09/26(火) 21:23:18
SpringFramework + iBATIS でのPL/SQL連携を確認。
つーかさ、DBの問い合わせから戻ってきた値が
<parameterMap>のclass要素のオブジェクトにマッピングされるのはいいんだが、
public List findList(String query, HashMap map)throws DataAccessException
{ return (List)getSqlMapClientTemplate().queryForList(query, map); }
↑のコードの意味無いじゃん。↑のメソッドを ArrayList list = (ArrayList)dao.findList(query, map);
で呼び出すんだけど、結局引数に渡したmapオブジェクト変数に格納し直されるっていう動作はどーなのよ。
いいの？これ。
どーいう意味かの解説は
ttp://canetrash.seesaa.net/article/2656752.html にあるんだが、動作的にねぇ…？
結局引数に渡したmapからListを取り出して、さらにBeanを取り出して…。
メンドクサーですよ。O/R-Mapperってこんなんなん？いや、動作的にはO/R-Mappingなんだろうけどさ。
識者コメント＆ツッコミ・キボンヌ。
374 ：
373：2006/09/26(火) 21:46:39
375 ：
デフォルトの名無しさん：2006/09/27(水) 07:55:54
O/Rマッパーじゃないけど、RailsのMigrateみたいなDBのバージョン管理できるJavaプロダクトって何かありますか？
あーゆーの欲しい。
>>368 blancoDb だろ。Excel O/R マッパー。
俺はそれを作ってる、いがぴょんっていう奴の顔がキモすぎて
試してもない。違うんかもしれんが。
377 ：
デフォルトの名無しさん：2006/10/07(土) 04:01:15
やっぱHibernate最高ですよね？
うちの会社に導入しようと思っています。
いまどきＪＤＢＣでＳＱＬ直書きなんて氏ねばいいと思います。
導入前に氏んでいるわけだな。
>>377 Hibernateがいいときもあるし、JDBCでSQL書きがいいときもあるし、iBatisがいいときもある。
最高ではない。
まあいまどきJDBCのようなところはとりあえず入れたほうがいいな。
見聞を広げるちゅー意味でも。
同意。
Hibernate最高とか言っちゃわない程度には触っておいたほうがいいな。
適材適所。「最高」なんてものは無い。
383 ：
377：2006/10/08(日) 10:47:35
いや、Hibernateは上級レベルの達人たちが
ものすごい工数をかけて作成したフレームワークだ。
Hibernateありきだ。
最初に。
もちろんHibernateではダメだというケースも
あるとは思うが、まずはHibernate最高と思っておいて
問題ないのでは？
JDBC APIだって上級レベルの達人たちが
ものすごい工数をかけて作成した仕様なのだが・・・
妄信してる信者の発言にしか聞こえない。
結局はどれが良いのか客観的に語ってよ。
386 ：
377：2006/10/08(日) 11:26:36
いや、Hibernateも内部でJDBCを使っている。
どんなシステムでも大抵、JDBCを利用するための
フレームワークを作っているだろうが、
そういうフレームワークとしてHibernateに
勝てるわけがないということだ。
うちなんてHibernateどころかServletすら使えないよ
DBまわりはWrapperがあるけど
BroadVision6...
＞そういうフレームワークとしてHibernateに
＞勝てるわけがないということだ。
すげぇ盲信っぷりにﾜﾛﾀ。
まあ言い方はあれだけどｗ、
日本の会社が自社で作っていたものとは次元が違う存在というのは言うまでもない。
すべてのケースに適しているとはいえないが、
使ったこともないじゃORマッパーを語れないな。
俺はjar（というか使ってるクラス）があまりにも多すぎるところがいやだな。
入れたら起動も死ぬほど重くなるし、OutOfMemoryにもなりやすい。
サーバーにいくつもHibernateを使ってるWebAppがあったら目も当てられない。
そんな貧相な鯖で Java を動かすこと自体が間違ってる。
フレームワークは目的ではなく手段。
無駄な残業したくないなら要件にフィットするものを選ぼう。
冷静に、冷静に。
あれこれ選び分ける程の余裕もスキルもありません。
可能な限り「標準」で行きたいのだけど。
JPAはしばらく安定しないだろうなぁ・・・
>>386 Hibernate に詳しいようだから、使ってみた感想でいいから
他のいくつかの O/R マッパーと比較して何かいいか
教えてくれないか？
俺には何がいいかさっぱり分からんので。
まずいエサだがスレの内容には沿ってるな＞393
Hibernateのよさは、資料が多いことだな。
俺はCayenne > Hibernateだと思う。複雑なクエリを
HQLで書くのは俺には無理。
ごめん、途中で送信した
O/Rマッパーの有用性はわかるけど、Hibernateの優位性がわからないのか
O/Rマッパーの有用性がわからないのか、どっちなんだ
前者ならJPA実装の中でも枯れてるしData Mapperパターンでは決定版に近いってレスになるし、
後者なら、そうですねってレスになる
O/R マッパー自体の有用性が分からない、つーのはスレ違いじゃね？
有用性があるのが前提で、優劣を議論するのがスレの趣旨じゃね？
>>397 適用範囲を把握するという意味では、
有用性自体を問うのもありだと思ふなり
ド短期製造、お前らなら何使う？
製造期間 10 日、マスタメンテ 3 機能。
DB 設計済み（複合キー）、検索条件は可変多し。
製造担当はたぶん JDBC 直以外知らない。
学習工数、製造工数の少なさを最優先。
JDBC 直、Hibernate、iBatis、DBUtils、、、
＞製造担当はたぶん JDBC 直以外知らない。
＞学習工数、製造工数の少なさを最優先。
10日間に学習工数も含めるのなら、断然JDBC直。
フレームワークは学習コストがそれなりにかかることを
認識しておかないと痛い目を見る。
それを認識できてない奴が「生産性が低い」と騒ぐんだ。
強いて何か覚えるなら、ORMよりもDbUnitでも覚えておいた方がいいんじゃね？
短期なのに学習コスト込み？てか１０日？
ギャグのつもりじゃなかったらやめたほうがいいだろう。
JDBC直よりは、closeし忘れとかを防止する意味で、
DBUtilsの方がいいんじゃない？
まあ、10日であることを考えたらJDBC直でもいっか。
悩んでいる暇があったら、早くやれって感じだ。
JDBC直でResultSetMetaDataとDatabaseMetaDataをひっぱって
全テーブル同じクラスで処理する。
仮に実装担当者が「色々とORM知ってます」と言ってきても
ちょっとしたもんならJDBC直（or 学習コストがかからん DbUtils）で十分。
後々メンテ担当者がチェンジする時のリスクも小さかろう。
>>400 DbUnit も知らんとか言ってたな。
一応、俺が Struts 上にアクセス制御、セッション管理、ログ、エラー制御あたりの
共通部を 2 日ぐらいで俺が作って後は任せようかと思ってる。
Click か Wicket も考えたけど 10 日じゃこわいんでやめとこうと思ってる。
>>402 俺はフリーで複数案件やってて60 万で案件とろうとしてるだけだ。
60 万ぽっちじゃ、10 日ぐらいでやらんと割りにあわんだろ。
部下の勉強がてらに良いと思ったんだけど意見を聞きたかった。
>>404 JDBC 直で close し忘れ防止は Session in View パターンで
ServletFilter でも作るわ。
>>405 結果は Map に格納すんの？ リフレクションで Bean？
昔作ったような気もするけど、それだったら何かあるやつ使うかなー。
>>408 勉強がてらなら、もっと納期が厳しくない案件でやらせた方がよくない？
確実に作らせたいのなら、担当のスキルと日程をふまえて指示する側が見極めないとな
あと、DbUtilsにするんなら、1.0は色々問題があるからdevelop版を使ったほうがいい。
可変長の引数が可能ですが、引数取り出しの扱いがわかりません。
function! AllRead(...)
while args
r args
endwhile
endfunction
どうすればいいでしょうか？
>>409 thx。DbUtils か JDBC にするわ。
Hibernate 3.2.0 GA
Hibernate Annotations も Hibernate EntityManager も同時に 3.2.0 GA
ガッはなんだガッは
Generally Available
以前ibatisで使った開発のときテーブルごとのクラスに結果を詰め込むようにしてたんだけど
結合テーブルのSQLなんかのとき都度それにあった結合テーブルクラス（必要なカラム以外もすべて定義）を使って結果を返していた
つまり結果は絶対SQLのと同じ表形式だったわけなんだけど
普通そういう設計するの？
複合キーのテーブルの場合代理のキーを作ってDB設計したほうがHibernateとかでは使いやすい
と同僚が言ってた。代理キーはシーケンスで振っていくようにするといってたけど
そうすっと一意制約が保障できないような気がするが、回避方法あるのかい？
>>418 UNIQUE制約ってしってるか？
PRIMARY KEYとは別にUNIQUE制約をかければいいだけだよ。
>>419 そりゃそうだ。なんできずかなかったんだろ。ありがとござんした
>>418 一意になるように代理キーで、作るべきだと思うけど。
ああ、勘違いした。複合キーが一意であることね。
ごめん
>>417 例えば、どうなってほしいの？
クラスを作るのが面倒ならば、Mapを使ってもよいと思うが、そうなるとタイプセーフではなくなる。
>>423 あーたとえばですね、親子関係のテーブルなんかの場合
親テーブルクラスに、子テーブルクラスを保持するフィールドもたせて
クエリーの結果をそういう感じで保持すんのかな？とおもって。
Hibernate で直に SQL 発行して結果を
Map のリストで受け取ることってできますか？
Hibernate を使わなければならず、
でも結果は Map で返さんとだめで、
entity クラスも作成できないんです。
426 ：
デフォルトの名無しさん：2006/10/25(水) 23:31:47
保守
>>425 たぶん駄目じゃない。
Spring使ってるならJdbcTemplate。ないならDbUtilsでごまかしとけば。
>>427 助かりました。
JdbcTemplate#queryForList
でごまかせるような気がします。
430 ：
デフォルトの名無しさん：2006/11/02(木) 00:22:59
dbutils 1.1 ってまだ開発中？
使いたいのだけど、1.0はだめだって聞いたんだけど。。
他のがいろいろでてきたからもう開発ストップしてるんかな。
>>430 dbutils、シンプルで使いやすいから愛用してるんだけど
あんまり使ってる人いないのかな？
何故だか各種ORMと比較されてショボイと思われてる感はあるかも。
個人的にはQueryRunnerがPreparedStatementを
基本、隠蔽する方向になってるのが何だか惜しいって印象。
まあ、そうしてもらうと楽な面も、もちろんあるんだけど。
>>431 俺も愛用している。
設定ファイルいらずだし、MapListHandlerの結果をJSP内のELで使うと超ラクで気に入ってます。
dbUtils、いいんだけどBeanHandler使うときのフィールド名とプロパティの
マッピングが普通とちがうのがちょっとなぁ。あれは直してくれんかな。
booleanのときとか？
>>434 フィールド名/プロパティ名が2語以上から成るとき、DBでは通常アンダースコア連結、
Javaはキャメルケースで表記するでしょ？
他のORMにはそこを変換してくれるものもあるけど、dbUtilsは単にcase-insensitiveで
比較するだけだから、
SELECT ID_DATA AS IDDATA
とか、
public void setId_Data() {
とか書かないといけない。
DbUtilは、キャッシュも遅延ロードも無いし、
commons BeanUtilsのリフレクション使いまくりだから、目に見えて遅い。
大規模・高負荷なシステムでは使えない。
けど、シンプルで俺は好き。
自社のお問い合わせ送信フォームとか、
小規模なマスタメンテとかで使ってみたことがある。
ORM使ったこと無いので教えてください。
DbUtils以外のORMはリフレクションを使わずに、Beanにどうやって格納したりしているの？
キャッシュが高速なのは分かるのですが、逆に古いデータを読んでしまうことにならないかも気になります。
>>439 キャッシュとDBの同期化をどうするかというAPIも用意されている場合も多いので
アプリケーション側でも制御できるし、デフォルト設定も変更可能な多い。
リフレクションを使わず、バイトコードをゴニョゴニョしたりするフレームワークも多い。
>>439 ＞キャッシュが高速なのは分かるのですが、逆に古いデータを読んでしまうことにならないかも気になります。
何か勘違いしてるんじゃないか。
>>440 バイトコードを変えることで、リフレクション使わずにセットしてたりするのか。
それは知らなかった。かなり高度なことをしているんだな。
>>441 こう考えているんだけど、勘違いしてると思った点を教えてくれれば幸い。
キャッシュを使えば、DBにアクセスすることなく、取得済みのデータを再利用するので、高速だと思っている。
「古いデータを～」と思ったのは、データがすでに更新されたのに、
更新前のキャッシュデータを使ってしまうことがないのか？ということを気にしている。
なんか間違ってるだろうか。
＞「古いデータを～」と思ったのは、データがすでに更新されたのに、
＞更新前のキャッシュデータを使ってしまうことがないのか？ということを気にしている。
ここの意味がよくわからん。
ひょっとして、複数のサーバでそれぞれ同一DBに対して
接続するとか、そういう使用法を考えてるわけ？
>>438 DbUtils から BeanUtils への依存関係はないんじゃない。
>>444 すまん。勘違いしていたらすい。
リフレクションAPI直叩きだね。
複数のサーバとは限らないけど、1つのDBに対して、複数の接続が発生するのが普通では？
キャッシュってのは、DBの複製的な情報を、アプリ側で保持するわけでしょ。
検索→キャッシュ生成→（他スレッドなどがDB更新）→キャッシュの値は更新前の値のまま
もちろん、ORMを使わず更新するとかが、論外なのは分かっているけど。
ここまで書いてきて気づいたのだけど、
1つのDB接続セッション内で、キャッシュされるのかと思ったけど、
全体でキャッシュを共有して持っているということ？
それならば、「更新前のデータを見ない」という意味は、理解できる。
そもそも
>>443みたいな設計がおかしいんじゃないか？
それともEJBのことを指しているのか？だとしたら意味が違うと思うが
＞検索→キャッシュ生成→（他スレッドなどがDB更新）→キャッシュの値は更新前の値のまま
~~~~~~~~~~~~~~~~~~~~~~~
これ何よ。こんなことするなよ。
アノテーション使えるDbUtilsが欲しい…
451 ：
447：2006/11/04(土) 01:39:13
>>449 えーと、シングルスレッドで、順番に更新しないと駄目という意味？？
Hibernateのキャッシュは2段階になってる
1次キャッシュ(Session)は一つのスレッド・トランザクションに閉じてる
自分でアクセスしたエンティティを再利用するだけだから遅延はない
2次キャッシュは複数のスレッド・トランザクションで共有されて実装を選択できる
2次キャッシュの実装に分散キャッシュを使えば複数のプロセスでも共有できる
遅延に関しては実装次第
一定時間でリフレッシュするのもあれば他プロセスから更新通知を受けるのもある
分散ロックや分散トランザクションをサポートしたものもある
当然遅延とパフォーマンスはトレードオフだから用途に合わせて実装を選べばよろし
>>451 そうじゃねーべ。
Hibernateでも何でもいいから一旦勉強してくれ！
454 ：
447：2006/11/04(土) 02:06:22
>>452 なるほど。
1次キャッシュなら、遅延は無いものの、キャッシュとしての効果は薄いと思うし、
2次キャッシュは、どうしても遅延が発生するだろうと感じていたのです。
キャッシュを利用して高速になるからといって、やはり遅延することを無視できないわけですね。
>>441の話だと、遅延があり得ないように、聞こえたので疑問に思っただけです。
>>453 ごみんなさい。勉強しときます。
だから、Hibernateのデフォルト設定では
更新前に一旦SELECTして同期するようになっている。
DBを他システムからも操作されることが想定される場合には
SELECTを含むクエリ発行のたびに毎回キャッシュと同期化するようにもできる。
他システムから操作されないのなら、キャッシュを最大限に利用する設定にすることも出来る。
456 ：
デフォルトの名無しさん：2006/11/04(土) 11:04:04
>>438 リフレクションやっぱ遅いのか。
ユーザ数の少ない業務アプリケーションしか作ったことないから、
SQL以外の速度気にしたことないな。。
気にすることないよ実際。
>438はまともにプロファイリングしたことないかな？
相当いびつな使い方をしない限り影響はない。DBのそれと比べると誤差の範囲。
なんか Hibernate ＆ DbUtils なモードだな。
DbUtils だけど、キャッシュはともかく、遅延ロードが無いことに関しては
ナマSQLを書く以上、SQLの書き方／コーディング次第な所なんで
大規模・高負荷なシステムで使えんって理由には直結しないんじゃないかな。
>>457はdbUtilを使ってまともなアプリを作ったことが無いのだろうか。
大規模・高負荷とか言ってるけど、逆にそういう用途にHibernateとかのORMは
使うのを躊躇するけどな。
キャッシュがあるといっても、このレベルじゃ到底信用できないし。
実際そういうところに使っている人いる？
俺の場合、パフォーマンスが必要なところでは基本JDBC直、得失を考慮したうえで
問題ない部分ではdbUtilsを使って楽をしてもいいかな、という感じ。
Hibernateを使うのは、パフォーマンスをあまり気にする必要がないところで
ちょっと複雑なデータを永続化したい場合だな。
今のHibernateはEJBの実装。
大規模システムでの利用を前提にしたプロダクトだと思うけど。
元々EJBは大規模つぅか分散システムのアーキだしなあ。
パフォーマンスクリティカルな案件じゃ
JDBC直（＋軽いラッパ）が実状じゃなかろうかと
一口に大規模高負荷と言っても、同時多アクセスのWebシステムなのか
大量データ一括処理のバッチなのかで大きく違うよね
前者ならHibernateの２次キャッシュが活用できそうだし
後者はやはりJDBC直書きか（というかストアド使えるならそっち使った方がいいかも）
>>462 分散前提のEJB2と分散前提ではなくなったEJB3は大きく異なる。
更に、EJB３からも独立したJPAは分散とは無関係
464 ：
デフォルトの名無しさん：2006/11/04(土) 23:04:37
Hibernateにはバッチは向いてないの？
465 ：
デフォルトの名無しさん：2006/11/04(土) 23:05:40
うちの会社でHibernateか、Torqueか、iBatisか、JDBC直を
検討しているんだけど、どれがいいの？
個人的には
通常：Hibernate
バッチ、複雑なＳＱＬ:JDBC直
かなあ
>>464 バッチには向いてないだろうね。
>>465 あなたの見解は正しいと思う。
Torqueは論外。
>>449 Webアプリなんかじゃ、ふつーに別スレッドに更新されることが、あるんじゃねーの？
>>465 自分で選べないくらいプロダクトの特性を理解してないなら
どれを選んでも失敗する
煽ってるだけだから気にすんな
しかし、なんだ。
バッチ系にもWEB系にも使えるものてのは、ありそうでないもんだな
万能ってのは無いよ。数あるフレームワークを適材適所で使うのが現実的。
うちでは、勉強するってモチベーションが低いのか、ちっともHibernateや他ORMが受け入れられない。
複雑なクエリ文を、しこしか書いている人たちに、HQL使えって言うのは厳しいし、
無理して使ってもらうこともないんだけど。
Hibernate最高って人は、
（実行パフォーマンスに目をつぶっても）開発側が楽だから？
それとも、（開発は多少面倒になるが）実行時に効果的だから？
もしくは、その両方？
今からHibernateのAPIやHQLを覚える必要はほとんど無い。
JPA/JPQLを使えよ。
開発効率も品質もそれなりの前提知識・意欲を持つ人が集まることで
ある程度保障されるものだし、何とも言えないんじゃ。
ただ、コンパクトなJDBCラッパだけで色々な案件を
問題無く捌けてりゃ、それはそれでハッピーだとは思う。
>>474 実行パフォーマンスについては、上手く作ればWebアプリ等では逆に早くなることもある。
開発に関しては、たしかに覚えることは多いが、
リスナーを使ってDBのトリガーみたいな処理をプログラムを使って書けたりとか、
あとは特に排他制御実装が非常に簡単になるのが嬉しい
SQLも使えるから、難しいところは無理にHQL使わずに積極的にSQL使えばいいし
（FROM句への副問い合わせやUNION以外はだいたいHQLで書けるけど）
たとえば、よくあるWebアプリの一覧検索から１件選んで更新処理とかする画面だと
一覧を取ってくる所は複雑な問い合わせ文になることが多いから
SQLをORMに投げて結果をBeanのListで受け取る。
１件選ぶ処理では主キーを渡してORMでEntityを受け取る。
そこから先はORMの機能だけで関連Entityを取って来たり、
排他制御しつつ更新処理とか全部やってくれる。
排他制御ってSpringやSeasarといったDIコンテナに
任せるものと違うの？
SpringやSeasarがテーブルのバージョンカラム定義や、
更新時の自動バージョンカラムチェックとかやってくれるのか？ｗ
トランザクションかとおもたｗ
比較的S2DAOが、バッチもオンラインも対応しやすい。
Seasarのリスクを受容出来るなら、S2DAOと必要に応じてストアドあたりが、
いい感じだな。
ibatisにsqlをフォーマットするクラスはありますか？
プリペアードステートメントの「?」にサブクエリーなどのＳＱＬを書いても
ＳＱＬではなく短に文字列として処理されるのでしょうか？
さらにibatisは$xx$はプリペアードステートメントの「?」で、#xx#はＳＱＬとして展開ですよね？
hibernate 3.2
hibernate annotation 3.2
hibernate tool 3.2
Eclipse 3.2
な環境でPOJO(アノテーション付き)からその他もろもろを生成したい。
>>485 今普通にそれでやってる。その他もろもろってDDLくらいしかなくね？
とりあえずHibernateのサイト見ればできるようになんだろ。
そういやDdlUtilsってアプリ組み込みDB初期化に便利そうなんで
早くリリースされないかなぁ。
sqlを見やすいようにフォーマットしてくれるクラスありますか？
ibatis、dbutils何でもいいのですが・・
一口に見易いと言っても好みがモロに出る所だと思うが、
とりあえずカンマの前後で改行入れる程度のものなら
自分ででっち上げる方が早い気もする。
そういうツールはいくらでもあるじゃん。
491 ：
デフォルトの名無しさん：2006/11/20(月) 04:29:31
MySQLにテーブルをいくつか作って、
Hibernate Toolsを使って.hbm.xmlと.javaを自動生成させた。
one-to-oneになって欲しい部分がone-to-manyになっている。
困った。
>>490 すいません。ツールは知っているのですが、管理者からＰＧ側から整形済みをログで吐き出せといわれていまして・・・
管理者ならログ整形するツールくらい用意しろよと言い返せ。
Hibernateなら整形出力あるんだけどね
496 ：
デフォルトの名無しさん：2006/11/27(月) 01:29:48
WebアプリでHibernateを使うとき、updateて普通どうやるんですか？
マニュアルとか見ると、一般的なやり方として
load -> データ変更 -> update
しかないみたいなんですがWebアプリだとloadとupdateの間に
画面遷移が入るのが普通ですよね.
・最初にloadしたデータをセッションにでも入れておく
・updateのときにもういっかいloadする
・loadはせず、自分でオブジェクトを生成してidや全てのプロパティを手動で設定
どんなふうにやるもんなのでしょうか.
・最初にloadしたデータをセッションにでも入れておく
の後、データを再度トランザクションにくくりつける。
・updateのときにもういっかいloadする
は、勝手にやってくれる。
>>496 前の画面で取得したEntityをsessionなどに保持しておいて
Session（Hibernate Core）使うならupdate
EntityManager(Hibernate EntityManager）使うならmerge
手動で再loadとかすると、排他制御をHibernateに任せられなくなるので
お勧めできない
ちなみに、同一トランザクション上なら、取得したEntityは
値を変えるだけでUPDATEされるので、updateメソッド使う必要はない
ここを間違ってupdateメソッド使うかのように書いてる本が多いので、騙されないように
499 ：
496：2006/11/27(月) 03:00:40
ありがとうございます.
セッション管理がいやなので更新時再loadでやろうと思ってました...
ブラウザのウインドウをいくつも開いて同時に編集というのを
許可する場合はどうするんでしょうか？
entityの種類とidごとに別のキーでセッションに入れたりして、
セッション内に作業中entityをどんどん保存/updateしていく
という感じになるんでしょうか．
ログを常時監視してる場合も有るから、人間が直接読めるってのは重要な場合も有るかと。
まあ要求するのは良いが、それならおまいが管理までやれって返されるだけだよ(w
やぶ蛇にならないようにガンガレ。
ログを監視する場合はむしろSQLを整形して吐かれるのは嫌だと思うんだけどなぁ。
ログは、基本一行で全部出して欲しい派。
正規表現で取り出しやすくなるし。
いつの間にか、Dbutils1.1が出てますね。
Java6のJDBC4.0使った簡易O/Rマッピングってどんな感じですかね？
>>498 いつも思うんだけど、Hibernateで排他制御を任せると、
複数サーバでの運用って事実上無理にならない？
JavaVM1つでしか動きを保障できないようなフレームワークが
なぜこんなに流行るのかわからない。
複数サーバの並列運用が必要な案件がそんなにないからじゃないかと。
大規模案件はやっぱりEJBの出番なんでしょう。
>>505 普通にHibernate経由でDBロック取ればいいじゃん。
API提供されてるし。
>>506 なんでEJB？
分散を最初から考慮しているってのは確かに大きいな。
509 ：
507：2006/12/07(木) 23:33:33
>>506 ちょっと喧嘩売ってるみたいな書き方になった…
補足すると、そもそも並列稼動の実装ってかなり設計に依存するから
安易に大規模案件=EJBを持ち出す意味がわかんないって話。
単純なスケールアウトの話で、VMをまたいだキャッシュの同期を
意図してたならHibernateでもいくつかサポートしてるキャッシュ実装があるよ。
※Coherenceとか
ま、JBossのEJBって話だったら別に変わんないか。
>>505 Hibernateの排他制御は基本的に楽観的排他で、
UPDATE文発行するときに、検索条件に主キー＋バージョンカラムの値をつけ、
UPDATEの結果が０だったら排他エラーにするものだよ
同期を取っているのはあくまでもDBで、JVMは関係ないと思うけど
２次キャッシュに対する更新は、たしかに複数サーバでの運用が問題になるが
そんなときはクラスタ対応のJBoss TreeCacheを使えばいい
>>510 へー、そうなのか。勉強になった。
どちらにせよ、最近は状態を頑張って各ノードで通信して同期するより、
なるべく状態非依存にしてスケールアップする方向に進んでるから、
Hibernateの挙動はあまりいくないと思う。
>>511 参考までに聞きたいのだが、状態を持たない場合、複数画面の排他制御ってどうやってやるのが普通なの？
主キー＋バージョン値だけを保持して、バージョン値も条件に入れて再SELECTとか？
ただこの場合、関連するEntityを同時に再SELECTする場合、全部のバージョン値を保持しなきゃいけなくなるよね
自分もHibernate使っていたとき迷ったのだが、結局HttpSessionに保持してmerge以外に良い方法を思いつかなかった
>>511 Hibernateの挙動というよりは、単に2次キャッシュを使わなければ良いだけでは？
OptimisticLockも2次キャッシュ同様にデフォルトでは有効でないから
そこに文句をつけるのは違うと思う。
> どちらにせよ、最近は状態を頑張って各ノードで通信して同期するより、
> なるべく状態非依存にしてスケールアップする方向に進んでるから、
これ、そうなの？クラスタ系プロダクトの信頼度が上がってくるのはこれからじゃないのかな。
あと、下のケースはスケールアウトと間違えてない？
ibatisでカスタムタグを作ることってできますか？
>>514 OpenSessionInViewパターン的な仕組みとやりとりするカスタムタグを
作るってことなら、そんなに悩まずできるんじゃないの？
iBatisだろうとHibernateだろうと生Jdbcだろうと。
おれなら半日で作るね。
半日もかかるのか。ｲﾗﾈ。
タグ作って、テストして、プロジェクトの他メンバーに仕様を伝えるためのドキュメント作って・・・
としていたら半日なんてあっという間。
ibatisの設定ファイルに書くタグのことじゃね？
gcの対象って、インスタンスだけじゃなくてクラスも対象なんですか？
クラスに定義してあるメソッドの実行コードもメモリから消えちゃう？
Ｃをやっていたとき、実行コードはメモリのtextにロードされるから、
textエリアは書込み禁止なはずなので・・・、javaでは実行コードはtextに書かないのかな
JBOSSなんて実運用で使ったら軽く死ねるよ。
コストかけても商用のEJBフレームワークを採用した方が、ロードバランサも不要で安くつく。
syslogやsnmpで監視しても、最後はopenviewのSQL DBに突っ込んでるしねえ。
加工することを考えると、SQL DBにログを突っ込むのは悪くはない。
syslogのテキスト処理しか出来ないperl廚が困るだけでしょ。DBIぐらい覚えろよと。
GlassFishでいいんじゃね？
ほんとに意味不明だなｗ
ある種の才能。
HOS
526 ：
デフォルトの名無しさん：2007/01/17(水) 22:43:07
取得する列を可変にしたいのですが、iBatisではどうやればいいですか
DBの型とJavaの型マップのデフォルト値を取得する方法ないでしょうか？
java.sql.Connection#setTypeMap で型マップの上書きができるのは、分かったのですが・・・。
フレームワークとは直接関係ないんだけど、良いDAOの作り方というのが
いまいちわからん。
検索条件が複雑なユースケースがたくさんの場合、メソッドの引数やDTO
だとすげー煩わしくなってくるんだけど、みんなはどう対応してる？
529 ：
デフォルトの名無しさん：2007/01/18(木) 23:59:20
>>528 検索はほぼＤＴＯですね。。
あとで変更があっても影響範囲極小にできるから
DTO でもめんどいと、もう Map しかないよね。
うぇーって感じだけど、DTO 書きが面倒というような規模
(ビューからDAOまで自分一人とか)なら、Map は割と現実的な
解だと思ってる。
SELECT文からDTOを児童生成するようなフレームワークって無いのかな？
Velocityとjava.sql.ResultSetMetaData使えば結構簡単に作れそうな気がするけど。
一時期作ってたけど、
同僚のマの人がせっせこ作ってくれるんで途中で投げた。
Hibernate以外でDAOでオブジェクトを生成するとき、みんなどこまでの階層を読み込んでる？
基準とかあるのか？
あるあるｗｗ
Mapが面倒ならRowSet使うのがいいと思われ
JPAとかこれから普及すると思うが、テーブル単位で扱うのが常識なのだろう
RDBに慣れた人ならjoinつかって重複するデータ部分も生成してすべてOneToOneでつなげれば今までと同じように使えるし
既存コードからの変更はわりと容易
535 ：
デフォルトの名無しさん：2007/01/19(金) 19:14:25
もれのORマッピングに関しての認識がどうも間違ってるみたいなので教えてください。
ORマッピングフレームワークにはHibernateやToplinkなどが一昔前からあり、
最近JPAというものが登場し、JAVAEE5、SE6にも取り込まれている。JPAはEJB3.0でも使用されている。
JPAはコアの部分にtoplinkを使っていてtoplinkエッセンシャルと呼ばれる？
なんかよく分かんないのですがあってます？
あってない
まずJPAはEJB3.0の中のひとつ
ただし、JavaSEでも使えるように独立している
toplinkはJPAの実装のうちのひとつででリファレンス実装となっている
サーブレットコンテナのリファレンス実装だったTomcatと同じような位置づけ
537 ：
535：2007/01/19(金) 20:32:39
>>536 ありがとうございます。
なんとなく理解できました。
EJB3.0の中にいたJPAは独立可能なのでSEにも加えられて、
toplinkとJPAの関係は Myfacesとjsfみたいなもんというわけですね。
めもめも
JavaSE6にJPAは取り込まれてない
すみませぬ。質問させてください。
取り出したレコードがコード値(性別とか)を保持している場合、0 -> 男性 などのマッピングはいつ行えばいいのでしょうか。
あとDTOにコード値とマッピング後の文字列、両方を保持するのが一般的なのでしょうか。
そのへんは突き詰めるとSEXSテーブルを作ってSexオブジェクトを作って…。みたいになりそうだ。
enumうまく使えたら良いのかな？
541 ：
デフォルトの名無しさん：2007/01/20(土) 01:15:37
>>539 DTOにマッピングの文字列を取得するメソッド作成するかな。。
確かにこういうの迷いますよね。。
542 ：
539：2007/01/20(土) 11:34:33
SQLで結合してしまえばいいともおもうのですが(iBatis使ってるんで)顧客とかって結構コード値で管理してるデータが多いじゃないですか。
SQLのFromにだらだらと並べるのも嫌だし。。。
今のところマスタ系のデータはグローバル領域で保持して、View(jsp)でマッピングするという流れになっています。
543 ：
328：2007/01/21(日) 02:02:35
マッピングはviewじゃないかな？
544 ：
デフォルトの名無しさん：2007/01/21(日) 21:32:58
viewかー
545 ：
某スレ167：2007/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の重力に魂を引かれていくのか……（苦笑）
ま、これは本当の余談ですけどね(^^;
S2/S2DAOはいいと思うよ。
Hibernateを今から覚えるぐらいなら、JPAを覚えて、
HibernateはJPA実装として使うという位置づけでいいんじゃないか？
>>545 Hibernate使ってる身としては、もう1:Nマッピングとかを自分で書く気にはなれないな
DBの定義に関する情報は、フレームワークがスキーマ読み込んでクラスまで自動作成すべき
たしかにHibernateの学習コストの高さはネックだけど、
JPAが出たおかげで、マッピング周りはかなり簡単になったと感じてる
あ
え？
550 ：
デフォルトの名無しさん：2007/02/19(月) 22:28:19
iBatis
abatorConfigでsqlMapを自動生成するとかなりいろんな条件いれてくれたり、XXXExampleとか作られるのがうざいんだけどなんとかならない？
Hibernate...
いちいち関連を定義しないと外部結合できないのはなんとかならんのか。
>>551 それがあるから、Entityに関連書きまくることになるんだよなぁ
553 ：
デフォルトの名無しさん：2007/02/25(日) 01:51:51
>> SELECT文からDTOを児童生成するようなフレームワークって無いのかな？
DBFluteとDolteng はSQLからS2Dao用のDTOを生成してくれるよ
554 ：
デフォルトの名無しさん：2007/02/25(日) 12:14:08
>>553 そりゃあもちろん、SELECT文はDTOを出産しない＞児童生成
認知してよ！
>>551 SQLを意識するならHibernateを使わないほうが良いと思われる
むしろXMLで定義するだけでオブジェクト間関連を永続化してくれるのはありがたいと思え
Hibernate は先にオブジェクトがあって、
永続層がたまたまRDBでしたって感じで使わないと
無駄に時間かかるだけだな・・
何故俺の行く先はロクに正規化もされてない神聖不可侵な
クソスキーマがアプリオリに存在してるのばかりなのはなんでなんだぜ。
>>558 たぶん、
>>557の転職先でも、同じようなDB設計になるはずｗ
つまり、それは運命ｗｗｗ
>>556 外部結合と、SQLを意識するしないは関係ないよ。
（SQL特有のものだったら、そもそもHQLにouter joinなんて単語は出ない）
単に機能が不完全なだけ。実装が面倒だったんだろ。
内部結合は関連なくてもできるしね。
HQLでのouter joinとかって苦肉の策だと思うのは俺だけか？
普通なら結合条件つけなくていいと思うんだが・・
>>561 FETCH JOINで使ったり、SELECT new ...()で外部結合テーブルのカラムを含めるときに
普通に使ってるが、なぜつけなくていいと思ったの？
>>562 お前、全然オブジェクトで考えられてないのなｗｗｗ
>>563 考えられてないでいいけど、なぜつけなくていいと思ったの？
>>564 オブジェクト中心に考えてるとつけなくていいから
>>564 HibernateってORマッピングフレームワークだぞ。
Object-RDBだぞ。
Object中心に考えないとおかしい使い方になる
FETCH JOINは通常パフォチューで使うもので、オブジェクト中心とか関係ない
N+1セレクト問題を避けるため、関連を全てLAZYで定義して
HQLのFETCH JOINを使うのがHibernateの常套手段
また、レポートクエリをEntityのみで無理矢理行うのは馬鹿げている
HQLならSELECT new、またはSQLQueryで普通にSQL発行すればいい
全てをEntity中心に行うのは無理で無駄。
Entityは排他制御＋登録・更新処理で威力を発揮する。
レポート機能はSQL中心に考える。適材適所で使えばいいんだよ
568 ：
デフォルトの名無しさん：2007/03/01(木) 11:58:30
>567
俺ならレポート部分はJDBC使う
> N+1セレクト問題を避けるため、関連を全てLAZYで定義して
> HQLのFETCH JOINを使うのがHibernateの常套手段
どこかに資料ありますか？
>>569 Hibernate in Action
そういやiBatis in Actionの訳本出ないかな～
レポートとか統計取るときにオブジェクトで考えてもおかしくなるだけだもんな。
そーゆー時には統計に優れれた言語であるSQLを使うのがやっぱり正しい。
RDB-Objectマッピングフレームワークの方がよくね？
つまりJava以外の話をしたいってこと？
O/R でなく R/O になってるところがポイントじゃね？
Object の永続層に RDB 使うためのマッピングフレームワークではなく、
RDB が先にあって、プログラミング言語から簡単に使うためのフレームワークなのでは。
DBを最初に考えて使いやすいものを
となるならJDBCRowSet使えばいいじゃない
データ構造はRDBのER図＋正規化で決定するけど、プログラムはオブジェクト指向でやりたいのよ
なら普通にJPAでいいだろ
JPAはObjectありきじゃね？
俺もRowSetにいっぴょ。
データをハンドリングする部分がオブジェクト指向で書ければ、
データそのものは生っぽくてもいいよ。
>>579 先にDBを定義しておいても使えるし、先にクラスを定義しておいても使える
どっちがメインかなんて意味なさ杉
おれはオブジェクト図を先に作るほうだけど、
ER図でどうなるかとか、SQLで結合しやすいかなどは考えながらやってるよ。
そういう意味じゃO-R-Oマッピングくらいか。
HQLやEJQLを使えば何でもできるというのはなんか違う気がする。
こいつは必要悪とは言わないがある種の妥協なんだと思う。
iBatis
テーブルごとにsqlMapを分けてるんだけど、
呼び出し側でnamespace意識して呼び出すことってできないの？
RDB使う時点で、性能やコーディングやりやすさはRDBの方に制約が大きいから、RDBの比重を大きくしたほうがしたほうがいいと思う。
こんな過疎スレがあったとは・・・・・・
586 ：
デフォルトの名無しさん：2007/04/12(木) 19:09:54
hibernateなんだけど、one2many to many なテーブルをone2manyなBeanにする方法ってありますか？
具体例を挙げると、ショップとカタログと商品のテーブルがあるとすると
カタログテーブルはショップIDと商品IDのユニークな組み合わせを持ってて、他にカラムは無い状態。
実際はあるオブジェクトに対してカスタム属性を付加するアプリなんだけどね。
586って、いわゆる many-to-many だと思うんだけど、違うの？
どう見てもただの many-to-many です。
カタログがリンクテーブルっぽいけど、商品から見たショップは1だろうからmany-to-manyではないんじゃないの？
よくわかんないけど。
>>586は「one2many to many 」って言ってるじゃないか
それがなんだかわからんが
カタログテーブルの商品IDがユニークなんだろ
593 ：
586：2007/04/17(火) 18:45:14
ただのmany-to-manyのようでした。
カタログテーブルにあたるビーンを作ってしまったのが混乱の元のようで。
594 ：
デフォルトの名無しさん：2007/05/10(木) 00:19:39
とっぷりんくあげ
データベースのコード値ってプログラムではどういうふうに管理してますか？
定数だけを集めるクラスを作ったり、列ごとの列挙型のクラス作ったりするのが普通なのですか？
ご自由に
・直値(マジックナンバー)
・const値
・enum挙
・ステートパターン
選択肢ってこれくらい？
エンティティクラスで const 定義してる。
基本的に、対応するカラムの型にあわせたconstを用意。
ステートパターンが使えるとこでは使うのが自然かな
エンティティでカプセル化でしょうな
>>597 揚げ足とりでスマンけど、直値って言うか？
immediateは即値じゃね？
回答いただきありがとうございます。
エンティティクラスとステートパターンがわからないので出直します。
aaaaa
各DBのテーブル定義などを取得するための共通IFをもったライブラリってありますか？
>>605 例えばgetTableInfo()みたいなものがあって、使用者側はどのベンダー化を意識しなくてもいいってこと？
ある程度意識しないとダメだがな
>>607 ありました
DatabaseMetaDataのgetColumns、getTables
activerecord
hibernate
sql分を解析するライブラリって知ってます？
613 ：
デフォルトの名無しさん：2007/07/23(月) 20:03:22
すみませんが、教えてください。
例えばhibernateで、１対多の関係のあるテーブルをone-to-manyで関連付けた場合、
「１」側のデータを取得した際に「多」側の関連するデータのインスタンスを
すべて作成してしまうんですよね？１万件のデータであっても。
最初の１０件・・のような、ページに分けて表示するようなWEBアプリの場合、
最初の１０件分のインスタンスだけが取得できればいいと思っているのですが
多側のインスタンス数のコントロールとかできるのでしょうか？
もしくは、みなさんこんな場合にはどのようにしているのか教えていただけると嬉しいです。
よろしくお願いします。
>>613 取得することも出来るし、しないこともできる
JPAでもそうだよ
基本はLAZYだろうね
615 ：
デフォルトの名無しさん：2007/07/24(火) 12:49:13
>>614 ありがとう。
> しないこともできる
っていうのはどういう風にやるのでしょうか？出来たら教えて欲しいです。
次の１０件とか、どうやるんだろう？
LAZYにして、必要な分だけloopするとかですか？ん？違うかな。
それと、もう一つ教えてください。
hibernateで、例えばマスターデータの追加ではなく編集の画面で、
入力画面→確認画面→結果画面って流れで、
入力画面から取得した値をhibernateから取り出したエンティティの
プロパティ値に直接書いちゃうと、確認画面を表示するところで、
updateされちゃうじゃないですか。
普通は、このような流れの時には、hibernateから取り出しエンティティの
値をDTOなどにつめ直してセッションとかにぶち込んでおいて、
最後にDTOの値をエンティティに書き戻したりするんでしょうか？
うーん、伝わるかなぁ・・・。
よろしくお願いします。
>>615 標準APIであるJPAの実装では1:nのデフォはLAZY
なにもアクセスしなければ連結先は取得されない
後半の文はおかしくないか？
実装次第だが仮にエンティティにデータを入れたところで勝手にupdateされるか？
WEBアプリなら入力専用にデタッチされたエンティティわたしてもいいし、
入力専用のBeanでわたしてもいい（これが普通）
スタンドアロンアプリなどではトランザクションでコミットしなければそのままだし
コネクションの持ち方と運用次第としか
ループ命令はfor文とwhile文のどちらがいいですか？といってる感じがしてどうもなぁ
617 ：
デフォルトの名無しさん：2007/07/24(火) 14:37:38
>>616 ありがとうございます。
> 標準APIであるJPAの実装では1:nのデフォはLAZY
> なにもアクセスしなければ連結先は取得されない
なにもアクセスしなければ、取得されないのは判るのですが、
ちょっとだけとか、ある範囲（２０件目～３０件目など）だけ取得したいのに、
全件取得されちゃうんじゃないかと・・・？違うんですかね？
> 後半の文はおかしくないか？
すんません。
> 実装次第だが仮にエンティティにデータを入れたところで勝手にupdateされるか？
ええ。例えば先の例（WEB）で、
１．エンティティを取得→入力画面にエンティティの情報含めて表示。ユーザーが入力してOKする。
２．おんなじエンティティを再度取得して、入力データでそのエンティティのプロパティを変更してセッションとかに入れる
→確認画面に編集後のエンティティの情報を表示
３．OKが押されたなら、その編集後のエンティティを取り出して、update
って流れで考えていたのですが、２．の終了段階でflushされて、その時エンティティの状態が変更されているから、
updateしちゃうんですよ。てっきりupdate(entity)メソッドを発行しない限りupdateされないかと思ってたんですけど
・・・って、私が試したのはhibernate2だったんですけど。今は違うのかな？
すみません。
それ、デタッチしないでセッション(=トランザクション)が開いたまま
使ってたんじゃないの？それだと update しなくても、セッションが
終了するときに、自動的に更新されるよ。
セッションって、webじゃなくてhibernateのほうのね。
>>618 ありがとうございます。
そうですね、デタッチしてなかったです。
そもそも、設計自体がよろしくないんですね。きっと。
専用のBeanを使うのがやはり普通なのでしょうかね？
なんとなく、入出力用のBeanを使うと、beanとエンティティとの間でプロパティのコピーを
しなきゃいけなくって、そうするのもわずらわしいと思って、
直接エンティティを操作していたんですけど、←これがわるいんですね。きっと。
勉強になりますた。
どなたか
>>617の前半の部分も解決させていただけると助かります。
よろしくお願いします。教えて君ですみません。
UIはUIで割り切ったほうが良いんじゃないのか？
例だけど、エンティティでは電話番号というデータ1つだけど、
UIでは-区切りの入力欄にするとかあるし・・・
一部分だけの検索がほしいってlimitとか条件で絞るって話のことか?
それならEAGERでいいっしょ
まぁLAZYでもその程度問題ないけど、全件取得して処理するのはおかしい
O/Rマッパというのはキャッシングも利用するからSQLが投げられるとも限らないからね
運用すればわかるがLAZYだから遅くなるとは限らない
>>620 フレームワーク次第じゃない?
ハイフン区切りや複数のコンポーネントの結果が1つのフィールドになるようなら何にも問題ないし
>>619 > ちょっとだけとか、ある範囲（２０件目～３０件目など）だけ取得したいのに、
> 全件取得されちゃうんじゃないかと・・・？違うんですかね？
違うよ。LAZY LOADだとforループとかで21-30件目を
DTOなりにコピーするたびに
SELECT ... FROM ... WHERE ID=?
が発行されるだけ。なので計10回クエリーされるけど全件は取得されない。
SQLの効率をよくしたいなら、
JPQLなりHQLなりで必要な範囲だけ一回で取り出しておいて
コピーすればいい。
なんか、話がOneToManyとManyToOneでずれてる気がする
そもそもは
Maker m = getSingleResult("select m from Maker m");
ってやって
List<Product> products = m.getProducts();
ってやったときにproductsが1万件あったらどうするの？ってことじゃないの？
select m top 30 from Maker
>>625 そんなあほな話じゃないだろ・・・
さすがにそう思いたい
List<Products> products =
em.createQuery("select p from Products p where p.maker = :maker").
setParameter("maker", m).setFirstResult(20).setMaxResults(10).getResultList();
SQL書いたほうが早いな
631 ：
デフォルトの名無しさん：2007/07/27(金) 17:23:31
何千行もあるようなSQL書いて悦に入ってる香具師が
まだこの世には存在しているという事実にナッカリ。
昔の方がSQLの長さに理不尽な制限があったりしたような気がするが
今だってOracleの場合 VARCHAR 4000 Byte の制限やテーブル名、カラム名の長さ制限には泣かされてるがな。
H2はLIKEがCLOBにも使えて感動した覚えがある。
たしかOracleって無理だったよね？
何千行もあるようなSQLを書くような輩が発生する
危険性があるので、O/Rマッパー使いなさいってのは無理がある
何千行もあるようなSQLがORマッピングで解決できると思ってるやつは、ORマッピングの意味を間違えている。
データベースにやらせてた処理をJava側にやらせるためにあるもんじゃない。
長いSQLが必要な処理ってのはある
O/RマッパとSQLは排他ってわけじゃないし
それぞれ利点と不利な点がある
ワイルドカードあるのに実質的に使えないのが癌だな
ついついカラム名を２～３文字にして
エイリアスも極力短めに（ｒｙ
JPAでは
select count(*) from Employee e
は使えないのでつか？
select count(e.id) from Employee e
とかじゃないかな
どうもでつ
select count(e) from Employee e
でもおk
またまたありがとでつ
そちらの方を使うことにしまつ
644 ：
デフォルトの名無しさん：2007/08/07(火) 22:08:14
Java永続化APIの次期バージョン、"JSR 317"として仕様策定プロセスへ
ttp://journal.mycom.co.jp/news/2007/07/23/039/ 既存バージョンからの主な変更点は以下の通り。
・組み込みオブジェクトのコレクションサポート
・組み込みオブジェクトの多段ネストをサポート
・Orderd Listのサポート
・アクセスタイプの組み合わせをサポート
・JPQL(Java Persistence Query Language)の拡張
・Criteriaの導入
・クエリとエンティティマネージャの設定ヒントの標準化
・DDL生成とJava2DBマッピングのための追加メタデータの標準化
・Bean Validation(JSR-303)のサポート
ポイントは
・Orderd Listのサポート
・クエリとエンティティマネージャの設定ヒントの標準化
・Bean Validation(JSR-303)のサポート
あたりかな
気になるのはenumが使いたい場合ってのが結構あることかな
たぶんJPAで一番ほしいのはDBのデフォルト値を有効に出来るような仕様だろうな
開発、運用していて一番これが厳しかったりする
Criteriaの導入が気になる。
Hibernateの仕様をベースにすんのかな？
あれはSQLと違って条件に応じて結合するテーブルを
動的に変化させるような使い方の場合に便利だと思う。
Hibernateではちょっと実装面がアレだったけど、
JPAだと安定しやすい仕様になってくれるんだろう。
Criteriaが必要になるときってそんなにない
というか、ある程度のことをやろうとしようとするとどうせJPQLを組み立てることになって
Criteriaでまかなえないことも多そうだし
LAZYなどの厳密化がほしいかな
デフォだとめちゃくちゃ検索の連鎖する場合が多すぎる
ただ、鯖だとキャッシングしまくるからパフォーマンスの問題はでないんだけど
クライアントからのアクセスがおわっとる
せっかくSwingとの親和性がよくなりそうなのにC/S無視するのはどうかと
社内アプリならわりとC/Sもシェアあるぜ
まだまだ50%は超えているんじゃないかな
>というか、ある程度のことをやろうとしようとするとどうせJPQLを組み立てることになって
>Criteriaでまかなえないことも多そうだし
具体的にはどういうケースですか？
>647の知識はHibernate2で止まってるとみた。
dblってかなりよさげじゃない？
>>649 JPQLってINを上手く扱えるようになったのか・・・
>JPQLってINを上手く扱えるようになったのか・・・
過去のJPQLがINを上手く扱えなかったような記述だな。
過去のJPQLって？ｗ
INで配列使えるの?
653がどうして649への安価なのかが理解できない
JPAもまともに触ってないやつおおすぎ
「JPAも」って言うほど評価・実績のあるものではないんだがな。
JPAも(Hibernateも)まともに触ってないやつおおすぎ
仕事には必要ないでしょ。趣味ならいいけど。
661が仕事で使ってるものは、おれには仕事に必要ない。趣味ならいいけど。
そういう話か？
iBatisを使っています。
updateをするときは1回主キーで検索した結果のビーンを渡すが普通でしょうか？
1つのテーブルを更新する個所が複数あって、その都度、updateのバリエーションが増えてきてしまっています。
私はORMを今回はじめて使うのであまり口を出せないのですが、こういうものなのでしょうか？
>>663 普通のO/Rマッパは変更のあった箇所のみupdateを発行する
薄いラッパほどそのままなので把握がしやすいともいうが、チューニングしていくのは面倒かも
ロストアップデートを防ぐような機能ってないですか？
Hibernate3になって、ストアドプロシージャをサポートしたらしいけど
参考サイトとかないですかね？
カイエンってどうよ？
最近、聞かんな。昔はHibernateと争える勢いだったっけ。
JPAに対応したよ
675 ：
デフォルトの名無しさん：2007/10/06(土) 18:11:51
>>675 JSF+Rowsetならすべてポトペタであつかえるオールインワン環境だぞ
問題はRowsetが主流に慣れそうになくてJSF+JPAになりそうだけど
>675の人気にジェラ
詳しくないけど、676～678 は違うだろ。
>>679 だな。
682 ：
デフォルトの名無しさん：2007/10/07(日) 06:00:35
>675
RIFE
683 ：
デフォルトの名無しさん：2007/10/07(日) 08:50:59
>>676 JRubyインストールしてみる
>>677 Groovyインストールしてみる
>>678 ポトペタって、マウスでぐりぐりやるとあらできあがり？
わからん
>>679 ＞churaの基本構成は､Seasar2.4 + Teeda + KuinaDao + S2Hibernate-JPA + S2Dxo + ツール群という形になります
インストール大変そうだから様子見てみる
>>682 RIFEインストールしてみる（他と比べると、ちょっと情報量が少ない？
Railsの環境設定なんか、Netbeans6のRuby版いれればDBもWebサーバーも苦労ないのにな。
687 ：
デフォルトの名無しさん：2007/10/08(月) 04:28:59
テーブルと1対1なエンティティクラスとマッピングする利点てなによ？
>>685 こんなやつ一生無職のほうが業界のためだ
こんなクズに対してレスしてたのか
一目瞭然だろ
692 ：
デフォルトの名無しさん：2007/10/08(月) 17:40:10
結論
標準になった以上、JPA以外の選択肢はありえない
Cayenneまで対応したことで、ORマッピングフレームワークが全部JPA対応になったから、どれを選んでもJPAには対応している、ってことか？
結論にはならんな。
Db上のフィールドがJavaのメンバ名として使用できない名称のような場合、
どうやってORmappingしているのですか？
>>694 プロパティとDBのフィールド名は一致させる必要はないぞ
>>695-697 POJO内のメンバはDB上はこのフィールド、
のようなことはマッピングファイル？か何かに書いておけば
Dbアクセスの時は意識せずに使える、
ORマッピングのツールはどれもそんなモンなんですか？
逆に、それはできないぞ、というモノもあるのでしょうか。
699 ：
デフォルトの名無しさん：2007/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：2007/10/09(火) 01:21:50
試しにCayenneでやってみますた。
作成されたBeanを見ると、
public static final String フィールド名_PROPERTY = "メンバ名";
という定数があって、これを使うようですね。
外部ファイルかアノテーションでやるのかと思ってましたが、
他のフレームワークでもこんなカンジなんでしょうか。
>>699 なるべく一致させたいのはやまやまですが、
ERを変えられるような立場ではないのです。orz
EJB3.0だとアノテーションで指定するのですね。
参考になります、ありがとうございますた。
JPAはEJB3から独立してSEで使えるから便利だよ
NetBeansだとテーブルから全部自動で作られるし
>>701 NetBeans以外では自動で作ってくれるﾂｰﾙをしらない？
プラグインを用意することなくデフォで使えるってのが大きいだけだろ
707 ：
デフォルトの名無しさん：2007/10/12(金) 22:52:01
結論：DAOでＯＫ マッピングｲﾗﾈ
DAOでOKって、マッピング使っても使わなくてもDAO使うだろ。
DAO内で自分でSQL発行じゃね？
>>710 その場合でも、手動マッピングはするわけだが
わかった！
>>707はマッピングせずに
M a p を そ の ま ま 使 う ん だ よ ！
ものによってはMapそのままでも悪くないと思うけどな
キー値の取得がプロパティの取得につながるし
ただ、HashMapとかそのままつかうのだけは禁止
キー値が存在しない場合Exceptionをかえすような実装ならOK
まーた、Map厨発生か。
が、キー値なしで例外は納得した。
実は Microfost Data Access Objects のことなのかも知れん。
ResultSetだってRowSetだってmapベースだろ
DelphiだってBCBだってスクリプト系だって
こいつは何をいっているんだ？
はじめから道具ありきで、どっかで道に迷っちゃうんだろ
若い奴らは大変なんだよきっと
Map系ってのはMapインターフェースを実装したものではなくて
名前で値を引っ張るものってことだろ。
何もおかしいことはない。
どうしてわざわざオブジェクトに情報を詰めなおすのか
知っているか？
以前、このスレだか過去スレだかに、Map、Mapと騒ぐ奴がいたのな。
その流れを汲んでの話なんだよ。
自分で間違ったことを言っていないつもりなのだろうけど、
このずっと前からのスレの流れ的には空気読めてないんだよ。
しばらくROMってろ。
>>720 JavaがLightWeightじゃないから
>>721 それは知っているが、そんな昔の狂ったやつなんてもう今はいないだろう
Mapのように名前を使ってアクセスする場合何が問題だったのかだけがわかって使っていればおけ
VCLのようにラッパクラスをそのまま入れないこと、存在しないキーに対して
取得しようとしたときに例外を発生させることがきまっていれば問題はない
>>719 おまえの頭がおかしいということはわかった。
"存在しないキーに対して取得しようとしたときに例外を発生させる"
これが必要なのはなんで？
と思ったが、nullが戻ってきたんじゃデータが無いのか項目自体がないのかが判別できないのか
それ以外の理由もある？
そもそもDBにnull入れないほうがよくない？
そうか？
NULLが無いほうが楽ではあるかもな色々と
ただ、Oracleのような、空文字列がNULLであるようなDBMSではNULLを
避けようが無いだろう
NullはDBに必要だろ
(商用で)一番普及してしまっているOracleの仕様にはモニョるものがある罠・・・。
ただnullはアレで便利な面もあるので、ここらは宗教論だろう。
DBにNULLが全くいらないってのが
どんな状況かわからん。
Mapを使う時点で、静的型言語の利点を失っている気がする。
だったら、RoRのActiveRecordのほうがよっぽど使いやすい。
HOGE <> 1 な条件で、HOGE が NULL なレコードが取得できないのが
直感的じゃないと思うので、検索列には NULL は勘弁して欲しいところだ。
>>733 nullがほしいならnullもor条件いれればいいじゃない
直感的ではないというのは同意だが、SQLにとってnullは特別な値だから仕方がないか
検索の際の特別扱いだけでなく、
NULLありのカラムはインデクス張る際にも実装上の制約があったりするし、
単純にホスト言語のデータ型とマッピングする際にもやや面倒が生じるので、
少なくとも意味のあるデフォルト値が考えられるようなエンティティなら、
NULLの代わりにデフォ値突っ込んだほうが楽は楽な気がする。
ま、常にそうできるというわけでもないが。
むしろプログラム言語で3値論理をきれいに扱えないのがおかしい
C#のnullは3値論理だ
Javaなら3値普通に扱えるだろ・・・
C.J.Dateたんは第五正規形まで正規化すればnullなんていらんだろ派だね。
>>733 条件を () で括って最後に is true
Daoは1テーブルごとに1クラス作成して、CRUDのメソッドがあるのが普通なのでしょうか。
1:nのテーブルがあって、一覧を表示する詳細な検索画面などでどうしても結合が必要な場合や条件が複雑になる場合は
その画面専用?のメソッドを作成するものなのでしょうか。
というか、それはORマッパがやるだろ。
テーブル単位でCRUDってのは大概O/Rマッパがやってくれる
連結は製品次第
DBのようにテーブル状に結果が入るほうがいい場合もあるし
そのつど連結先を取ってくるほうがいい場合もあるしなんとも
DAOやORマッパは手段なのに、
目的の方を「どうするのが普通でしょうか？」って
おかしくね？
そういうヤツは、O/Rマッパの仕様に合わせてテーブル設計とかしそうで怖いよな。
COBOLerお得意の横長DBとか。
まあ、漏れは直でSQLゴリゴリ出来る人なので、条件・結合が複雑だったら
SQLを直書きではあるな。
746 ：
デフォルトの名無しさん：2007/10/21(日) 21:12:53
テーブル単位でCRUDするだけがORマッパーの役割と思ってる奴多くね？
少ないと思う
>>539 って結局JSPで、DTOからコード値をgetして、
<% if (sex.equals("1") {%>男 ... (taglibとか)
みたいなのを書くってことでしょうか。
それともDTOにUser#getSexName、getSexCodeを自前で準備するものですか。
これだと自動生成が大変なのですが。。。
前にViewでマッピングしようとするとコネクションが切断？されてるから例外になったり、
マッピングを自動でするような機能がなかったりして断念したことがあるのですが。
>>748 その例外はO/Rマッパ依存の部分でしょ
たとえばJPAのリファレンス実装であるToplinkは参照専用のコネクションを開くので問題ない
それにリソースファイルで扱う場合も多いし、すべてアプリやライブラリなど実装次第としかいえんぞ
750 ：
デフォルトの名無しさん：2007/10/22(月) 16:02:03
そこはentityにisMan()isWomen()を持たせたら？
>>748 定数値と表示名称のマップをアプリケーションスコープに保存して
ELでアクセスしたりとか
DBに持たせてEntityの2次キャッシュにしたりとか
色々方法はあると思う
俺はマップをアプリケーションスコープに入れる派
>DBに持たせてEntityの2次キャッシュにしたりとか
これってどういうことなん？詳しくお願いしたいかもー。
定数マスタとかをDBに持ってる場合
Hibernateなどの2次キャッシュ機能を使えば
アプリレベルでEntityを共有できる
これを通常のEntityと関連付けてLazyロードさせれば
Entityだけで名称表示を行える
まぁでも設定とか色々と面倒かも
O/Rマッパでキャッシングはデフォっしょ
やってないほうが少ないのでは?
おかげでLAZYが便利
ただ、hibernateではセッション明けとかないとダメかもね
キャッシングした場合、定数マスタかなんかが更新されるタイミングっていつになるのでしょうか。
例えば、DB直接いじって定数テーブル？に1行追加して、htmlの画面で<option>がふえてねーじゃん！てことにならない？
そら、なるんだろうなぁ
759 ：
デフォルトの名無しさん：2007/10/23(火) 22:37:32
だめやん
760 ：
デフォルトの名無しさん：2007/10/23(火) 22:43:49
ORマッパー＝はいばね
な件
ORマッパ使おうが使うまいが
キャッシュ対象は読み取り専用のデータだけでしょ
プロパティファイルのDB格納版というか
リソースファイルも変更時には配備しなおしてVM再起動が必要だろ
それと同じこと
>>757 キャッシュ対象データはO/Rマッパーを使って更新する
>>757 だからデフォルトのキャッシュ設定はoff。
キャッシュ側で短めの有効期限を設定したり、
動的な更新を想定しないテーブルのみに使ったりする。
クラスタの場合はDB直接編集でなくとも不整合が起こるので、
分散キャッシュ(OSSだとJBoss TreeCacheが有名)を使う事もある。
>>757 管理者機能でマスタ更新とか作ったりするが、それじゃだめ？
DB直接いじってもボタン押したらキャッシュ読み直しみたいな。
大抵そんな機能を要求されるとマスタに好きなだけ追加削除更新したいって言い出すけどな。
性別なんて男性・女性・不明ぐらいでいいのに全部編集したい！とかいう客は珍しくない。
性別マスタの編集で追加削除ってどんな時代だろう
時代っていうか顧客。
「MTFTS」「MTFTV」「その他」「不明」とかぞろぞろあるんじゃね？
すまんすまん。性別は極端な例だったか。
最近はいろいろと考慮して、男・女の2択はまずやらないわけです。
そういう人からすると”不明”てのはあんまりよろしくないからね。
単純にデフォルトの表示を空白とか"-"にして必須選択にしないってのがうちの会社の流れです。
769 ：
デフォルトの名無しさん：2007/11/08(木) 20:01:01
iBatis をつかってて、Generics関係で質問です。
以下のような ProductDao といったクラスを作り、
Product エンティティをリストで返すメソッドを作りました。
public List<Product> listProduct() throws Exception {
SqlMapClient sqlMap = MyIBatisUtil.getSqlMap();
return sqlMap.queryForList("Product.selectAll");
}
これで -Xlint:unchecked 付きでコンパイルすると、以下の警告が出ます。
警告:[unchecked] 無検査変換です
検出値 : java.util.List
期待値 : java.util.List<jp........Product>
return sqlMap.queryForList("Product.selectAll");
警告 1 個
<Product>はどこにつければいいのでしょうか？
return sqlMap.queryForList<Product>("Product.selectAll");
とやったら「シンボルを見つけられません」とでてしまました。
>>769 原因はsqlMap.queryForListの戻り値が
型指定なしListになってるっぽいところじゃないかな。
キャストしても確か出たと思うので、
メソッド宣言の頭に@SuppressWarning("unchecked")をつけるとか。
1.4までのライブラリはそうなるの多いね
でも、JPAは5.0前提なのにキャストが必要で警告でるってのは納得いかないんだぜ・・・
レスどうもありがとうございます。
なるほど、com.ibatis.sqlmap.client.SqlMapExecutor#queryForList()が
Generics なしでビルドされているから(1.4デモ使えることを前提にしているから)
仕方がないということですね。
今作っているのは、自分の勉強もかねていて Genericsはあまり使ったことがないので、
生産性を度外視して極力 Generics を使っているのですが、
いろんなところでこの警告がでて直そうとすると疲れます。
>>769 で示したのは Dao の Impl クラスなのですが、
Dao のインターフェースクラスでは
public List<Product> listProduct() throws Exception;
というように、Dao を呼ぶ側に対しては Generics 付きで公開したいので、
>>770 のように @SuppressWarnings("unchecked") をつけて黙らせることにしました。
これで -source 1.5 -Xlint:unchecked をつけても、このメソッドでは警告が出ないようになりました。
勉強になりました。どうもありがとうございました。
Genericsは1.4以前のコードとの相性もあるが、リフレクションとも相性が悪いからね。
外部との連携が多いと利点を活かしきれないことも多いとは思う。
JDBC4.0があと2年もすれば普及すると思うけど、
>>769の手間をデータベース開発元がやってくれるから凄く楽になる。
SQLを外だしするってだけでも恩恵はでかいからiBatisは残るだろうけど。
ibatisをspring等と連携しないで使うには、
SqlMapClientをpublic static等で参照できるようにして
#setUserConnectionでjava.sql.Connectionをセット、queryXXXを実行するで問題ないでしょうか。
あと、いまいちSqlMapSessionの存在意義などがわからないのですが・・・
775 ：
デフォルトの名無しさん：2007/11/11(日) 18:18:46
struts+ibatisで開発しています。
DBの接続先をibatisのxmlに記述しているのですが、
参照するDBが複数になってしまった場合どんな感じでやるのがベストだと思いますか？
単純に設定ファイル追加か、追加されたDBのコネクションを取得してセットしてやるが候補なのですが、おかしいかな。
sqlMapClientはDB接続先をひとつしか管理できないよね？
なので設定ファイルを追加して、SqlMapConfig も複数にするしかないような気が。
ibatisのサイトのチュートリアルの7ページを改造してみた。
以前も同じような方式でやったが、ほかにいいアイデアがあればおれも教えてほしい。
public MyAppSqlConfig {
private static final SqlMapClient sqlMap_A ;
private static final SqlMapClient sqlMap_B ;
static {
try {
// A用
String resource = "com/ibatis/example/sqlMap-config_A.xml";
Reader reader = Resources.getResourceAsReader (resource);
sqlMap_A = SqlMapClientBuilder.buildSqlMapClient(reader);
// B用
resource = "com/ibatis/example/sqlMap-config_B.xml";
reader = Resources.getResourceAsReader (resource);
sqlMap_B = SqlMapClientBuilder.buildSqlMapClient(reader);
} catch (Exception e) {
throw new RuntimeException ("Error initializing MyAppSqlConfig class. Cause: " +e);
}
}
public static SqlMapClient getSqlMapInstance_A(){
return sqlMap_A;
}
public static SqlMapClient getSqlMapInstance_B(){
return sqlMap_B;
}
}
>>776 thx。
やっぱそういう感じになるか。
>>774の#setUserConnection？をつかってもできそうな、できなさそうな
778 ：
デフォルトの名無しさん：2007/12/14(金) 00:33:18
HibernateToolsでhbmファイルを自動生成しようとしてるんですが、
関連があるテーブルだと勝手に多重度が設定されますよね。
one-to-manyとか。
あれを自動で設定されたくないんですが、
自動生成時にオプションとかでオフにできないものでしょうかm(_ _)m
DBから関連はずせば?
DBの制約残したままでやりたいのですm(_ _)m
DBの構造コピーして、関連はずしてマッピング作成ってのがてっとりばやそうだな
そうかやっぱり関連外す手しかないか...
ありがとうm(__)m
783 ：
デフォルトの名無しさん：2007/12/25(火) 14:20:30
HibernateのSessionで質問があります。
いま自分がヘルプでアサインされた案件が(Struts+)Spring+Hibernateなのですが、
DAOの作り方が以下のようになっています。
スーパークラス：Org.springframework.orm.hibernate3.support.HibernateDaoSupport
各業務のDAO：HibernateDaoSupportをextendsする。
OracleのXML DB SQL関数を使いたいという理由で、HQLもcriteriaでもなく 生SQL を使っている。
各業務DAOでは、以下のようなコードになっています。
例：
public List getHogeTableEntity() {
～
Session session = super.getSession();
SQLQuery query = (SQLQuery) session.getNamedQuery("....");
ScrollableResults sr = query.scroll();
～
}
質問1.：
このメソッドの中で、sessin.close()が呼ばれていなかったり、ScrollableResults.close()も
呼ばれていないのですが、これはNGですよね？
session には clear() というメソッドもありますが、close()とはどう違うのでしょうか?
質問2.：
上記のケースとは違いますが、似た質問です。
技術評論社のSpring入門なんかの本を見ると、以下のようなコード(例.p274)があります。
public List findPerson() {
return getHibernateTemplate().find("from person");
}
ここでは close() がよばれていませんが
(そもそも org.springframework.orm.hibernate3.HibernateTemplate には close() がない)
これはこれでいいのですよね？
環境によるけど、コネクションを各自にまかせるタイプと、
フレームワークなどがそれらを完全にコントロールしてユーザーは
コネクションを勝手に閉じたりしてはいけないタイプがある。
トランザクションがどの境界でコミットされるかなど、重要なことは多い。
わからないことがあったら普通に素直に聞いたほうがいいよ。
とくにあとからヘルプで入った場合はチーム内での暗黙のルールとかあると思うし。
> 質問1.：
> session には clear() というメソッドもありますが、close()とはどう違うのでしょうか?
Hibernate は取得したオブジェクトを Session にキャッシュしている。
そのキャッシュのクリアが clear() で行える。
ただし、この関数を呼び出してしまうと、Session#save() で永続化しているが、まだDBにコミットして
いないアクションさえもクリアしてしまう。
close() はそのセッションの破棄を意味する。
> 質問2.：
Spring の HibernateTemplate は基本的にすべての作業を HibernateCallback インターフェイス内で
行う。
この HibernateCallback には、Object doInHibernate(Session session) という関数が定義されており、
この関数に渡される Session は Spring が破棄してくれる。
さらに、Spring では HibernateCallback を実装しなくてもある程度は実行できるようにいくつかの簡単な
関数を HibernateTemplate で提供してくれている。
> return getHibernateTemplate().find("from person");
も、そのうちの一つ。これを、HibernateCallback を使用して実装すると以下のような感じになる。
return getHibernateTemplate().execute(new HibernateCallback() {
public Object doInHibernate(Session session) throws HibernateException {
Query query = session.createQuery("from person");
return query.list();
}
});
Spring のソースを追えばすぐに分かると思う。
このように、Hibernate+Spring の組み合わせの場合、基本的には Session#close() などを Spring 側に任せるように
することが出来る。
>>784 も言及しているが、この辺は各プロジェクトでどのような扱いにしているのかで話が変わってくるので、
聞いた方が早い。
ただ、HibernateDaoSupport を継承したとしても、HibernateCallback の中でない限りは Spring が Session を自動的に
閉じたりすることを期待できない気もする。
とはいえ、AOP を使用して閉じるようにしているのかもしれないので断言は出来ない。
だけど、ScrollableResults は自力で閉じないとムリなような気が・・・。
Struts＋Spring＋Hibernateの組み合わせなら、AOPで閉じてるかSession In Viewで閉じてるはず。
てか、俺はそうした。
どこの現場もフレームワークの上にさらにかぶせてる場合も多いからなんとも
オープンソースだけにソースに手が入ってる可能性も高いしね
断言は危険
みなさんレスどうもありがとうございます。
ORMapper は iBatis しか使ったことがなかったので Hibernate は初めてなのですが、とても参考になりました!
>>785 clear() の役割はわかりました。
たしかに Hibernate にはその特徴として 「永続化コンテキスト」というのがあるが、
そのキャッシュを破棄するということですね。
>>786-788 Spring の HibernateTemplate と組み合わせる場合は、Spring のなかで
Session が管理されているので、プログラマは意識しなくてよいというのも理解しました。
自分が理解した仕組み：
>>787 のように Spring AOP を使っていることが前提となるが、
1.context.xml で、transactionManager や、Transaction 管理させるAOPの設定をしておく
2.AOPで、たとえば update* というメソッドを AOP の範囲と設定しておく
3.update*() に処理が移ると、Session が確保される(Commons DBCP などを使っている場合、pool からひとつとってくる)
4.getHibernateTemplate().find() すると、内部で 3. で得たSession に対し DB アクセスが行われる
(ThreadLocal 経由で DAO に Session が渡されるのかな)
5.update*() が終わると、トランザクションが commit され、session も close() される。
Spring のソースをDLして見てみましたが、
>>786 で示していただいたソースは、
HibernateTemplate#find(String, Object[]) と同じものですね。
791 ：
783：2007/12/26(水) 17:43:24
(
>>790 も私です)
こちらの状況ですが、フレームワーク担当に聞いたり、OSSをラップしているローカルフレームワークの
ソースを読んだところ、以下の状況でした。
・トランザクションの管理は、context.xml の AOP で行っている。
・独自に Interceptor や Adviser のようなクラスをつくり、そこで管理はしていない。
・実際には HibernateDaoSupport と業務DAO の間にローカルフレームワークの抽象クラスがあるが、
ここでもトランザクション管理/Session 管理はしていない。
業務DAO が
>>783 になっていることを告げると、フレームワーク担当もどうしたらいいかわからないということで
調べることになりました。
ということで、以下のように考えました。
・ScrollableResults は、Spring をうまく使っていようがいまいが、自分で close() する必要がある
・super.getSession() した場合、AOP の範囲の外を出たときに、session が自動的に close() されるかどうか
調べる必要があり
うーん、サンプル作って実験してみるか・・・
ちなみに AOP は以下のように設定しています。
792 ：
783：2007/12/26(水) 17:50:18
<!-- TransactionManager -->
<bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory"><ref bean="sessionFactory"/></property>
</bean>
<!-- Transaction proxy -->
<bean id="autoTransactionProxy" class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
<property name="beanNames">
<list>
<value>*Service</value>
</list>
</property>
<property name="interceptorNames">
<list>
<value>tsInterceptor</value>
</list>
</property>
</bean>
続く
793 ：
783：2007/12/26(水) 17:50:47
続き
<!-- interceptor -->
<bean id="tsInterceptor"
class="org.springframework.transaction.interceptor.TransactionInterceptor">
<property name="transactionManager"><ref bean="transactionManager"/></property>
<property name="transactionAttributeSource"><ref bean="tsAttribute"/></property>
</bean>
<!-- attribute -->
<bean id="tsAttribute" class="org.springframework.transaction.interceptor.NameMatchTransactionAttributeSource">
<property name="properties">
<props>
<prop key="get*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="insert*">PROPAGATION_REQUIRED</prop>
<prop key="update*">PROPAGATION_REQUIRED</prop>
<prop key="delete*">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>
何度も連投すみません。以上です。
>>783 お前がプロジェクトに対して発言権があるかどうかはわからないが、
おれは出来る限りHibernateDaoSupport を使うときには
HibernateCallback で実装を進めるようにしてもらったほうがいいと思ってるし、
方針が曖昧なようならそう提案してみてはどうだろう？
そうすることによって
・ Session の境界をコントロールしやすくなる。
(HibernateTemplateがネストしたときには下位のセッションが上流に合流する)
・session の close() 忘れが無くなる。
(これはテスト実行時にデッドロック的な挙動を引き起こしたりする)
という利点がある。
OpenSessionInViewパターンは一番シンプルなんだが、
View 層に処理が渡ってから DB にアクセスするしにいったりする挙動が
三層モデル大好きな奴らから理解を得られない場合があるしやめたほうがいい。
複数画面をまたいでオブジェクトを引き回すときには結局Hibernateのセッション切れるんで、
あんまり有利でないことも多いし。
>>790 誤解のないように言っておくが、iBatisでもSpringと組み合わせれば似たようなことができるよ
796 ：
デフォルトの名無しさん：2008/01/16(水) 01:23:47
Hibernateで、主キーはOracleのトリガで生成する場合で聞きたいのですが、
その場合にマッピングファイルに定義するIDジェネレータは SelectGenerator ですよね。
公式のチュートリアルにこんなんあったんですが、
------------
<id name="id" type="long" column="person_id">
<generator class="select">
<param name="key">socialSecurityNumber</param>
</generator>
</id>
※person_idがトリガで払出した代理キーで、socialSecurityNumberが自然キーらしいです
------------
僕が実現したいテーブルに自然キーはないので（ユニークになるカラムもPKだけ）、
以下のようにしたいのですが、keyが必須だとエラーがでました。
------------
<id name="id" type="long" column="person_id">
<generator class="select" />
</id>
------------
自然キーで指定するフィールドもないので、どうやって<id>タグ書けばいいのか分かりません。
どなたか教えてもらえないでしょうかm(_ _)m
797 ：
デフォルトの名無しさん：2008/01/20(日) 09:43:59
Mr. Persisterには関連のマッピング機能は実装済みですか？
798 ：
デフォルトの名無しさん：2008/01/20(日) 13:04:53
ORマッピングはこういう↓抽出も、効率的に出来るのでしょうか？
SELECT
売上実績.*
FROM
売上実績
INNER JOIN 顧客 ON
売上実績.顧客番号 = 顧客.顧客番号
INNER JOIN 商品 ON
売上実績.商品番号 = 商品.商品番号
WHERE
売上実績.年 = 2007 AND
売上実績.月 = 12 AND
顧客.名前 = 'ひろゆき' AND
商品.商品名 = 'うまい棒'
ORマッピングではないけど、独自実装のDAOで、
こういう感じのSQLを1回発行すればいいものを、数万回発行するものがあったので……
いや、どちらかというとこんな感じか……
SELECT
売上実績.*
FROM
売上実績
INNER JOIN 顧客 ON
売上実績.顧客番号 = 顧客.顧客番号
INNER JOIN 会社 ON
顧客.会社番号 = 会社.会社番号
INNER JOIN 商品 ON
売上実績.商品番号 = 商品.顧客番号
WHERE
売上実績.年 = 2007 AND
売上実績.月 = 12 AND
会社.社長 = 'ひろゆき'
商品.商品名 = 'うまい棒'
やべー、
売上実績.商品番号 = 商品.顧客番号 じゃなくて、
売上実績.商品番号 = 商品.商品番号
連投すまん。
>>798 それができないマッパってたぶん存在しないぞ
その独自実装のDAOが1TABLEマッピングしか出来なかったんだろ？
昔、誰かが作ったそんな独自ORマッパーがあって、使えんから
改造した経験がある。公開されてるので、さすがにないだろ。
Seasar2とかのDAOでもそれってできる？
俺もわかっていないのでみなさんに聞きたい(おしえていただきたい)。
以下であってる？
○iBatisの場合、>799 のような SQL を直接書いて、得られた結果セットは <resultMap> タグに書いておいた
売上実績 エンティティにマッピングされる。(これはよくやってる)
Hibernate の場合、売上実績の hbm に、売上実績.顧客番号→顧客.顧客番号 とかの関連 を書いておけばよい。
ただし join フェッチにしないとだめ。
# あ、結果セットは売上実績TBL単体しか見てないので、この場合は joinフェッチとか select フェッチとか関係ないんだっけ?
>>803 S2DaoはSQLファイル書けばできる。
S2JDBCはSQL書かなくてもできる。
JPAサポートしてるツールでJPA使うのが一番らくかもね
Hibernateも今後JPA実装をまずメインにしていくし
っつーか、JPA仕様作ってるのがHibernateだからな。
>>807 仕様策定とプロダクトと一緒にするなよと
809 ：
デフォルトの名無しさん：2008/01/21(月) 23:51:59
>>808 Hibernate陣営が仕様策定に大きく関わっているってことだろ？
810 ：
デフォルトの名無しさん：2008/01/30(水) 23:21:38
hbm2javaで、javaソースコードを
UTF-8で作成したいのですが、どのような設定を行えばよいでしょうか？
>>62で書かれている事象と同じようなことになってしまいます...
java -Dfile.encoding=UTF-8
812 ：
デフォルトの名無しさん：2008/02/08(金) 20:54:05
Springは基本的にコアは 1.1.x で完成していて、
1.2.x 以降は設定ファイルの書式が若干良くなったり
かえって悪くなったりしてるだけじゃなかろうか。
(XML 名前空間は使いにくいから失敗だと思う。
機械が読むには悪くないけど、人間が書くには疲れる。)
spring-ws や spring-webflow みたいなサブプロジェクトが
どれだけ完成度高めていくかと、
新たに面白いサブプロジェクト生まれないかなぁって辺りに関心がある。
コアのバージョンはもうどうでも良いって言うか。
Guice や Sesar2 はハナから問題外じゃね？
デファクト取っちまってるプロダクトがどうしたって強いし。
あとは Rails にだまされてる人達が
どれだけ早く DI の妥当さに気がつくかだけでしょ。
813 ：
デフォルトの名無しさん：2008/02/08(金) 21:53:32
ふと思ったがJAXBとJPAが強力に結びついて
XML->Beans->DBまで一発でリレーション作れたら凄い楽かも。
ついでJAXBの生成したBeanにバインドしたSwingフォームを作ってくれるとなおよし。
>>813 NetBeansはさわったことあるかね?
JPA直はコンポーネントバインディングでできてるからJAXBも問題ないでしょ
でも、JAXB直はあまりないんじゃね？
JAX-WSで使うのが本筋でしょう
これもNetBeansだと全自動で鯖もクライアントも用意できるし
検索取得系の処理用にとiBATISに興味があるのですが、
(1)DTOや検索条件ホルダーにゲッターとセッター必須ですか？
この手のクラスなら単純にpublicフィールドでいいじゃんと
(2)SQLテンプレートを別ファイルにしないオプションはありますか？
別ファイルのSQLのIDの代わりに、
テンプレートの文字列+DTOのClassを引数にできたいしませんか？
ちなみに更新系はアクティブレコード方式のマイナーなの使っています。
DBはマーチン先生の言葉で言うところのアプリケーションデータベースで、
DBA、データ管理者を開発の主要メンバが兼任していて、
処理は大量の項目を持つテーブルのCRUD処理がメインで、
複雑なドメインモデルが必要なロジックはほとんどなく、
保守運用上開発者は当然テーブル構造を熟知していなきゃだめだめ、
な環境だと初めにテーブルありきで名前による自動マッピングで全てを解決する
シンプルなアクティブレコードがいいのかなぁって思ってます。
すでに使ってるフレームワークがあるのならそれを使ったほうがいいんじゃない?
更新系と同一のものを使えばキャッシングとか性能向上されるようになってるはずだよ
818 ：
816：2008/02/10(日) 10:31:26
>>817 実は複雑な検索には、そのActiveRecord方式のフレームワーク使ってないです。
基本的に テーブル（ビュー）--ドメイン
を設定ファイル無しでマッピングするので、もしフレームワーク使うなら、
複雑なJOINの過程の検索条件列を無理矢理最上位のSELECTに書き、
元の1レコードがN件分現れる非常に直感的でないビューを作成しないといけないのです。
そのため今はSQLを引数に、読取り専用汎用ドメインを作成するような
ユーティリティでお茶を濁している感じなのですが、Webのシステムでないとはいえ、
文字列連結でSQL組んでたりであまりよろしくないのです。
両者とも私が関わる前からあり、別に私が選択した方式ではないです。
ActiveRecordで更新系に関してシンプルになるのは割りと気に入っているので、
複雑な検索系だけはiBATISなんかで改善できないかぁと思って色々調べてます。
うーん、その既存のフレームワークが厄介ということか
どのO/Rマッパにしろたいていキャッシングするからそれを無効に設定できるやつを選んでね
そもそもその既存のフレームワークはキャッシングはしてないの？OFFにするとパフォーマンス下がるよね
検索系だけなら複雑なO/Rマッパは使わないでCommons DbUtilsがいいんじゃない？
JDBCのラッパなのでコネクション取得できればそれでいいわけで
昔からあるということは新しいJDKとかつかえないだろうからなおさらかな
820 ：
816：2008/02/10(日) 17:53:20
>>819 以前にソースを見たらスレッド・トランザクション単位で、
主キーをキーにHashTableにドメインのインスタンスを保持していましたが、
常にDBからSELECTし、同じ主キーのインスタンスが既にマップに存在するなら
当該インスタンス上の値を上書きして返すようになっています。
なのでキャッシュしていてもパフォーマンス向上が目的でなく、
同じ主キーのインスタンスは1つということの保証が目的と理解しています。
Commons DbUtilsのソースを落として見てみました。
今現在のやり方はマップリストを返すやつと大体同じです。
iBATISは名前パラメータと動的部分をタグで制御っての気になります。
名前によるバインドはOraclePreparedStatementで直接受けちゃえば
使えそうだけど、それは反則のような気がして・・・。
今となってはiBATISってそんなに便利なものにもみえないけど、
SQLを書きたいのか、隠したいのか、JDK5が使えるのか等
いろいろ前提条件があるからなんとも
iBATISは設定ファイル書いたりするのがたるいよ
今のバージョンはどうなってるかわからないけど
O/RマッパとしてはiBATISとDBUtilisはカプセル化が薄いので習得は容易だと思う
でもこの程度ならその自前のやつとそうそうかわらないかと
JDK5が使えるならJPAとか使うのもいいかも
標準技術だけあって各種ツールサポートが一番充実しているのが強み
822 ：
816：2008/02/11(月) 00:27:15
JDK5は今は使えないです。SQLは隠さない方向で。
求める機能としては名前パラメータのSQL文字列と、
検索条件のマップもしくは検索条件DTOを引数にして結果のマップのリストを取得。
戻りのDTOのClassも引数に追加してDTOの配列で結果を取得。
スカラークエリから各種スカラー値を取得できるショートカットもあれば便利。
バインド後に実際に実行されるSQL文字列のログ出力。
(パラメータの型を無視して''やエスケープなしで単純置換して文字列でも可)
ソートキー列と値の配列から指定キー以降でMAXN件取得なんかもあれば。
なければ自分で作れば済むような機能もありますが・・
今日調べたらSpringJDBCのNamedParameterJdbcTemplateが求めるものに近そうです。
ソース見たら名前パラメタの条件の値がコレクションなら複数の?,?に展開とか賢い。
素のPreparedStatementだとIN句簡単につかえないのに。
ネックは5.0じゃなきゃ駄目なのと、Springのjarに組み込まれてる点か。
SpringJDBCが使いたいのならバージョンさげれば1.4で動くはず
DTOのリストでデータが帰ってくるのでいいのならDBUtilsで十分かと
当たり前だけど、SQLを隠さずにしようと思うと制限は出るよ
足りない機能はそれをラップすればいいだけ
マップやDTOを検索条件にするのはたぶん流行ってないかと
824 ：
816：2008/02/11(月) 10:59:15
一部の機能を放棄すれば1.4でも使用可能なのですね、勘違いしてました。
マップで条件指定って流行ってないんですか。
リストか可変長引数が主流ということでしょうか？
それだとWHERE句で指定する列やサブクエリの数自体が可変で、
かなり動的にテンプレートを組み立てないといけない場合に
?の追加と条件リストへの値の追加との同期が厄介かなと。
名前パラメタとマップで条件指定なら、SQLテンプレートだけを動的に組み立てて、
別途条件MAPには順番気にせず、値が条件指定無しでNULLだろうが全部入れておけば、
内部で実際に名前パラメタで使用して?に置き換わったものだけ、
その順番で条件マップから条件の配列に再構築してくれる。
っていう点で有利だなと思ったのですが。
問題はJPAと一番相性がいいのがEJB3で
続いてSpringJPAサポートなところなんだよね。
Seasar2やHibernateに依存しまくる文章はないものと信じたい。
>>826 SpringJPAサポートって何かメリットあったっけ？
何のありがたみもないJpaTemplateとJpaDaoSupportしか知らないんだが。
Seasar2ってついてるから買わない
ただのJPAの本でよかったんだけどなぁ・・・
hibernate3 + Spring なのですが、
@Entity で bean とテーブルマッピングは一箇所で定義するが、
@NamedQuery は使用せず、SQL は外出しにする良い方法はないでしょうか？
マッピングは annotation を使いたい、しかし SQL は外出しにしたい。
というのが希望です。
Springつかってるならそれでインジェクトすればいいだろう・・・
832 ：
830：2008/03/26(水) 20:45:09
>>830 JPAでやってるならorm.xmlに書けば出来る
Hibernateで複数のテーブルorビューに一つのマッピング定義and一つのEntityって可能なんですか？
836 ：
デフォルトの名無しさん：2008/04/17(木) 23:16:09
HibernateなどのORツールを使う利点ってなんでしょう？
beanに手書きmappingすることで工数削減以外の、
パフォーマンスなどで利点があるのでしょうか？？？
今SQLをゴリゴリ書いてシステム作ってるけど、
テーブル間の関連を書いておくだけで簡単に関連をたどっていけるのはかなりラク
A4何ページにもなるようなSQLなんて見とれんよ
でもHibernate使うのであればそれなりの知識は必要。
迷ってるぐらいならやめとけ
>>836 工数削減できれば十分じゃね?
つまり給料増えるわけだ
実際のところ複雑なSQL発行することももうほとんどないけどね
昔はSQL発行をぎりぎりまでチューニングしないとまともに実用速度が出なかったけどね
へたなSQL書くよりO/Rマッパのほうが効率がいい場合も多いし
>>838 工数削減⇒売り上げ減⇒間接費の負担増⇒給料減
>>838 個人的にはそのとおりなんですが、
要員調達の困難さ（OR技術者が少ない）が障害で、上司が導入を拒んでいるんですよ。
で、他に理由があればいいなと思いまして。
攻め方として、
みんながみんなORまっぱをしってるひつようはないですよ。
SQL技術者なら多いという判断でしょうか？
であればSQLサポートツールとしてiBATISかS2DaoかS2JDBCを導入させてください。
とか。
>>840 道具に流されるのはよくないが、JPAとか標準的なＯ／Ｒマッパは調達は容易だと思うけど
教育のコストも普通は考慮して納期設定するからどの程度の人員かどうかだな、結局は
>>841 S2JDBCはいわば俺俺JPAだから個人的にはオススメしにくい
それくらいならJPA使ったほうがいい
JDBC直でもいいとは思うけど、フレームワークでDBアクセスの方法はある程度絞ったほうがいい
まずはcommonsとかからスタートしてステップアップしていったほうがいいかも
JPAの利点はJavaEEの標準技術なのでサポートするツールがたくさんあるところだな
実装はRIのToplinkかユーザー数の多いHibernateの2択になることがほとんどだと思う
ToplinkはJPA2.0でもRIとなる予定で今後に期待されるとか、TopLink自体はOracleのものだから
glassfishかOracleのAS使う予定があるのならそちらがいい
トランザクション系の処理が中心でリレーションシップがある
複数のテーブルからなる情報を取り扱うシナリオで、次のような条件を含む場合。
更新を前提にするので読み取りにJOINは使えないか使いにくい。
必要に応じてアクセスパスをたどる方法でのデータ取得が望ましい。
楽観的排他。
こういうケースでORMはおすすめ。
逆に問い合わせ中心でJOINや射影が有効。大域処理。
シビアなロック制御が必要な処理といったケースではあまり必要じゃない。
単純に１テーブルを１データオブジェクトにマップするだけが目的だったら正直どうでもいい。
>>842 JPAのまともな実装見たこと無いんだけどいいのあるか？
JPAでというお勧めであればS2JDBCはちょっと弱いけど、純粋に開発効率とメンテナンス製あげようと思ったらS2JDBCはなかなか良いと思う
>>844 TopLink Essentialsでいいんじゃねーの？
吐き出すSQLみてるとLAZYとか一番まともそうだよ
そもそも、今どうやって書いてるんだ？
JPAの範囲で済むならTopLinkでもいいが
SQLや実装固有の機能使うならHibernateの方がいい
SQL使いたかったらDatasourceをインジェクトすればいいだけだと思うんだが
>>839 工数削減が売上減ってどんだけバカな見積もりだしてるのｗ
工数減った分技術料で乗せたらいいんじゃ
>>850-851 なんという殿様商売
こちとら工数×単価でどっちも削られっぱなしなんだぜ？
単に営業がバカなだけだろ、それ
ふつうは開発効率がよくなった結果、残業が減ってハッピーとだろう
期間は今までどおりにしろよ
>>852 オマエが受身すぎなだけだろ。
ﾊﾞｶは甘やかしてもいい事無いぞ
>>852 の気持ちはよくわかるし、ほかの人のレスも正論なのはわかるけど。
この前 NTTデータとNRIの人と話したが、
あいつら、エンドユーザには絶対に単価情報を出さないって言ってた。
「人月ビジネスすると儲からないので、絶対一括」。
そして
>>852 のような下請けが削られる。これ最強。
もっとむかつくのは、うっかりデータの新人が教えてくれたんだが、
うちら下請けには、すぐ工数削るのに、エンドユーザへは一切金額下げてない。
ほんとむかつく。まぁデータやNRIでここを見ている人もいるだろうし、優秀な人もいるけど。
あと、データの公共はほんとクソだな。自分たちは何もできないのに、
役人の顔色伺いながら、こっちの計画書の揚げ足取りしかしない。
法人のほうが、まだまし。
気持ちはわかるが
>>856 > うちら下請けには、すぐ工数削るのに、エンドユーザへは一切金額下げてない。
当たり前だろ。
だって企業名を盾に中間マージンを抜くのが仕事だもの。
みかかデータ。
結構数見てきたけどまともな奴いない。
というかいなくなるな、みかかは・・・
>>856 下請けなんてやるからいけない。
うちは10人ほどしかいない会社だが、元請しかやらないよ。
小さい会社だと数千人月とかの仕事はもらえないからなぁ
>>862 ちょｗ
10億前後ってことかよｗ
そりゃそうだろｗｗ
数千人月の案件は大手SIerが受注すればよろし
だがしかし数百人月の案件は中堅に譲るべし
中規模以下の案件まで大手が受注して下請けに出すから
業界がおかしくなるんじゃ
>>862 小さい会社がそんなの受けてどうすんの?
一人当たりの利益が同じならば大きい仕事でも小さい仕事でもかまわんだろ
マ板でする話をム板でしてるあたりがアレなんだよな
>>867 というか、ひがタンの会社、ITゼネコンじゃないのか？ｗｗｗ
>>868 だから上司にはそういうタイトル名だとはいってないという記述があったはず
>>869 ひがは上司とか、わからない奴をだますことしか考えてないな。
871 ：
デフォルトの名無しさん：2008/05/15(木) 00:00:55
329 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/13(火) 22:04:29
冷ややかな戦争勃発ｗ
ttp://d.hatena.ne.jp/masataka_k/20080513/1210661500#c 342 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 02:05:36
はぶ参入で抗争激化！さぁ、盛り上がってまいりました！
343 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 02:08:47
とりあえず、保存しといた。
http://s04.megalodon.jp/2008-0514-0207-34/d.hatena.ne.jp/masataka_k/20080513/1210661500 347 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 07:16:26
面白くなってきたな。Seasar界隈は人格的にちょっとあれな人が多いのが魅力w
348 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 07:40:37
でも、理事のBlogでやることじゃないよこういうことはメールベースでやるべきだと思う
野次馬的には面白いかもしれないけど企業から見たら不安になって採用を躊躇するところが出てきてもおかしくないからね
352 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 14:02:42
マーケ的にまずいのでseasar3はとりあえず表に出さないでくださいとかいうのはちょっとやばい
353 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 14:04:14
元理事は一旦収束していたのに、なにをしたかったのだろうか。そして日記非公開の理由とは・・・？asipの参戦はありうるのか！？
354 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 14:08:14
うわ、ほんとだ 閉鎖した
355 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 16:31:01
DB関連とか色々勉強させてもらったけど、このしみったれた感覚が所詮デブオタなんだなと思うわ。
872 ：
デフォルトの名無しさん：2008/05/17(土) 10:30:28
ひがです。
Seasar2の後継プロジェクトとしてSlimを申請します。
SlimはかつてはSeasar3(?)と呼ばれていたものです。
詳細は、Seasarカンファレンスで発表します。
# 開設プロジェクトに関する情報
プロジェクト名:Slim
一覧に記載する簡単な説明:
"Less Is More"をコンセプトに持つ、フルスタックフレームワーク。
所属するトップレベルプロジェクト名:Sandbox.java
リーダアカウント名: higa
希望サイトアドレス: slim.sandbox.seasar.org
Maven用groupId: org.seasar.slim
よろしくお願いします。
http://ml.seasar.org/archives/operation/2008-March/003758.html 関係ないだろ。
よそのスレでやれ。
874 ：
デフォルトの名無しさん：2008/06/05(木) 20:23:21
正直、面倒。
S2DaoかSpringJdbcSupportでいいや。
正直、面倒。
JDBC直でいいや。
ユーザープログラマーです。
JavaとRDBのやりとりにに悪戦苦闘しながら１ヶ月やっといろいろなプログラムできてきた。
みんなどうしてこんな面倒なことしてるんだろうとぐぐった。
今ORMを知った。
タバコ吸いながらたそがれた。
そうやって積み重ねていかないと何が便利になったかわからないから正しいと思うぜ
いきなりO/RからはじめるとどういうSQL発行してるとかチェックしなくなってしまう
そもそもJDBCの時点でかなり触りやすくなってるけどね
昔はDBベンダごとにライブラリや命令がばらばらだったんだから・・・
880 ：
デフォルトの名無しさん：2008/06/26(木) 10:48:44
>>877 [Javaデータアクセス実践講座] この本結構いいと思うけど どうよ
＃まだ ちら見だけどｗ
どうもこうも…
882 ：
877：2008/06/27(金) 18:45:01
>>879 >そもそもJDBCの時点でかなり触りやすくなってるけどね
ですね、だからこそ勉強する気になりました。
>>877 とりあえずJPAのドキュメントとか見たらやろうとしている事は簡単に
できそうだからそっから始めてます。
作るのめちゃくちゃ楽ですわ。
883 ：
デフォルトの名無しさん：2008/07/03(木) 06:34:34
誘導されて来ました。
もし知ってる人がいたら教えてください
ActiveObjectsっていうORマッパなんですが
複合主キー使えるんでしょうか？
JPAでOneToManyのMany側を絞り込み検索した状態で
One側を得るようなJPQLはどのように書けばよいのでしょうか。
例えば従業員の作業日誌の直近5日分を
全ての従業員分取得するといったケースです。
>>884 実際にやってみてダメだったJPQLここにさらしてみ
しょうもないところでつまってるだけだから
886 ：
884：2008/07/06(日) 19:02:31
実はPersistenceUnitLoadingExceptionってのが出て
まだ接続すらできてなかったりします。すみません。
DerbyやH2とDBを切り替えても動かないです。。。
888 ：
884：2008/07/06(日) 21:35:25
接続がうまくいかないのはマッピングに失敗してるからのようです。
DialyエンティティがEMPLOYEE_IDとWROTE_DATEの複合キーを
使用しているのですが、どこを直せばよいのでしょうか。
@Entitiy @Table(name="EMPLOYEE")
public class Employee implements Serializable
@OneToMany(targetEntity=Diary.class, mappedBy="employeeId")
public List<Diary> getDiaries() {
@Entitiy @Table(name="DIALY")
public class Dialy implements Serializable
@EmbeddedId
public DiaryPK getPK() {
@ManyToOne(targetEntity = Employee.class)
@JoinColumn(name = "EMPLOYEE_ID",
referencedColumnName = "EMPLOYEE_ID")
public Employee getEmployee() {
@Embeddable
public class DialyPK implements Serializable
@Column(name = "EMPLOYEE_ID", nullable = false)
public int getEmployeeId() {
@Column(name = "WROTE_DATE", nullable = false)
@Temporal(TemporalType.DATE)
public Calendar getWroteDate() {
DialyじゃなくてDiaryだろjk
>>888 Employeeに定義しているdiariesの@OneToManyアノテーションのmappedByが間違っている
mappedByに書くのはカラム名ではなく相手側@ManyToOneのプロパティ名になるので
employeeとなるのが正しい
マッピングがよくわからないなら、DDLに外部キー制約を付けてテーブルを作成してから
EclipseのEntity自動作成機能を使った方が早い
あとはやはりJPAだとキーは１つにしたほうがいいな
892 ：
884：2008/07/07(月) 21:20:55
>>889 実はホントのソースコード上では全部Diaryだったんだけど、
手打ちで書いたらボロボロでした。英語力って大切ですね。
>>890 mappedByを修正して、Diary.employeeをread onlyにしたらうまくいきました。
どうもありがとうございます。
>>891 弄ってみた感触だとJPQLと@EmbeddableなPKは相性が思いみたいですね。
代理キーに切り替えて、PKだったものはUniqueにしました。
で、やっとこさ本題です。以下のようにすれば目的の結果を得ることができるのですが、
JPQL一発でList<Employee>内のgetterとしてのdiariesに、絞り込み結果を詰めることはできますか。
List<Employee> list = em.createQuery(
"SELECT e FROM Employee e ORDER BY e.id").getResultList();
Query query = em.createQuery(
"SELECT d FROM Diary AS d "
+ "WHERE d.employeeId = :empId AND d.wroteDate BETWEEN :start AND :end "
+ "ORDER BY d.employeeId, d.wroteDate");
for (Employee e : list) {
query.setParameter("empId", e.getId());
query.setParameter("start", start, TemporalType.DATE);
query.setParameter("end", end, TemporalType.DATE);
List<Diary> diaries = query.getResultList();
}
＞query.setParameter("empId", e.getId());
なんでわざわざidとりだしてるんだ？
Entityのコードさらしてみ
894 ：
884：2008/07/07(月) 22:59:33
>>893 > なんでわざわざidとりだしてるんだ？
SQL的に速くてもリストの詰め直しは避けたかったためです。
以下はEmployeeとDiaryのコードです。
@Entity
@Table(name = "DIARY", uniqueConstraints =
@UniqueConstraint(columnNames = {"EMPLOYEE_ID", "WROTE_DATE"}))
public class Diary implements Serializable {
private static final long serialVersionUID = 1L;
@GeneratedValue(strategy = GenerationType.TABLE, generator = "DIARY_SEQ")
@Id
@Column(name = "DIARY_ID", nullable = false)
private Long id;
@Column(name = "EMPLOYEE_ID", nullable = false)
private Integer employeeId;
@Column(name = "WROTE_DATE", nullable = false)
@Temporal(TemporalType.DATE)
private Date wroteDate;
@Column(name = "CONTENT")
@Lob
private String content;
@ManyToOne(targetEntity = Employee.class)
@JoinColumn(name = "EMPLOYEE_ID", referencedColumnName = "EMPLOYEE_ID",
insertable = false, updatable = false, nullable = false)
private Employee employee;
895 ：
884：2008/07/07(月) 23:01:04
@Entity
@Table(name = "EMPLOYEE")
public class Employee implements Serializable {
private static final long serialVersionUID = 1L;
@Id
//@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name = "EMPLOYEE_ID", nullable = false)
private Integer id;
@Column(name = "NAME", nullable = false)
private String name;
@OneToMany(targetEntity = Diary.class, mappedBy = "employee")
private List<Diary> diaries;
前はgetterにアノテーションを書いてましたが、フィールド注釈に変えています。
>> なんでわざわざidとりだしてるんだ？
>SQL的に速くてもリストの詰め直しは避けたかったためです。
？
>? ? @Column(name = "EMPLOYEE_ID", nullable = false)
>? ? private Integer employeeId;
?> ? @ManyToOne(targetEntity = Employee.class)
?> ? @JoinColumn(name = "EMPLOYEE_ID", referencedColumnName = "EMPLOYEE_ID",
?> ? insertable = false, updatable = false, nullable = false)
?> ? private Employee employee;
なにこれ？
897 ：
884：2008/07/07(月) 23:16:48
？ばかり書かれても何がなんだか。
894をコピペしたら文字化けしてるだけだな
空白になにをいれたのだ？
なにこれというのは2つの箇所のことだよ
なんで2つあるの?
899 ：
884：2008/07/07(月) 23:25:30
ああ、d.employee = :emp としろということですね。
ORMに慣れてないので主キーとエンティティが
等価に見えずにそう書いていました。
まずそれをやめればよい
select e, d
from Employee e inner join e.diaries d
where d.wroteDate between :start and :end
order by e, d.wroteDate
getResultListがList<Object[]>になるけどこんなんで取れるんじゃね？
DiaryはEmployeeの関連持ってるんだからemployeeIdはいらないな。
>>901 ２つのエンティティをかえすならせめてnewキーワードつかったほうがいいし
なぜ2つ返す必要があるのかわからない
@ManyToOneしてるんでしょ？
903 ：
884：2008/07/08(火) 00:53:13
最初からDiaryのみを検索して、Map<Employee,List<Diary>>に
詰め直す場合と比べたら、もっさりしちゃいますね。
結果セットがどのような状態かを考えれば仕方ありません。
まぁORM自体はなかなか便利なので、今後も使いたいと思います。
ながながとおつきあいいただきありがとでした。
>>902 この程度で一々クラス作ってまでnewするか？いやしない。
fetch joinだと全部持ってこられてしまって直近だけ取れないから
EmployeeとDiary並べた。課題(>884)を素直に解くとこうなるだろ。
文句あるならお前の解を示せよ。
>>898 外部キーを関連Entityとは別に定義するやり方は特に珍しくは無い
フィールドアクセス時にLAZYロードが走るようなJPA実装の場合便利だし
>>902 DiaryをルートとしてEmployeeをFETCH JOINするのと結局は同じになるからね
Employeeを軸にページングしたいときは、
>>892のようにMany側は個別に取る必要があるけど
>>905 複数のプロパティを単一のカラムにマッピングすると動作は実装依存にならないかい？
909 ：
デフォルトの名無しさん：2008/07/11(金) 17:46:05
Hibernate 3.xのオススメな参考書ってある？
入門については何とかなりそうなので、ある程度リファレンスな内容が載っている物を希望。
「HIBERNATE イン アクション」か「Hibernate (開発者ノートシリーズ) 」にしようと思ったんだけど、両方とも2.xなんだよね。
Java Persistence With Hibernate
911 ：
909：2008/07/12(土) 12:40:48
>>910 ・・・わ、和書で・・・ない・・・かな？
すまん。アホウな漏れに、HibernateのMany-to-Many関係のメリットを教えてくれ。
何で、Many-to-One×３（データを持ってるテーブルの他に「関係」テーブルの定義も書く）ぢゃダメなんだ？
inverse指定とか出来るから？
913 ：
912：2008/07/29(火) 18:43:58
っと、保守込みということで一応age
JPQLはやってるけどMany-to-Manyはつかわん
必要な場面ってのが想像できない
この時代、英語でマニュアルやブログが読めん開発者はヤバいんじゃないの。
少なくともオープンソース系では英語が読めないと先進的なことできないでしょ。
Seaserみたいのはごく一部だし
だから
>>911は英語を死ぬ気で読むべき
O/Rマッパごとき特に先進もクソもないと思うが
別にO/Rマッパが先進的とは一言も書いてないし…
# しかしhibernate3やJPA周辺はそれなりに先進的だと信じてるぞ
何にせよ和書が出るまで待ってちゃ完全に出遅れ組なのは間違いないでしょ
和書書けばもうかるから著者はそれでいいんだろうけど
多くの人は6年間も英語やってたんだしさ リーディングくらいさくっとやりなよ 英語で情報発信しろとは言わないから。
少なくとも標準APIであるJPAは日本語情報普通にあるでしょ
そこまでして日本語にこだわる意味がわからん…誤訳も多かろうに
圧倒的に読みやすいからだろ。誤訳も、ネイティブ言語の優位性を覆すほどひどいものはないし。
英語は何年やっても何故か生理的に苦手
でも、酷い日本語の原文を想像して意味を拾うはめになったり
（やばいと気がつくからこれはましだが）、
勝手に脳内補完されたり、真逆の訳を付けられたり
こんな俺でも原文を読むようになりました
日本語にこだわってる子はまだいいけど、日本語しか読めないのはどうかという話だったような。そもそもスレ違いか。
エンティティにアノテーションをつけるのは間違ってる気がしてきた。
フィールドやアクセッサにそんなもん付けたら、もうPOJOじゃねーよみたいな。
POJOを継承してそっちに@Entity付ける仕様の方がいいんじゃないかな。
JPAはどうせエディタで補完しながら使うんだし。
継承必須な時点でそれもどうかと
Entityはビジネスロジック書く場所ではないから今の状態が一番バランスは取れていると思う
DTOはインターフェースだけでは定義できないしね（各種イベント等の処理が必要になる場合もある）
むしろDIコンテナやそれに依存したフレームワークでやっちまったといえるのが
アノテーションを使わないで自動バインディングして不具合出すようなやつ
自動バインディングしないようにアノテーションつけるって・・・本末転倒すぐる
そんなPOJOにこだわって何か意味あるの？
無駄なロジックいたる所に増やしたくないだろ
ロジックじゃなくアノテーションの話じゃねーの？
>>926 アノテーション関係ないし。
むしろ、継承して一クラス増やしちゃってるみたいだし。
>>928 いやいやいや、アノテーション付けたらPOJOじゃないってのが発端だろ。>923嫁。
>925も>923宛じゃねーの？>924にはPOJOなんて出てこないんだから。
930 ：
928：2008/08/03(日) 04:14:03
>>929 う～ん、よくわからんな。
アノテーションにしろPOJOにしろ、無駄なロジックとは関係ない話だと思うが。
>>930 だーかーらー、アノテーション付けたらPOJOじゃないって話が
なんで無駄なロジックの話になってんだよｗわけわかんねーぞおい。
932 ：
928：2008/08/03(日) 05:52:01
それは926につっこむところだろ。
つーかさ、使う側なんだから自分にあったの探せよ。で終わりでしょ。
作る側なら
>>923みたいな狂った考えでてこないし。
>>924みたいにEntityObjectへの自動バインディングをパッケージ以外で設定するとか・・・
設計が糞かコンテナ理解低すぎる。
>>933 >>924の後半はO/Rマッパの話ではなくて
某国産DIコンテナのフレームワーク周りの不具合のことな
cayenneって流行ってないですか？
あんまり日本語の資料見かけないんだけど。
HibernateかTopLinkという選択肢をおしのけてまで使うメリットはあまりない気がする。
xmlファイルが全くいらないフレームワークってない？
S2JDBC
>>938 s2jdbc.diconはXMLファイルな件
そこにこだわる必要も感じられないけどね。
「*全く*いらない」というのが与件。
「必要も感じられない」とかいって無視したらそれはバグだ。
そか。
困ったクライアントにあたっちゃったね。
Mr.Persisterだろ、ｊｋ
xmlファイルなんて自動生成だからあんまり気にしないけどね
ActiveObjects最高ですお。まだ、0.8だけどな。
ActiveObjectsって本家にも情報があんまり載ってないからなあ。
ddlutilsみてみぃ。いいぜぃ
ちょっと調べて見たけど、ActiveObjectsって、
インターフェースだけ書けばいいみたいだな。
結構楽かも。
そうか？ ジェネリクスがある今は、インターフェースも書かなくていけるだろ。
インターフェースなしだと・・・？
ジェネリクスとなんの関係もない話っぽいが。
プロパティチェンジサポート全自動でやってくれるやつがいいなぁ。
JPAはそこだけ不満だから。
インターフェースクラスだけ書けばいいということは、
DI コンテナみたいに実行時に Proxy クラスを自動生成して、
そいつが DB アクセスしてくれるってことかな。
>>955 そうみたい。
middlegenみたいのが使えればもっと楽なんだけどなー。
>>952-954 ジェネリクスが無い時代はDaoをそれぞれ作る必要があった。
それを軽減するための苦肉の策として、インタフェースを書けば
実行時に実装が生成される、というものが無理矢理作り出された。
ジェネリクスが出てからは、そんな無駄なことはしなくていいということ。
出た当初はもう、Daoは一個でいけるんじゃないかという流れも
あったが、そうではないことが世間的に分かってきた。
ジェネリクスの親Daoが一個あって継承だな。
ジェネリクスといいうのがどうも我々の世界モノとは異なるようだ。
君の語るジェネリクスの例というか近いWebサイトなどがあったら紹介して欲しい。
List<String>のように使うジェネリクスとは違う話をしてるんだよね？
960 ：
デフォルトの名無しさん：2008/08/20(水) 10:36:53
961 ：
デフォルトの名無しさん：2008/08/20(水) 10:38:01
単純なCRUDだけならこれでもいいけど、実際はそうもいかないでしょ。
ORM使ってるときのDAOは飾りみたいなものでしょ。
>>960 その類。結果的にORMは結構それ系になってると思ったが違うのか？
>>961 そりゃそうだ。インタフェースだけ書くやつも単純なCRUDだけだろ。
別SQLファイルとか人の実装が必要なのは、もう実装そのものだし、
そもそもインターフェース「だけ」じゃないしな。
>963
そうか。勘違いかもしれん。
っつか、おまえは全部ObjectかMap厨かｗ
ORMでそもそも、それぞれインターフェースが必要だった理由の
1つに戻り値の型安全確保があったからと思ったが。
そうじゃなきゃRubyのActiveRecordみたいなのでいいしな。
JPAでもS2JDBCでもジェネリクスのおかげで便利に使えるように
なった。俺的にORMにジェネリクス抜きはもうめんどくさい。
ああ、ここまで読んでわかった
S2JDBCのS2AbstractServiceをありがたがるやつか
いや、あれだけ批判されていたS2AbstractServiceがまさかいまごろ話題に出るとは誰もおもわんて
別に何か出たのかなと思ったまでだ
>>952がActiveObjectsのインターフェースというのを激しく勘違いして
自分の妄想いっぱいの持論を展開してるところか。
そして再び過疎
970 ：
デフォルトの名無しさん：2008/08/25(月) 12:00:22
初歩的な質問で申し訳ないのですが・・・
Hibernateのコンフィグファイル等をすべて実行可能なjarファイルにまとめて
実行しましたとことろ、org.hibernate.MappingNotFoundException例外が発生してしまいます。
jarファイルの中にはいちおう必要なファイルはあるようなのですが。
当方、Java開発は統合環境（Eclipse）オンリーでやっていていて、jarファイルも、
Eclipseがすいすい出力してくれたのですが。
971 ：
970：2008/08/25(月) 13:05:19
あれあれあれ。
よく考えたらcfg.xmlは読み込んでいるのに、cfg.xmlで指定された
マッピングファイルが読めないとかいっていいるのか・・・
すいません。自分で全部試してる時間がないので結論だけ教えて下さい。
どのフレームワークが一番いいですか？
JDBC
976 ：
デフォルトの名無しさん：2008/08/31(日) 02:43:39
Zachman Framework
SQLiteを使ってデータベースデスクトップアプリケーションを作ってるんだけど、
データベースファイルの生成から面倒見てくれるフレームワーク無いかな？
今はiBATISでXML組み立てて作ってるけど、
ResourceBundleからCREATE TABLE生成とかしてるから
関連性がうまく保てないんだよな。
普通のO/Rマッパはクラスからテーブル作成するか、
テーブルからクラスを作るか
しかしないんじゃないかな
もちろん関連はすべてやってくれる
iBATISはDBよりなんでたぶん面倒なんだろうなぁというのはわかるが
JPAの実装ならクラスから自動的にテーブル作るだろ
iBATISの話だろ？
iBATISの代わりを探してるんではないの？
＞普通のO/Rマッパはクラスからテーブル作成するか、
これに該当してるから特に何も新しい情報は出ていない。
iBATISでも他のでもいいかな
DBをSQLiteでやってることもあって、
軽い感じのがよくてiBATISをファーストチョイスにしたんだ。
JPAってSE1.5で使える？
JPAはJavaEE5
つまりSEも5.0が対象
もちろん上位互換のSE6でも問題は無い
うちの新しい案件、JPAで考えてたけど、iBatisでDAOろうと思ってる。
Java専属の技術者が会社にひとりだけだと、外様お断りなフレームワークは選択できない。
iBatisという有効な代替手段があるのもまたJavaのいいところだけど。
JPA実装も検討してみるわ
Hibernateはちょっと強力すぎる気がするからOpenJPAがいいかな。
色々とありがとう。
>>986 JPA汎用にしとけ。
依存コードは出来るだけ書かないこと、依存コードを明記しておくことでいいと思う。
>>985 JPAはiBatisと比べて利点は開発効率がいいことと、開発環境が整備されていること。
また、実装を切り替えることも出来る。
ただ、ちょっとレイヤーが違うから、SQLがりがり書きたい人ばかりならiBatisのほうがいいと思う。
DAOでラップしてO/Rマッパすらある程度隠すのもありかと。
昔、ベトナムの会社の人がiBatisをバリバリ使っててちょっとおどろいた
iBatisはSQLを外出ししてガリガリ書こうぜって代物と考えると、
JPAやJDBC直書きと比べて学習対効果のバランスがいいしね。
>>987 汎用ってのは、適当な実装から
JPAの部分、javax.persistenceのクラスだけ抜き出して使うって意味？
当人じゃないがそういう意味じゃねーかな。
JPAで実装依存ってそこそこ程度の案件だと、
悲観ロックを使う時くらいしかお目にかからない。
>>991 Criteriaは使わないの？
あれが無いと任意検索条件のQueryを発行するのが面倒なんだけど
いろんなマッパが出てはいるけど、
みんな実際そんなに使ってないのか？
複雑なリレーションを持つテーブルを扱う案件なら、
依存ばりばりのSQLを直書きしたくなるからJPAはいらんなぁ。