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
関係ないだろ。
よそのスレでやれ。