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

Java⇔RDBのMapping-F ..

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

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

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

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

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

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

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

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

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

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

よろしくお願いします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

さすがにそう思いたい

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

651:デフォルトの名無しさん
07/08/14 09:57:59
>>650
まちがえ、ddlutils

652:デフォルトの名無しさん
07/08/15 14:40:24
>>649
激しく同意

653:デフォルトの名無しさん
07/08/17 01:57:00
>>649
JPQLってINを上手く扱えるようになったのか・・・

654:デフォルトの名無しさん
07/08/17 05:22:41
>JPQLってINを上手く扱えるようになったのか・・・
過去のJPQLがINを上手く扱えなかったような記述だな。
過去のJPQLって？ｗ

655:デフォルトの名無しさん
07/08/17 21:32:58
INで配列使えるの?

656:デフォルトの名無しさん
07/08/17 22:12:54
653がどうして649への安価なのかが理解できない

657:デフォルトの名無しさん
07/08/18 00:34:59
>>656
禿げしく同意
全くもって理解不能

658:デフォルトの名無しさん
07/08/18 00:52:11
JPAもまともに触ってないやつおおすぎ

659:デフォルトの名無しさん
07/08/18 01:40:33
「JPAも」って言うほど評価・実績のあるものではないんだがな。

660:デフォルトの名無しさん
07/08/18 03:23:45
JPAも(Hibernateも)まともに触ってないやつおおすぎ

661:デフォルトの名無しさん
07/08/18 13:25:34
仕事には必要ないでしょ。趣味ならいいけど。

662:デフォルトの名無しさん
07/08/19 12:25:58
661が仕事で使ってるものは、おれには仕事に必要ない。趣味ならいいけど。
そういう話か？

663:デフォルトの名無しさん
07/08/19 14:56:37
iBatisを使っています。
updateをするときは1回主キーで検索した結果のビーンを渡すが普通でしょうか？
1つのテーブルを更新する個所が複数あって、その都度、updateのバリエーションが増えてきてしまっています。
私はORMを今回はじめて使うのであまり口を出せないのですが、こういうものなのでしょうか？

664:デフォルトの名無しさん
07/08/19 15:54:47
>>662
そういう話ｗ

665:デフォルトの名無しさん
07/08/19 19:04:38
>>663
普通のO/Rマッパは変更のあった箇所のみupdateを発行する
薄いラッパほどそのままなので把握がしやすいともいうが、チューニングしていくのは面倒かも

666:デフォルトの名無しさん
07/09/01 15:45:34
ロストアップデートを防ぐような機能ってないですか？

667:デフォルトの名無しさん
07/09/25 22:32:58
Hibernate3になって、ストアドプロシージャをサポートしたらしいけど
参考サイトとかないですかね？

668:デフォルトの名無しさん
07/09/26 00:44:57
>>667
URLﾘﾝｸ(www.hibernate.org)

669:デフォルトの名無しさん
07/09/26 00:48:43
>>668
英語読めない

670:デフォルトの名無しさん
07/09/26 01:39:42
>>669
URLﾘﾝｸ(www.nova.ne.jp)

671:デフォルトの名無しさん
07/09/26 01:45:43
>>669
それは、読んでないだけ。

672:デフォルトの名無しさん
07/09/27 00:48:19
カイエンってどうよ？

673:デフォルトの名無しさん
07/09/28 00:59:53
最近、聞かんな。昔はHibernateと争える勢いだったっけ。

674:デフォルトの名無しさん
07/09/28 07:00:36
JPAに対応したよ

675:デフォルトの名無しさん
07/10/06 18:11:51
最近Ruby on Railsをすこしやってたんだけど、Railsに相当するものって
Javaで言うとどんなのがあります？

やりたいのは、Railsでやってた、↓をJavaでもやりたい。
Four Days on Rails 4日で作るToDoリスト
URLﾘﾝｸ(rails.to)

676:デフォルトの名無しさん
07/10/06 19:05:18
>>675
JRuby on Rails

677:デフォルトの名無しさん
07/10/07 00:30:39
>>675
厳密にはJavaじゃないけど、Grailsとか
URLﾘﾝｸ(grails.codehaus.org)

678:デフォルトの名無しさん
07/10/07 00:48:54
>>675
JSF+Rowsetならすべてポトペタであつかえるオールインワン環境だぞ

問題はRowsetが主流に慣れそうになくてJSF+JPAになりそうだけど

679:デフォルトの名無しさん
07/10/07 01:43:18
>>675
Chura

680:デフォルトの名無しさん
07/10/07 02:05:28
>675の人気にジェラ

681:デフォルトの名無しさん
07/10/07 02:32:45
詳しくないけど、676～678 は違うだろ。>>679 だな。

682:デフォルトの名無しさん
07/10/07 06:00:35
>675
RIFE

683:デフォルトの名無しさん
07/10/07 08:50:59
>>676
JRubyインストールしてみる

>>677
Groovyインストールしてみる

>>678
ポトペタって、マウスでぐりぐりやるとあらできあがり？
わからん

>>679
＞churaの基本構成は､Seasar2.4 + Teeda + KuinaDao + S2Hibernate-JPA + S2Dxo + ツール群という形になります
インストール大変そうだから様子見てみる

>>682
RIFEインストールしてみる（他と比べると、ちょっと情報量が少ない？

684:デフォルトの名無しさん
07/10/07 11:52:24
>>683
churaのインストールはこれだけだよ。
URLﾘﾝｸ(s2container.seasar.org)

俺も最初は面倒くさそうだと思ったんだけど、eclipseプラグイン入れれば揃うみたい。

685:デフォルトの名無しさん
07/10/07 23:49:40
なんというヘタレ…
URLﾘﾝｸ(d.hatena.ne.jp)

686:デフォルトの名無しさん
07/10/08 03:45:53
Railsの環境設定なんか、Netbeans6のRuby版いれればDBもWebサーバーも苦労ないのにな。

687:デフォルトの名無しさん
07/10/08 04:28:59
テーブルと1対1なエンティティクラスとマッピングする利点てなによ？

688:デフォルトの名無しさん
07/10/08 08:46:40
>>685
こんなやつ一生無職のほうが業界のためだ

689:デフォルトの名無しさん
07/10/08 11:59:00
こんなクズに対してレスしてたのか

690:デフォルトの名無しさん
07/10/08 14:31:25
>>685って>>675？

691:デフォルトの名無しさん
07/10/08 14:56:55
一目瞭然だろ

692:デフォルトの名無しさん
07/10/08 17:40:10
結論
　標準になった以上、JPA以外の選択肢はありえない

693:デフォルトの名無しさん
07/10/08 19:32:17
Cayenneまで対応したことで、ORマッピングフレームワークが全部JPA対応になったから、どれを選んでもJPAには対応している、ってことか？
結論にはならんな。

694:デフォルトの名無しさん
07/10/08 20:35:11
Db上のフィールドがJavaのメンバ名として使用できない名称のような場合、
どうやってORmappingしているのですか？

695:デフォルトの名無しさん
07/10/08 20:41:11
>>694
完全に一致させる必要ないだろ

696:デフォルトの名無しさん
07/10/08 20:48:05
>>694
好きな名前つければいいと思うよ。

697:デフォルトの名無しさん
07/10/08 20:48:34
>>694
プロパティとDBのフィールド名は一致させる必要はないぞ

698:デフォルトの名無しさん
07/10/08 21:35:58
>>695-697
POJO内のメンバはDB上はこのフィールド、
のようなことはマッピングファイル？か何かに書いておけば
Dbアクセスの時は意識せずに使える、
ORマッピングのツールはどれもそんなモンなんですか？

逆に、それはできないぞ、というモノもあるのでしょうか。

699:デフォルトの名無しさん
07/10/09 01:09:02
>>698
EJB3.0だとこんな感じになるはず。

# ただ、なるべく一致させておいた方が不幸なことが起きないかも・・・

@Entity(name="ITEM")
public class Item implements Serializable{
private int id = 0;

@Id
@GeneratedValue(strategy=GenerationType.AUTO)
@Column(name="RENBAN",nullable=false)
public int getId(){ return id;}

public void setId(int id){ this.id=id;}

private String title = null;

@Column(name="SHOSEKI_MEI",nullable=false)
public String getTitle(){ return title;}

public void setTitle(String title){ this.title=title;}

700:694
07/10/09 01:21:50
試しにCayenneでやってみますた。
作成されたBeanを見ると、
public static final String フィールド名_PROPERTY = "メンバ名";
という定数があって、これを使うようですね。
外部ファイルかアノテーションでやるのかと思ってましたが、
他のフレームワークでもこんなカンジなんでしょうか。

>>699
なるべく一致させたいのはやまやまですが、
ERを変えられるような立場ではないのです。orz

EJB3.0だとアノテーションで指定するのですね。
参考になります、ありがとうございますた。

701:デフォルトの名無しさん
07/10/09 13:04:01
JPAはEJB3から独立してSEで使えるから便利だよ
NetBeansだとテーブルから全部自動で作られるし

702:デフォルトの名無しさん
07/10/09 20:24:11
>>701
NetBeans以外では自動で作ってくれるﾂｰﾙをしらない？

703:デフォルトの名無しさん
07/10/09 21:34:41
プラグインを用意することなくデフォで使えるってのが大きいだけだろ

704:デフォルトの名無しさん
07/10/10 01:27:45
>>702
知ってる

705:デフォルトの名無しさん
07/10/10 01:31:27
>>701
きしだﾀｿ乙

706:デフォルトの名無しさん
07/10/12 06:45:53
>>702
WTP2.0

707:デフォルトの名無しさん
07/10/12 22:52:01
結論：DAOでＯＫ　マッピングｲﾗﾈ

708:デフォルトの名無しさん
07/10/12 23:05:37
DAOでOKって、マッピング使っても使わなくてもDAO使うだろ。

709:デフォルトの名無しさん
07/10/13 03:12:15
>>707
ありえないほどバカだな

710:デフォルトの名無しさん
07/10/13 08:51:12
DAO内で自分でSQL発行じゃね？

711:デフォルトの名無しさん
07/10/13 10:59:52
>>710
その場合でも、手動マッピングはするわけだが

712:デフォルトの名無しさん
07/10/13 11:32:35
わかった！>>707はマッピングせずに

M　a　p　を　そ　の　ま　ま　使　う　ん　だ　よ　！

713:デフォルトの名無しさん
07/10/13 13:24:55
ものによってはMapそのままでも悪くないと思うけどな
キー値の取得がプロパティの取得につながるし

ただ、HashMapとかそのままつかうのだけは禁止
キー値が存在しない場合Exceptionをかえすような実装ならOK

714:デフォルトの名無しさん
07/10/13 17:00:59
まーた、Map厨発生か。
が、キー値なしで例外は納得した。

715:デフォルトの名無しさん
07/10/15 15:09:20
実は Microfost Data Access Objects のことなのかも知れん。

716:デフォルトの名無しさん
07/10/16 12:47:53
ResultSetだってRowSetだってmapベースだろ
DelphiだってBCBだってスクリプト系だって

717:デフォルトの名無しさん
07/10/16 14:05:52
こいつは何をいっているんだ？

718:デフォルトの名無しさん
07/10/16 14:19:27
はじめから道具ありきで、どっかで道に迷っちゃうんだろ
若い奴らは大変なんだよきっと

719:デフォルトの名無しさん
07/10/16 14:28:44
Map系ってのはMapインターフェースを実装したものではなくて
名前で値を引っ張るものってことだろ。
何もおかしいことはない。

720:デフォルトの名無しさん
07/10/16 14:42:06
どうしてわざわざオブジェクトに情報を詰めなおすのか
知っているか？

721:デフォルトの名無しさん
07/10/16 14:42:10
以前、このスレだか過去スレだかに、Map、Mapと騒ぐ奴がいたのな。
その流れを汲んでの話なんだよ。

自分で間違ったことを言っていないつもりなのだろうけど、
このずっと前からのスレの流れ的には空気読めてないんだよ。
しばらくROMってろ。

722:デフォルトの名無しさん
07/10/16 14:52:41
>>720
JavaがLightWeightじゃないから

723:デフォルトの名無しさん
07/10/16 17:47:29
>>721
それは知っているが、そんな昔の狂ったやつなんてもう今はいないだろう

Mapのように名前を使ってアクセスする場合何が問題だったのかだけがわかって使っていればおけ

VCLのようにラッパクラスをそのまま入れないこと、存在しないキーに対して
取得しようとしたときに例外を発生させることがきまっていれば問題はない

724:デフォルトの名無しさん
07/10/16 17:52:59
>>719
おまえの頭がおかしいということはわかった。

725:デフォルトの名無しさん
07/10/16 18:07:58
"存在しないキーに対して取得しようとしたときに例外を発生させる"
これが必要なのはなんで？
と思ったが、nullが戻ってきたんじゃデータが無いのか項目自体がないのかが判別できないのか
それ以外の理由もある？

726:デフォルトの名無しさん
07/10/16 18:48:26
そもそもDBにnull入れないほうがよくない？

727:デフォルトの名無しさん
07/10/16 21:53:40
そうか？

728:デフォルトの名無しさん
07/10/16 22:33:48
NULLが無いほうが楽ではあるかもな色々と
ただ、Oracleのような、空文字列がNULLであるようなDBMSではNULLを
避けようが無いだろう

729:デフォルトの名無しさん
07/10/16 22:41:00
NullはDBに必要だろ

730:デフォルトの名無しさん
07/10/16 22:42:28
(商用で)一番普及してしまっているOracleの仕様にはモニョるものがある罠・・・。

ただnullはアレで便利な面もあるので、ここらは宗教論だろう。

731:デフォルトの名無しさん
07/10/17 01:04:31
DBにNULLが全くいらないってのが
どんな状況かわからん。

732:デフォルトの名無しさん
07/10/17 02:44:06
Mapを使う時点で、静的型言語の利点を失っている気がする。
だったら、RoRのActiveRecordのほうがよっぽど使いやすい。

733:デフォルトの名無しさん
07/10/17 09:26:04
HOGE <> 1 な条件で、HOGE が NULL なレコードが取得できないのが
直感的じゃないと思うので、検索列には NULL は勘弁して欲しいところだ。

734:デフォルトの名無しさん
07/10/17 11:59:11
>>733
nullがほしいならnullもor条件いれればいいじゃない

直感的ではないというのは同意だが、SQLにとってnullは特別な値だから仕方がないか

735:デフォルトの名無しさん
07/10/17 12:11:08
検索の際の特別扱いだけでなく、
NULLありのカラムはインデクス張る際にも実装上の制約があったりするし、
単純にホスト言語のデータ型とマッピングする際にもやや面倒が生じるので、
少なくとも意味のあるデフォルト値が考えられるようなエンティティなら、
NULLの代わりにデフォ値突っ込んだほうが楽は楽な気がする。

ま、常にそうできるというわけでもないが。

736:デフォルトの名無しさん
07/10/17 12:23:44
むしろプログラム言語で3値論理をきれいに扱えないのがおかしい

737:デフォルトの名無しさん
07/10/17 13:08:35
C#のnullは3値論理だ

738:デフォルトの名無しさん
07/10/17 13:09:54
Javaなら3値普通に扱えるだろ・・・

739:デフォルトの名無しさん
07/10/17 15:11:51
C.J.Dateたんは第五正規形まで正規化すればnullなんていらんだろ派だね。

740:デフォルトの名無しさん
07/10/18 11:31:41
>>733
条件を () で括って最後に is true

741:デフォルトの名無しさん
07/10/21 11:43:49
Daoは1テーブルごとに1クラス作成して、CRUDのメソッドがあるのが普通なのでしょうか。
1:nのテーブルがあって、一覧を表示する詳細な検索画面などでどうしても結合が必要な場合や条件が複雑になる場合は
その画面専用?のメソッドを作成するものなのでしょうか。

742:デフォルトの名無しさん
07/10/21 16:28:16
というか、それはORマッパがやるだろ。

743:デフォルトの名無しさん
07/10/21 17:46:11
テーブル単位でCRUDってのは大概O/Rマッパがやってくれる
連結は製品次第

DBのようにテーブル状に結果が入るほうがいい場合もあるし
そのつど連結先を取ってくるほうがいい場合もあるしなんとも

744:デフォルトの名無しさん
07/10/21 18:06:18
DAOやORマッパは手段なのに、
目的の方を「どうするのが普通でしょうか？」って
おかしくね？

745:デフォルトの名無しさん
07/10/21 18:34:43
そういうヤツは、O/Rマッパの仕様に合わせてテーブル設計とかしそうで怖いよな。
COBOLerお得意の横長DBとか。

まあ、漏れは直でSQLゴリゴリ出来る人なので、条件・結合が複雑だったら
SQLを直書きではあるな。

746:デフォルトの名無しさん
07/10/21 21:12:53
テーブル単位でCRUDするだけがORマッパーの役割と思ってる奴多くね？

747:デフォルトの名無しさん
07/10/21 21:14:14
少ないと思う

748:デフォルトの名無しさん
07/10/21 21:39:36
>>539
って結局JSPで、DTOからコード値をgetして、
<% if (sex.equals("1") {%>男 ... (taglibとか)
みたいなのを書くってことでしょうか。

それともDTOにUser#getSexName、getSexCodeを自前で準備するものですか。
これだと自動生成が大変なのですが。。。
前にViewでマッピングしようとするとコネクションが切断？されてるから例外になったり、
マッピングを自動でするような機能がなかったりして断念したことがあるのですが。

749:デフォルトの名無しさん
07/10/21 23:47:14
>>748
その例外はO/Rマッパ依存の部分でしょ
たとえばJPAのリファレンス実装であるToplinkは参照専用のコネクションを開くので問題ない
それにリソースファイルで扱う場合も多いし、すべてアプリやライブラリなど実装次第としかいえんぞ

750:デフォルトの名無しさん
07/10/22 16:02:03
そこはentityにisMan()isWomen()を持たせたら？

751:デフォルトの名無しさん
07/10/22 19:55:03
>>748
定数値と表示名称のマップをアプリケーションスコープに保存して
ELでアクセスしたりとか
DBに持たせてEntityの2次キャッシュにしたりとか
色々方法はあると思う

752:デフォルトの名無しさん
07/10/22 19:57:38
俺はマップをアプリケーションスコープに入れる派

753:デフォルトの名無しさん
07/10/22 20:38:01
>DBに持たせてEntityの2次キャッシュにしたりとか
これってどういうことなん？詳しくお願いしたいかもー。

754:デフォルトの名無しさん
07/10/22 21:59:39
定数マスタとかをDBに持ってる場合
Hibernateなどの2次キャッシュ機能を使えば
アプリレベルでEntityを共有できる
これを通常のEntityと関連付けてLazyロードさせれば
Entityだけで名称表示を行える

まぁでも設定とか色々と面倒かも

755:デフォルトの名無しさん
07/10/22 22:36:37
>>754
おー、なるほど、どうもです。

756:デフォルトの名無しさん
07/10/23 01:30:51
O/Rマッパでキャッシングはデフォっしょ
やってないほうが少ないのでは?
おかげでLAZYが便利

ただ、hibernateではセッション明けとかないとダメかもね

757:デフォルトの名無しさん
07/10/23 21:41:49
キャッシングした場合、定数マスタかなんかが更新されるタイミングっていつになるのでしょうか。
例えば、DB直接いじって定数テーブル？に1行追加して、htmlの画面で<option>がふえてねーじゃん！てことにならない？

758:デフォルトの名無しさん
07/10/23 22:10:44
そら、なるんだろうなぁ

759:デフォルトの名無しさん
07/10/23 22:37:32
だめやん

760:デフォルトの名無しさん
07/10/23 22:43:49
ORマッパー＝はいばね
な件

761:デフォルトの名無しさん
07/10/24 01:52:07
ORマッパ使おうが使うまいが
キャッシュ対象は読み取り専用のデータだけでしょ
プロパティファイルのDB格納版というか

762:デフォルトの名無しさん
07/10/24 01:58:30
リソースファイルも変更時には配備しなおしてVM再起動が必要だろ
それと同じこと

763:デフォルトの名無しさん
07/10/24 01:59:36
>>757
キャッシュ対象データはO/Rマッパーを使って更新する

764:デフォルトの名無しさん
07/10/24 13:48:23
>>757
だからデフォルトのキャッシュ設定はoff。

キャッシュ側で短めの有効期限を設定したり、
動的な更新を想定しないテーブルのみに使ったりする。

クラスタの場合はDB直接編集でなくとも不整合が起こるので、
分散キャッシュ(OSSだとJBoss TreeCacheが有名)を使う事もある。

765:デフォルトの名無しさん
07/10/24 22:27:37
>>757
管理者機能でマスタ更新とか作ったりするが、それじゃだめ？
DB直接いじってもボタン押したらキャッシュ読み直しみたいな。
大抵そんな機能を要求されるとマスタに好きなだけ追加削除更新したいって言い出すけどな。
性別なんて男性・女性・不明ぐらいでいいのに全部編集したい！とかいう客は珍しくない。

766:デフォルトの名無しさん
07/10/25 10:28:47
性別マスタの編集で追加削除ってどんな時代だろう

767:デフォルトの名無しさん
07/10/25 20:51:23
時代っていうか顧客。
「MTFTS」「MTFTV」「その他」「不明」とかぞろぞろあるんじゃね？

768:デフォルトの名無しさん
07/10/25 23:19:50
すまんすまん。性別は極端な例だったか。
最近はいろいろと考慮して、男・女の2択はまずやらないわけです。
そういう人からすると”不明”てのはあんまりよろしくないからね。
単純にデフォルトの表示を空白とか"-"にして必須選択にしないってのがうちの会社の流れです。

769:デフォルトの名無しさん
07/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");

とやったら「シンボルを見つけられません」とでてしまました。

770:デフォルトの名無しさん
07/11/08 20:15:48
>>769
原因はsqlMap.queryForListの戻り値が
型指定なしListになってるっぽいところじゃないかな。
キャストしても確か出たと思うので、
メソッド宣言の頭に@SuppressWarning("unchecked")をつけるとか。

771:デフォルトの名無しさん
07/11/08 20:31:40
1.4までのライブラリはそうなるの多いね
でも、JPAは5.0前提なのにキャストが必要で警告でるってのは納得いかないんだぜ・・・

772:デフォルトの名無しさん
07/11/08 21:00:45
レスどうもありがとうございます。
なるほど、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 をつけても、このメソッドでは警告が出ないようになりました。
勉強になりました。どうもありがとうございました。

773:デフォルトの名無しさん
07/11/08 21:27:11
Genericsは1.4以前のコードとの相性もあるが、リフレクションとも相性が悪いからね。
外部との連携が多いと利点を活かしきれないことも多いとは思う。

JDBC4.0があと2年もすれば普及すると思うけど、
>>769の手間をデータベース開発元がやってくれるから凄く楽になる。
SQLを外だしするってだけでも恩恵はでかいからiBatisは残るだろうけど。

774:デフォルトの名無しさん
07/11/10 00:44:24
ibatisをspring等と連携しないで使うには、
SqlMapClientをpublic static等で参照できるようにして
#setUserConnectionでjava.sql.Connectionをセット、queryXXXを実行するで問題ないでしょうか。
あと、いまいちSqlMapSessionの存在意義などがわからないのですが・・・

775:デフォルトの名無しさん
07/11/11 18:18:46
struts+ibatisで開発しています。
DBの接続先をibatisのxmlに記述しているのですが、
参照するDBが複数になってしまった場合どんな感じでやるのがベストだと思いますか？
単純に設定ファイル追加か、追加されたDBのコネクションを取得してセットしてやるが候補なのですが、おかしいかな。

776:デフォルトの名無しさん
07/11/11 21:22:36
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;
　　}
}

777:デフォルトの名無しさん
07/11/11 21:50:05
>>776
thx。
やっぱそういう感じになるか。

>>774の#setUserConnection？をつかってもできそうな、できなさそうな

778:デフォルトの名無しさん
07/12/14 00:33:18
HibernateToolsでhbmファイルを自動生成しようとしてるんですが、
関連があるテーブルだと勝手に多重度が設定されますよね。
one-to-manyとか。

あれを自動で設定されたくないんですが、
自動生成時にオプションとかでオフにできないものでしょうかm(_ _)m

779:デフォルトの名無しさん
07/12/14 01:50:45
DBから関連はずせば?

780:デフォルトの名無しさん
07/12/14 09:23:05
DBの制約残したままでやりたいのですm(_ _)m

781:デフォルトの名無しさん
07/12/14 21:34:57
DBの構造コピーして、関連はずしてマッピング作成ってのがてっとりばやそうだな

782:デフォルトの名無しさん
07/12/18 08:58:11
そうかやっぱり関連外す手しかないか...

ありがとうm(__)m

783:デフォルトの名無しさん
07/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() がない)
これはこれでいいのですよね？

784:デフォルトの名無しさん
07/12/25 15:24:48
環境によるけど、コネクションを各自にまかせるタイプと、
フレームワークなどがそれらを完全にコントロールしてユーザーは
コネクションを勝手に閉じたりしてはいけないタイプがある。

トランザクションがどの境界でコミットされるかなど、重要なことは多い。
わからないことがあったら普通に素直に聞いたほうがいいよ。
とくにあとからヘルプで入った場合はチーム内での暗黙のルールとかあると思うし。

785:デフォルトの名無しさん
07/12/26 00:39:23
> 質問1.：
> session には clear() というメソッドもありますが、close()とはどう違うのでしょうか?
Hibernate は取得したオブジェクトを Session にキャッシュしている。
そのキャッシュのクリアが clear() で行える。
ただし、この関数を呼び出してしまうと、Session#save() で永続化しているが、まだDBにコミットして
いないアクションさえもクリアしてしまう。
close() はそのセッションの破棄を意味する。

786:デフォルトの名無しさん
07/12/26 00:45:09
> 質問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 のソースを追えばすぐに分かると思う。

787:デフォルトの名無しさん
07/12/26 00:54:03
このように、Hibernate+Spring の組み合わせの場合、基本的には Session#close() などを Spring 側に任せるように
することが出来る。
>>784 も言及しているが、この辺は各プロジェクトでどのような扱いにしているのかで話が変わってくるので、
聞いた方が早い。

ただ、HibernateDaoSupport を継承したとしても、HibernateCallback の中でない限りは Spring が Session を自動的に
閉じたりすることを期待できない気もする。
とはいえ、AOP を使用して閉じるようにしているのかもしれないので断言は出来ない。
だけど、ScrollableResults は自力で閉じないとムリなような気が・・・。

788:デフォルトの名無しさん
07/12/26 01:28:46
Struts＋Spring＋Hibernateの組み合わせなら、AOPで閉じてるかSession In Viewで閉じてるはず。
てか、俺はそうした。

789:デフォルトの名無しさん
07/12/26 02:08:53
どこの現場もフレームワークの上にさらにかぶせてる場合も多いからなんとも
オープンソースだけにソースに手が入ってる可能性も高いしね

断言は危険

790:デフォルトの名無しさん
07/12/26 17:42:16
みなさんレスどうもありがとうございます。
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
07/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
07/12/26 17:50:18

<bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
　<property name="sessionFactory"><ref bean="sessionFactory"/></property>
</bean>


<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
07/12/26 17:50:47
続き


<bean id="tsInterceptor"
　class="org.springframework.transaction.interceptor.TransactionInterceptor">
　<property name="transactionManager"><ref bean="transactionManager"/></property>
　<property name="transactionAttributeSource"><ref bean="tsAttribute"/></property>
</bean>


<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>

何度も連投すみません。以上です。

794:デフォルトの名無しさん
07/12/27 00:18:15
>>783
お前がプロジェクトに対して発言権があるかどうかはわからないが、
おれは出来る限りHibernateDaoSupport を使うときには
HibernateCallback で実装を進めるようにしてもらったほうがいいと思ってるし、
方針が曖昧なようならそう提案してみてはどうだろう？

そうすることによって
・ Session の境界をコントロールしやすくなる。
(HibernateTemplateがネストしたときには下位のセッションが上流に合流する)
・session の close() 忘れが無くなる。
(これはテスト実行時にデッドロック的な挙動を引き起こしたりする)
という利点がある。

OpenSessionInViewパターンは一番シンプルなんだが、
View 層に処理が渡ってから DB にアクセスするしにいったりする挙動が
三層モデル大好きな奴らから理解を得られない場合があるしやめたほうがいい。
複数画面をまたいでオブジェクトを引き回すときには結局Hibernateのセッション切れるんで、
あんまり有利でないことも多いし。

次ページ