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
<!-- 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
07/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>
何度も連投すみません。以上です。
794:デフォルトの名無しさん
07/12/27 00:18:15
>>783
お前がプロジェクトに対して発言権があるかどうかはわからないが、
おれは出来る限りHibernateDaoSupport を使うときには
HibernateCallback で実装を進めるようにしてもらったほうがいいと思ってるし、
方針が曖昧なようならそう提案してみてはどうだろう？
そうすることによって
・ Session の境界をコントロールしやすくなる。
(HibernateTemplateがネストしたときには下位のセッションが上流に合流する)
・session の close() 忘れが無くなる。
(これはテスト実行時にデッドロック的な挙動を引き起こしたりする)
という利点がある。
OpenSessionInViewパターンは一番シンプルなんだが、
View 層に処理が渡ってから DB にアクセスするしにいったりする挙動が
三層モデル大好きな奴らから理解を得られない場合があるしやめたほうがいい。
複数画面をまたいでオブジェクトを引き回すときには結局Hibernateのセッション切れるんで、
あんまり有利でないことも多いし。
795:デフォルトの名無しさん
07/12/28 00:38:31
>>790
誤解のないように言っておくが、iBatisでもSpringと組み合わせれば似たようなことができるよ
796:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/01/20 09:43:59
Mr. Persisterには関連のマッピング機能は実装済みですか？
798:デフォルトの名無しさん
08/01/20 13:04:53
ORマッピングはこういう↓抽出も、効率的に出来るのでしょうか？
SELECT
売上実績.*
FROM
売上実績
INNER JOIN 顧客 ON
売上実績.顧客番号 = 顧客.顧客番号
INNER JOIN 商品 ON
売上実績.商品番号 = 商品.商品番号
WHERE
売上実績.年 = 2007 AND
売上実績.月 = 12 AND
顧客.名前 = 'ひろゆき' AND
商品.商品名 = 'うまい棒'
ORマッピングではないけど、独自実装のDAOで、
こういう感じのSQLを1回発行すればいいものを、数万回発行するものがあったので……
799:デフォルトの名無しさん
08/01/20 13:11:16
いや、どちらかというとこんな感じか……
SELECT
売上実績.*
FROM
売上実績
INNER JOIN 顧客 ON
売上実績.顧客番号 = 顧客.顧客番号
INNER JOIN 会社 ON
顧客.会社番号 = 会社.会社番号
INNER JOIN 商品 ON
売上実績.商品番号 = 商品.顧客番号
WHERE
売上実績.年 = 2007 AND
売上実績.月 = 12 AND
会社.社長 = 'ひろゆき'
商品.商品名 = 'うまい棒'
800:デフォルトの名無しさん
08/01/20 13:14:37
やべー、
売上実績.商品番号 = 商品.顧客番号 じゃなくて、
売上実績.商品番号 = 商品.商品番号
連投すまん。
801:デフォルトの名無しさん
08/01/20 15:25:07
>>798
それができないマッパってたぶん存在しないぞ
802:デフォルトの名無しさん
08/01/20 21:40:23
その独自実装のDAOが1TABLEマッピングしか出来なかったんだろ？
昔、誰かが作ったそんな独自ORマッパーがあって、使えんから
改造した経験がある。公開されてるので、さすがにないだろ。
803:デフォルトの名無しさん
08/01/21 09:24:19
Seasar2とかのDAOでもそれってできる？
804:デフォルトの名無しさん
08/01/21 15:31:37
俺もわかっていないのでみなさんに聞きたい(おしえていただきたい)。
以下であってる？
○iBatisの場合、>799 のような SQL を直接書いて、得られた結果セットは <resultMap> タグに書いておいた
売上実績 エンティティにマッピングされる。(これはよくやってる)
Hibernate の場合、売上実績の hbm に、売上実績.顧客番号→顧客.顧客番号 とかの関連 を書いておけばよい。
ただし join フェッチにしないとだめ。
# あ、結果セットは売上実績TBL単体しか見てないので、この場合は joinフェッチとか select フェッチとか関係ないんだっけ?
805:デフォルトの名無しさん
08/01/21 15:51:17
>>803
S2DaoはSQLファイル書けばできる。
S2JDBCはSQL書かなくてもできる。
806:デフォルトの名無しさん
08/01/21 20:11:07
JPAサポートしてるツールでJPA使うのが一番らくかもね
Hibernateも今後JPA実装をまずメインにしていくし
807:デフォルトの名無しさん
08/01/21 21:09:23
っつーか、JPA仕様作ってるのがHibernateだからな。
808:デフォルトの名無しさん
08/01/21 23:34:51
>>807
仕様策定とプロダクトと一緒にするなよと
809:デフォルトの名無しさん
08/01/21 23:51:59
>>808
Hibernate陣営が仕様策定に大きく関わっているってことだろ？
810:デフォルトの名無しさん
08/01/30 23:21:38
hbm2javaで、javaソースコードを
UTF-8で作成したいのですが、どのような設定を行えばよいでしょうか？
>>62で書かれている事象と同じようなことになってしまいます...
811:デフォルトの名無しさん
08/01/30 23:30:02
java -Dfile.encoding=UTF-8
812:デフォルトの名無しさん
08/02/08 20:54:05
Springは基本的にコアは 1.1.x で完成していて、
1.2.x 以降は設定ファイルの書式が若干良くなったり
かえって悪くなったりしてるだけじゃなかろうか。
(XML 名前空間は使いにくいから失敗だと思う。
機械が読むには悪くないけど、人間が書くには疲れる。)
spring-ws や spring-webflow みたいなサブプロジェクトが
どれだけ完成度高めていくかと、
新たに面白いサブプロジェクト生まれないかなぁって辺りに関心がある。
コアのバージョンはもうどうでも良いって言うか。
Guice や Sesar2 はハナから問題外じゃね？
デファクト取っちまってるプロダクトがどうしたって強いし。
あとは Rails にだまされてる人達が
どれだけ早く DI の妥当さに気がつくかだけでしょ。
813:デフォルトの名無しさん
08/02/08 21:53:32
ふと思ったがJAXBとJPAが強力に結びついて
XML->Beans->DBまで一発でリレーション作れたら凄い楽かも。
ついでJAXBの生成したBeanにバインドしたSwingフォームを作ってくれるとなおよし。
814:デフォルトの名無しさん
08/02/09 03:37:21
>>812
マルチうざ
815:デフォルトの名無しさん
08/02/09 03:39:52
>>813
NetBeansはさわったことあるかね?
JPA直はコンポーネントバインディングでできてるからJAXBも問題ないでしょ
でも、JAXB直はあまりないんじゃね？
JAX-WSで使うのが本筋でしょう
これもNetBeansだと全自動で鯖もクライアントも用意できるし
816:デフォルトの名無しさん
08/02/09 23:46:31
検索取得系の処理用にとiBATISに興味があるのですが、
(1)DTOや検索条件ホルダーにゲッターとセッター必須ですか？
この手のクラスなら単純にpublicフィールドでいいじゃんと
(2)SQLテンプレートを別ファイルにしないオプションはありますか？
別ファイルのSQLのIDの代わりに、
テンプレートの文字列+DTOのClassを引数にできたいしませんか？
ちなみに更新系はアクティブレコード方式のマイナーなの使っています。
DBはマーチン先生の言葉で言うところのアプリケーションデータベースで、
DBA、データ管理者を開発の主要メンバが兼任していて、
処理は大量の項目を持つテーブルのCRUD処理がメインで、
複雑なドメインモデルが必要なロジックはほとんどなく、
保守運用上開発者は当然テーブル構造を熟知していなきゃだめだめ、
な環境だと初めにテーブルありきで名前による自動マッピングで全てを解決する
シンプルなアクティブレコードがいいのかなぁって思ってます。
817:デフォルトの名無しさん
08/02/10 00:05:19
すでに使ってるフレームワークがあるのならそれを使ったほうがいいんじゃない?
更新系と同一のものを使えばキャッシングとか性能向上されるようになってるはずだよ
818:816
08/02/10 10:31:26
>>817
実は複雑な検索には、そのActiveRecord方式のフレームワーク使ってないです。
基本的に テーブル（ビュー）--ドメイン
を設定ファイル無しでマッピングするので、もしフレームワーク使うなら、
複雑なJOINの過程の検索条件列を無理矢理最上位のSELECTに書き、
元の1レコードがN件分現れる非常に直感的でないビューを作成しないといけないのです。
そのため今はSQLを引数に、読取り専用汎用ドメインを作成するような
ユーティリティでお茶を濁している感じなのですが、Webのシステムでないとはいえ、
文字列連結でSQL組んでたりであまりよろしくないのです。
両者とも私が関わる前からあり、別に私が選択した方式ではないです。
ActiveRecordで更新系に関してシンプルになるのは割りと気に入っているので、
複雑な検索系だけはiBATISなんかで改善できないかぁと思って色々調べてます。
819:デフォルトの名無しさん
08/02/10 15:07:54
うーん、その既存のフレームワークが厄介ということか
どのO/Rマッパにしろたいていキャッシングするからそれを無効に設定できるやつを選んでね
そもそもその既存のフレームワークはキャッシングはしてないの？OFFにするとパフォーマンス下がるよね
検索系だけなら複雑なO/Rマッパは使わないでCommons DbUtilsがいいんじゃない？
JDBCのラッパなのでコネクション取得できればそれでいいわけで
昔からあるということは新しいJDKとかつかえないだろうからなおさらかな
820:816
08/02/10 17:53:20
>>819
以前にソースを見たらスレッド・トランザクション単位で、
主キーをキーにHashTableにドメインのインスタンスを保持していましたが、
常にDBからSELECTし、同じ主キーのインスタンスが既にマップに存在するなら
当該インスタンス上の値を上書きして返すようになっています。
なのでキャッシュしていてもパフォーマンス向上が目的でなく、
同じ主キーのインスタンスは1つということの保証が目的と理解しています。
Commons DbUtilsのソースを落として見てみました。
今現在のやり方はマップリストを返すやつと大体同じです。
iBATISは名前パラメータと動的部分をタグで制御っての気になります。
名前によるバインドはOraclePreparedStatementで直接受けちゃえば
使えそうだけど、それは反則のような気がして・・・。
821:デフォルトの名無しさん
08/02/10 18:45:55
今となってはiBATISってそんなに便利なものにもみえないけど、
SQLを書きたいのか、隠したいのか、JDK5が使えるのか等
いろいろ前提条件があるからなんとも
iBATISは設定ファイル書いたりするのがたるいよ
今のバージョンはどうなってるかわからないけど
O/RマッパとしてはiBATISとDBUtilisはカプセル化が薄いので習得は容易だと思う
でもこの程度ならその自前のやつとそうそうかわらないかと
JDK5が使えるならJPAとか使うのもいいかも
標準技術だけあって各種ツールサポートが一番充実しているのが強み
822:816
08/02/11 00:27:15
JDK5は今は使えないです。SQLは隠さない方向で。
求める機能としては名前パラメータのSQL文字列と、
検索条件のマップもしくは検索条件DTOを引数にして結果のマップのリストを取得。
戻りのDTOのClassも引数に追加してDTOの配列で結果を取得。
スカラークエリから各種スカラー値を取得できるショートカットもあれば便利。
バインド後に実際に実行されるSQL文字列のログ出力。
(パラメータの型を無視して''やエスケープなしで単純置換して文字列でも可)
ソートキー列と値の配列から指定キー以降でMAXN件取得なんかもあれば。
なければ自分で作れば済むような機能もありますが・・
今日調べたらSpringJDBCのNamedParameterJdbcTemplateが求めるものに近そうです。
ソース見たら名前パラメタの条件の値がコレクションなら複数の?,?に展開とか賢い。
素のPreparedStatementだとIN句簡単につかえないのに。
ネックは5.0じゃなきゃ駄目なのと、Springのjarに組み込まれてる点か。
823:デフォルトの名無しさん
08/02/11 02:15:27
SpringJDBCが使いたいのならバージョンさげれば1.4で動くはず
DTOのリストでデータが帰ってくるのでいいのならDBUtilsで十分かと
当たり前だけど、SQLを隠さずにしようと思うと制限は出るよ
足りない機能はそれをラップすればいいだけ
マップやDTOを検索条件にするのはたぶん流行ってないかと
824:816
08/02/11 10:59:15
一部の機能を放棄すれば1.4でも使用可能なのですね、勘違いしてました。
マップで条件指定って流行ってないんですか。
リストか可変長引数が主流ということでしょうか？
それだとWHERE句で指定する列やサブクエリの数自体が可変で、
かなり動的にテンプレートを組み立てないといけない場合に
?の追加と条件リストへの値の追加との同期が厄介かなと。
名前パラメタとマップで条件指定なら、SQLテンプレートだけを動的に組み立てて、
別途条件MAPには順番気にせず、値が条件指定無しでNULLだろうが全部入れておけば、
内部で実際に名前パラメタで使用して?に置き換わったものだけ、
その順番で条件マップから条件の配列に再構築してくれる。
っていう点で有利だなと思ったのですが。
825:デフォルトの名無しさん
08/02/22 15:30:30
Seasar2とHibernateで学ぶデータベースアクセス JPA入門
URLﾘﾝｸ(book.mycom.co.jp)
826:デフォルトの名無しさん
08/02/22 23:41:03
問題はJPAと一番相性がいいのがEJB3で
続いてSpringJPAサポートなところなんだよね。
Seasar2やHibernateに依存しまくる文章はないものと信じたい。
827:デフォルトの名無しさん
08/02/23 00:59:49
>>826
SpringJPAサポートって何かメリットあったっけ？
何のありがたみもないJpaTemplateとJpaDaoSupportしか知らないんだが。
828:デフォルトの名無しさん
08/02/23 03:17:54
Seasar2ってついてるから買わない
829:デフォルトの名無しさん
08/02/23 14:04:52
ただのJPAの本でよかったんだけどなぁ・・・
830:デフォルトの名無しさん
08/03/26 18:03:43
hibernate3 + Spring なのですが、
@Entity で bean とテーブルマッピングは一箇所で定義するが、
@NamedQuery は使用せず、SQL は外出しにする良い方法はないでしょうか？
マッピングは annotation を使いたい、しかし SQL は外出しにしたい。
というのが希望です。
831:デフォルトの名無しさん
08/03/26 18:43:33
Springつかってるならそれでインジェクトすればいいだろう・・・
832:830
08/03/26 20:45:09
>>831
あ、DAO に突っ込めばいいってことですよね？
そんで session で createQuery なり createSQLQuery を呼ぶと。
確かにそうですね。
実は下記の記事を読んで、
URLﾘﾝｸ(www.ibm.com)
これの GenericDao を使いたいなと思ったんです。
ただ、それだと DAO が query用のメンバで汚くなるかな、と…
と思ったんですが、それはそれで query をまとめとくクラスを作るとか、Map を使えば無問題っぽいですね。
あ、なんか解決っぽいです。
ありがとうございます。
833:デフォルトの名無しさん
08/03/31 10:10:38
>>830
JPAでやってるならorm.xmlに書けば出来る
834:デフォルトの名無しさん
08/04/12 02:25:36
Hibernateで複数のテーブルorビューに一つのマッピング定義and一つのEntityって可能なんですか？
835:デフォルトの名無しさん
08/04/14 17:02:07
>>832
これの日本語訳を見つけた。
URLﾘﾝｸ(www.ibm.com)
836:デフォルトの名無しさん
08/04/17 23:16:09
HibernateなどのORツールを使う利点ってなんでしょう？
beanに手書きmappingすることで工数削減以外の、
パフォーマンスなどで利点があるのでしょうか？？？
837:デフォルトの名無しさん
08/04/17 23:28:25
今SQLをゴリゴリ書いてシステム作ってるけど、
テーブル間の関連を書いておくだけで簡単に関連をたどっていけるのはかなりラク
A4何ページにもなるようなSQLなんて見とれんよ
でもHibernate使うのであればそれなりの知識は必要。
迷ってるぐらいならやめとけ
838:デフォルトの名無しさん
08/04/17 23:37:46
>>836
工数削減できれば十分じゃね?
つまり給料増えるわけだ
実際のところ複雑なSQL発行することももうほとんどないけどね
昔はSQL発行をぎりぎりまでチューニングしないとまともに実用速度が出なかったけどね
へたなSQL書くよりO/Rマッパのほうが効率がいい場合も多いし
839:デフォルトの名無しさん
08/04/17 23:50:40
>>838
工数削減⇒売り上げ減⇒間接費の負担増⇒給料減
840:デフォルトの名無しさん
08/04/17 23:54:25
>>838
個人的にはそのとおりなんですが、
要員調達の困難さ（OR技術者が少ない）が障害で、上司が導入を拒んでいるんですよ。
で、他に理由があればいいなと思いまして。
841:デフォルトの名無しさん
08/04/18 00:01:41
攻め方として、
みんながみんなORまっぱをしってるひつようはないですよ。
SQL技術者なら多いという判断でしょうか？
であればSQLサポートツールとしてiBATISかS2DaoかS2JDBCを導入させてください。
とか。
842:デフォルトの名無しさん
08/04/18 00:21:51
>>840
道具に流されるのはよくないが、JPAとか標準的なＯ／Ｒマッパは調達は容易だと思うけど
教育のコストも普通は考慮して納期設定するからどの程度の人員かどうかだな、結局は
>>841
S2JDBCはいわば俺俺JPAだから個人的にはオススメしにくい
それくらいならJPA使ったほうがいい
JDBC直でもいいとは思うけど、フレームワークでDBアクセスの方法はある程度絞ったほうがいい
まずはcommonsとかからスタートしてステップアップしていったほうがいいかも
JPAの利点はJavaEEの標準技術なのでサポートするツールがたくさんあるところだな
実装はRIのToplinkかユーザー数の多いHibernateの2択になることがほとんどだと思う
ToplinkはJPA2.0でもRIとなる予定で今後に期待されるとか、TopLink自体はOracleのものだから
glassfishかOracleのAS使う予定があるのならそちらがいい
843:デフォルトの名無しさん
08/04/18 00:31:54
トランザクション系の処理が中心でリレーションシップがある
複数のテーブルからなる情報を取り扱うシナリオで、次のような条件を含む場合。
更新を前提にするので読み取りにJOINは使えないか使いにくい。
必要に応じてアクセスパスをたどる方法でのデータ取得が望ましい。
楽観的排他。
こういうケースでORMはおすすめ。
逆に問い合わせ中心でJOINや射影が有効。大域処理。
シビアなロック制御が必要な処理といったケースではあまり必要じゃない。
単純に１テーブルを１データオブジェクトにマップするだけが目的だったら正直どうでもいい。
844:デフォルトの名無しさん
08/04/18 00:37:28
>>842
JPAのまともな実装見たこと無いんだけどいいのあるか？
845:デフォルトの名無しさん
08/04/18 00:39:02
JPAでというお勧めであればS2JDBCはちょっと弱いけど、純粋に開発効率とメンテナンス製あげようと思ったらS2JDBCはなかなか良いと思う
846:デフォルトの名無しさん
08/04/18 00:41:45
>>844
TopLink Essentialsでいいんじゃねーの？
吐き出すSQLみてるとLAZYとか一番まともそうだよ
847:デフォルトの名無しさん
08/04/18 01:02:13
そもそも、今どうやって書いてるんだ？
848:デフォルトの名無しさん
08/04/18 01:16:24
JPAの範囲で済むならTopLinkでもいいが
SQLや実装固有の機能使うならHibernateの方がいい
849:デフォルトの名無しさん
08/04/18 01:20:23
SQL使いたかったらDatasourceをインジェクトすればいいだけだと思うんだが
850:デフォルトの名無しさん
08/04/18 09:37:00
>>839
工数削減が売上減ってどんだけバカな見積もりだしてるのｗ
851:デフォルトの名無しさん
08/04/18 14:28:35
工数減った分技術料で乗せたらいいんじゃ
852:デフォルトの名無しさん
08/04/18 14:56:02
>>850-851
なんという殿様商売
こちとら工数×単価でどっちも削られっぱなしなんだぜ？
853:デフォルトの名無しさん
08/04/18 19:00:48
単に営業がバカなだけだろ、それ
854:デフォルトの名無しさん
08/04/18 23:39:09
ふつうは開発効率がよくなった結果、残業が減ってハッピーとだろう
期間は今までどおりにしろよ
855:デフォルトの名無しさん
08/04/18 23:57:23
>>852
オマエが受身すぎなだけだろ。
ﾊﾞｶは甘やかしてもいい事無いぞ
856:デフォルトの名無しさん
08/04/30 00:00:00
>>852 の気持ちはよくわかるし、ほかの人のレスも正論なのはわかるけど。
この前 NTTデータとNRIの人と話したが、
あいつら、エンドユーザには絶対に単価情報を出さないって言ってた。
「人月ビジネスすると儲からないので、絶対一括」。
そして >>852 のような下請けが削られる。これ最強。
もっとむかつくのは、うっかりデータの新人が教えてくれたんだが、
うちら下請けには、すぐ工数削るのに、エンドユーザへは一切金額下げてない。
ほんとむかつく。まぁデータやNRIでここを見ている人もいるだろうし、優秀な人もいるけど。
あと、データの公共はほんとクソだな。自分たちは何もできないのに、
役人の顔色伺いながら、こっちの計画書の揚げ足取りしかしない。
法人のほうが、まだまし。
857:デフォルトの名無しさん
08/04/30 00:11:53
URLﾘﾝｸ(www.atmarkit.co.jp)
まぁ技術力は要らないという人種ですから・・・
858:デフォルトの名無しさん
08/04/30 01:32:15
気持ちはわかるが
>>856
> うちら下請けには、すぐ工数削るのに、エンドユーザへは一切金額下げてない。
当たり前だろ。
859:デフォルトの名無しさん
08/04/30 01:53:51
だって企業名を盾に中間マージンを抜くのが仕事だもの。
みかかデータ。
860:デフォルトの名無しさん
08/04/30 20:18:37
結構数見てきたけどまともな奴いない。
というかいなくなるな、みかかは・・・
861:デフォルトの名無しさん
08/04/30 22:56:55
>>856
下請けなんてやるからいけない。
うちは10人ほどしかいない会社だが、元請しかやらないよ。
862:デフォルトの名無しさん
08/05/01 00:11:40
小さい会社だと数千人月とかの仕事はもらえないからなぁ
863:デフォルトの名無しさん
08/05/01 00:29:29
>>862
ちょｗ
10億前後ってことかよｗ
そりゃそうだろｗｗ
864:デフォルトの名無しさん
08/05/01 01:01:44
数千人月の案件は大手SIerが受注すればよろし
だがしかし数百人月の案件は中堅に譲るべし
中規模以下の案件まで大手が受注して下請けに出すから
業界がおかしくなるんじゃ
865:デフォルトの名無しさん
08/05/01 02:15:04
>>862
小さい会社がそんなの受けてどうすんの?
一人当たりの利益が同じならば大きい仕事でも小さい仕事でもかまわんだろ
866:デフォルトの名無しさん
08/05/01 02:47:00
マ板でする話をム板でしてるあたりがアレなんだよな
867:デフォルトの名無しさん
08/05/01 13:33:46
昨日の JJUG Cross Community Conference の、一番最後のひがさんのセッション。
URLﾘﾝｸ(www.java-users.jp)
まぁ内容的にはちょっと無理があったが、そのうちPowerPointも上記サイトで公開されるとのこと。
(スレ違いすみません)
868:デフォルトの名無しさん
08/05/01 20:27:47
>>867
というか、ひがタンの会社、ITゼネコンじゃないのか？ｗｗｗ
869:デフォルトの名無しさん
08/05/01 21:01:03
>>868
だから上司にはそういうタイトル名だとはいってないという記述があったはず
870:デフォルトの名無しさん
08/05/03 19:02:53
>>869
ひがは上司とか、わからない奴をだますことしか考えてないな。
871:デフォルトの名無しさん
08/05/15 00:00:55
329 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/13(火) 22:04:29
冷ややかな戦争勃発ｗ
URLﾘﾝｸ(d.hatena.ne.jp)
342 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 02:05:36
はぶ参入で抗争激化！さぁ、盛り上がってまいりました！
343 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 02:08:47
とりあえず、保存しといた。
URLﾘﾝｸ(s04.megalodon.jp)
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:デフォルトの名無しさん
08/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
よろしくお願いします。
URLﾘﾝｸ(ml.seasar.org)
873:デフォルトの名無しさん
08/05/17 11:23:37
関係ないだろ。
よそのスレでやれ。