Java⇔RDBのMapping-Frameworkを語るスレ Vol.5
6 :
デフォルトの名無しさん:2008/09/14(日) 19:42:58
Hibernateの、HQLを使用した、自然キーを持つテーブル(クラス)の
結合に関して質問したいんだけど、それってここでいいの?
すいませんあげてしまいました・・・ごめんなさい
新規の質問はあげるのが普通じゃね?
いいと思いますよ。
9 :
6 1/2:2008/09/15(月) 13:33:38
ありがとうございます。
それでは質問します。
EclipseとStruts2フレームワークを使用して、開発を行なっています。
Struts2に付属?していたHibernateを用いて、簡単なワークフローを実現する、
Webシステムを開発しようとしています。
申請テーブル
+ユーザID
+作成年月日
+申請種別
−承否認期限日
申請先テーブル
+ユーザID
+作成年月日
+申請種別
+申請先順番
−申請先ユーザID
−承否認状況
(テキストでの記述の方法がよく分からなかったため、+が主キー列、−が普通の列です。
外部参照等は設定しておりません。)
最低限の構造に絞った物ですが、上記のような構造のDBテーブルがありまして、
このテーブルを用いて「現在自分に来ている申請の、"承否認期限日"一覧を表示する」画面を
作成しようと思っています。
10 :
6 2/2:2008/09/15(月) 13:38:18
HQLでなく、SQLで実現するのであれば、下記のようなSQLが必要であると考えています。
SELECT A.承否認期限日
FROM 申請テーブル as A, 申請先テーブル as B
WHERE A.ユーザID = B.ユーザID
AND A.作成年月日 = B.作成年月日
AND A.申請種別 = B.申請種別
AND B.申請先ユーザID = '自分のユーザID'
これをStruts2のHibernateを用いて実現したく、現在、DBとマッピングされるクラスは、
申請テーブルを表すクラス、申請テーブルの主キーを表すクラス、
申請先テーブルを表すクラス、申請先テーブルの主キーを表すクラス
の4つがあります。
テーブルを表す2つのクラスには、主キーを表すクラスを格納するための
フィールドを作成済みです。
このクラス構成で、SQLをHQLに置き換えた処理を記述したいのですが、
結合するフィールドが別のクラスにあるため、どのように記述していいのか分かりません。
Hibernateを用いるのであれば、XML内に、結合に関する定義が必要であるような気がするのですが、
どのように記述すれば、別クラスにあるフィールドの結合の定義になるのかが分かりません。
XMLで、複合主キー(自然キー)を用いたクラス同士のフィールドの、
結合のための定義方法について、どなたかご教授願います。
また、どこか根本的に間違っている部分があれば、指摘を頂きたいです。
よろしくお願いします。
13 :
6:2008/09/15(月) 21:17:29
15 :
6:2008/09/15(月) 23:02:29
>>14 まじですか。
公式っぽいなぁとは思いつつ、確証持てなかったんですが・・・
ありがとうございます、自信を持って参考にします
>>5 これ使ったことあるん?
あるなら感想というか使い心地を聞きたいなあ
17 :
16:2008/09/16(火) 20:33:25
activeobjectsってHIBERNATEとかに比べると簡単だったよ。
ただトランザクションの宣言方法が独特だった気が…
あれー?
S2JDBCはー?
なにそれ
使えんの?
>>20 今の流行。俺の中でw
Hybernate
↓
S2Dao
↓
iBatis
↓
S2JDBC(今ここ)
その流れでS2JDBCにたどり着くっててところがおもろいが
4つの中でどれが一番覚え易かった?
いまはS2JDBCかなー
でもちゃんと規約作った方がよさげ。
自分で規約を作れないならS2Dao。
規約作れなくても楽がいいっていうならS2JDBC。
仕組み的にはiBatisが一番分かりやすいけど、
タグ覚えなきゃならないのとタグにクセがある部分があるのが
ちょっといやなところがある。
まあ、Seasar使えないならiBatisしかないけど。
Hybernateは無い。
S2JDBCやLINQみたいなものは良いんだけどさ〜。
でも、分かっている人達だけでやる時用っていう気はするんだよね。
スキルが色んな人達が集まっている環境で、最低限の品質を保とうとすると
結局DAOパターンに落ち着いてしまったり。
iBatisも3.0になって、interfaceベースでのConfigurationが出来るようになると
嬉しいかな?
そしてHibernateは無い。
Hybernateが無いのは同意
規約は無くても、作ってたら自然と規約っぽくなっちゃわない?
でも複数人でやるときは
やっぱS2Daoのほうがいらぬ心配しなくていいのか
Hybernateはないよな
たしかにそんなプロダクトはないな
無い理由は?
覚えること多すぎというのはわかる
あと、Hibernateな
開発や企画を押さえ込めるスーパーエンジニアががっちりドメインモデルを作って
仕切ってるような場合はhibernateはいいんだけど、そういうのはまずありえないから。
EclipseLinkは?
>>30 O/Rマッパの主力かと
EclipseとNetBeans、JDevの積極的なサポート
アプリケーションサーバーもGlassfishV3で標準になるし
Oracle製品も標準搭載してくるでしょ
なんだかんだいってもJPAはツールのサポートが一番優れてるから便利
標準APIは強いな
>>28 > あと、Hibernateな
>26はその意味。分かりにくいけどyは全角なんだぜ
S2JDBC、OpenJPA は、ともに JPA の実装のひとつという理解であってますか?
あと、ほかに JPA ができる実装として、(ググってキーワードだけ見つけたので実際に使ったことはないのですが)
を見つけました。
Hibernate + Hibernate Entity Manager
TopLink JPA
Hibernate Entity Manager を使えば、Hibernate を JPA チックに使えるってこと?
S2JDBCはJPAの実装じゃないよ
>>33 S2JDBCは違う。あれは見た目JPAに似ているが完全な独自。
>Hibernate Entity Manager を使えば、Hibernate を JPA チックに使えるってこと?
そういうこと。
Hibernateを採用した場合でも独自は出来るだけ使わずにJPAベースで開発して
どうしても必要なところのみHibernate依存を書くのが一番メンテ含めて効率が良い。
あとTopLink EssentialsがTopLinkをベースにJPA実装を作ったやつで
RI(参照実装)となっていた。これの後継がEclipseLinkになると思ってよい。
JPA2.0ではEclipseLinkがRIになる。
>>29 DB設計時にO/Rマッパーの機能・規約を意識しているかどうかは重要だけど
ドメインモデルを採用するかどうかは必須条件ではないよ
37 :
デフォルトの名無しさん:2008/10/09(木) 23:44:37
javax.persistenceのアノテーションでインデックス付けたいんですけど、
Hibernateの@Index見たいなのが無くて困ってます。
そう言う物?
>>37 Hibernate独自アノテーションはJPAにできないことのためにある
39 :
デフォルトの名無しさん:2008/10/10(金) 02:56:28
JavaPersistenceAPI(笑い)
JPAネットたかた(笑い)
(笑い)(笑)
>37
@Indexってなんのためにあるの?
禁書目録のためにある
44 :
デフォルトの名無しさん:2008/10/10(金) 20:48:12
禁書目録のためにある(笑)
45 :
デフォルトの名無しさん:2008/10/10(金) 21:05:56
>>38 そうだと思って@Index(name="xxxx")を一緒に付けても、
インデックスが作成される気配も無く・・・
persistence.xmlを使うと、Hibernateアノテーションは使えなくなるのかなと。
>>42 DBのいわゆるインデックスを作成する為に。
少なくともそう思ってます。
ORM側からDB生成するのはせいぜい最初だけだと思ってるけど、
定常的にORM側をメインに使ってる事例はどのくらいあるんだろ。
あぼーん
あぼーん
い……禁書目録
あぼーん
あぼーん
ところで、JPAのManyToOneのOne側のIdがnullなデータベースがあったらどうすればいいですか?
IDがNullだと・・?
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
60 :
デフォルトの名無しさん:2008/10/25(土) 20:23:47
なんかのアニメキャラなのか?
キモ・・・
あぼーん
あぼーん
あぼーん
なんか荒らされるようなことあったっけ?
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
すみません
Hibernate勉強中なのですが、Hibernate Reference Documentationの最初から戸惑ってます
最初の単純なアプリケーションをコピーして作っているのですが、動作しません
いきなり、slf4j関係で怒られます
エラーメッセージにあらわれたURLを参考にslf4j-simple-1.5.5.jar入れたら、とりあえず、slf4j関係は怒られなくなりました
しかし、さらにjava.lang.NoSuchFieldError: nameなるエラーメッセージが現れ動作しません
デバッガで追ったところ、発生箇所はnew Configuration()なのですが、何が悪いのかよくわかりません
現在、Configurationのソースコードを読み始めていますが、なにかアドバイスあればお願いいたします
Hibernateは3.3.1です
OSはWindowsXPSP2, jdkは6update7です
よろしくおねがいいたします
71 :
デフォルトの名無しさん:2008/10/29(水) 21:50:15
>>70 事故解決しました
ありがとうございました
事故解決ってなんだ
下請けにぶつけて賠償請求でもしたのか
あぼーん
あぼーん
なんかJavaって使ってるの基地外ばっかなのか?
>>43 あたりからなんか意味不明なんだけど
意味さえわかれば基地外ではないということが理解できるはずさ
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
>>70 同じ問題で悩んでいます。
どう解決したのか教えて下さいませ。
どう解決したのか教えてくれるとうれしいな
>>82から
>>70へのお願いなんだよ
84 :
70:2008/11/11(火) 18:54:13
Hibernateのバージョンを3.3.1から2.1.8に落としたらうまくいきました。
フォーーー!!
あぼーん
あぼーん
あぼーん
あぼーん
S2JDBC って Seasar と全く関係ないプロジェクトでも使えるんですか?
ちょっと質問が意味不明かもしれないですが…うまく言えないですが、
Seasar 系のものと一緒でなければ使えないのかどうか知りたいのですが。
名前からみてもらえればわかるとおり依存性あり
JPAのようにコンテナ非依存だったらよかったよね
S3の各種コンポーネントもSlim依存のようだし
SAStrutsとS2JDBCがDIコンテナ非依存だったら
SpringとかGuiceとかその他さまざまなところで使われた予感
何トンチンカンなこと言ってるんだ?
なんだS2JDBCってそうなのか。残念。
とある Java の インデックスアウトオブバウンズエクセプション
あぼーん
無能力情報処理技術者 レベル0(大半はこれに当てはまる。単なるおちこぼれ。ごくまれに例外がいる。)
低能力情報処理技術者 レベル1(多くの開発者が属する。パスポートでITの国に入国できる程度の力。)
異能力情報処理技術者 レベル2(レベル1に毛が生えた程度の力で、基本的な能力のみ有する。)
強能力情報処理技術者 レベル3(能力は今の貝発射程度。資格的には高度区分扱いされ始めるレベル。)
大能力情報処理技術者 レベル4(プロジェクトにおいて戦術的価値を見出せる程の力。)
超能力情報処理技術者 レベル5(日本のIT業界でもそれほど多くない。1人で1プロジェクトと対等に渡り合える程の力。)
絶対能力情報処理技術者レベル6(日本のITの動向に影響を与えるほどのスキルを有する者だけが到達可能。)
ttp://www.ipa.go.jp/jinzai/itss/
あぼーん
あぼーん
あぼーん
これってSeasarの人が荒らしてるの?
あぼーん
Seasarの中の人を怒らせると
おそろしいってことか・・・
あぼーん
あぼーん
関係ないの混じってるw
あぼーん
あぼーん
もうやめてください…(;-;)
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
114 :
デフォルトの名無しさん:2008/12/05(金) 00:39:54
質問です。
複数のスキーマがあり、プログラム起動時にアクセスするスキーマを動的に切り替えたい。
SCHEMA_01.TABLE_01
SCHEMA_02.TABLE_01
SCHEMA_03.TABLE_01
(TABLE_01のレイアウトは全て共通)
iBatis2.3.4で試してみたところ
<select id="getTABLE_01" parameterClass="java.util.Map" resultClass="examples.dto.TABLE_01">
SELECT * FROM $SCHEMA$.TABLE_01 WHERE ID = #ID#
</select>
HashMap map = new HashMap();
map.put("SCHEMA", "SCHEMA_01");
map.put("ID", "1");
TABLE_01 dto = (TABLE_01)sqlMap.queryForObject("getTABLE_01", map);
とすることで一応、目的を果たせました。
ですが、この方法ですと毎回HashmapにSCHEMAパラメータを指定する必要があり、
またparameterClassに自前クラスを指定したい場合などに困ったことになります。
sqlMap側でデフォルトスキーマを指定するようなパラメータがないか調べたのですが、見つかりませんでした。
もう少しスマートに行う方法はありませんでしょうか?
ちなみにHibernateでもアレコレやってみましたが、
こちらは動的に切り替える方法が全く分かりませんでした。
Hibernate EntityManager+Springで動的切り替えはやったことある
EntityManagerの委譲クラスを作って、メソッド呼び出しのタイミングで
スレッドローカルに保持しておいたユーザ情報を見て
利用するPersistenceContextを選択するというやり方をした
あぼーん
以外だ?以上だ?
>>114 iBatis + Spring の環境だけど、DataSource のサブクラスを自分で作って、
Spring が getConnection するときに、スレッドローカルなりに格納されてきたユーザ名に応じて
接続先の JDBC DB ユーザ名というを変える、というようなことをやっているよ。
SQL レベルで、
select * from スキーマ名.テーブル名
にはしたくない。
>>118 Connection時にDataSourceのユーザを切り替るということはコネクションプーリングを
考えないということでしょうか?
>>115のやり方もちょこっと調べてみましたが同様の考え方のように見受けられました。
(なにやら難しそうで読んだだけでは理解が追いつかなかった・・・)
でも確かに接続ユーザ自体を切り替えるほうが安全で
SQLでスキーマ名.テーブル名ってやっちゃうと、何かの弾みで
別スキーマのデータにアクセスできてしまうという危険がありますからね。
そもそもこのような使い方する場合はコネクションプーリングを考えないほうがいいのかな。
よくDB接続時の負荷が高いというのを見ますが、その辺は大丈夫なんでしょうか?
>>119 切り替える分のデータソースを予め定義しておいて、
そのDataSourceを使うiBatisなりHibernateなりのアプリレベルで切り替えればいい
言ってることが理解できないのなら、もうちょっとJavaのDBアクセス関連を勉強した方がいい
>>120 スキーマは動的に増えていくので、その数分データソースを
用意しておくというのは現実的じゃないんですよ。
なんせゼロからjavaでやるの初めてなんで、
おっしゃる通り勉強し直してきます・・・。
>>121 で、試行錯誤の末なんとか実現できそうです。
sqlMapConfig側で
<dataSource type="SIMPLE">
<property name="JDBC.Driver" value="org.postgresql.Driver"/>
<property name="JDBC.ConnectionURL" value="jdbc:postgresql://....."/>
<property name="JDBC.Username" value="${username}"/>
<property name="JDBC.Password" value="${password}"/>
</dataSource>
ソース側で
Properties props = new Properties();
props.setProperty("username", "hoge");
props.setProperty("password", "1234");
SqlMapClient sqlMap = SqlMapClientBuilder.buildSqlMapClient(reader, props);
とやることで指定したユーザで接続できました。
これを開始時に行って取得したsqlMapを使いまわせば実現できそうです。
色々と情報ありがとうございました。
スキーマ動的に増えるとか何かの冗談?
あぼーん
ORツールを導入するプロジェクトの規模ってどのくらいからが妥当ですか?
1人で開発する場合から妥当
>>123 スキーマ動的に増える設計のシステム保守してるよ。
案外冗談でもないんだな。これが。
むしろひとりだとORMつかってうまーの規模だな。
プロジェクトで ORM 導入を考えるときは、
便利だけど使いこなすのが難しいので、メンバーに使いこなせるかどうか
とか考えなければいけないけど、ひとりだと自分の好きなツールを使えるからいいね。
メンバーのスキルは期待できない。
SQLなら多少書ける。
っというのであれば、DBUtilsやiBatisあたりを使ってりゃいいんじゃね。
スキルが期待できない開発者はSQLもとんでもないのを書くことが多いw
ぶっちゃけオブジェクト指向よりSQLの方が簡単なので
ORMの説明してもSQLじゃないと出来ないとか言われるのが落ち
オブジェクト指向よりSQLのほうが簡単?マジ?
使う側の話だよね?
SQLとの比較ってことは、クラス設計ではなくて、誰かが作ったクラス使う場合だよね。
age
Entityクラスくらい誰でも作れるだろ
あぼーん
137 :
デフォルトの名無しさん:2008/12/11(木) 01:01:18
オレもDBからデータ引っ張るときはSQLで考える方が楽だと思う。
WHEREにORとかBETWEENとか必要で、
GROUP BYでMAXとらなきゃいけないケースが多いからかもしれないけど、
これをORMで、ってなったらゴメンナサイだわ。
group byって標準APIであるJPAにもあった気がするけど
GROUP BYでMAXはORMでも簡単じゃないか?
テーブル結合とかがかなり面倒って感じかな
ORMの場合最初に設計時に関連かいてるからね
FKつけないとかいうトンデモな場所だと使いにくい
逆にORM意識して規約に従ったDB設計やっていたら
結合がアホのように簡単になる
スキーマをいじれるときはORMで
いじれないときはSQL重視でやるのがいいと思う
SQLがある程度のレベル(ここが議論を呼ぶだろうが)で書ける人は、
ORMをウザく感じるのは事実だろうなぁ。
オブジェクト指向よりも数学の集合論の方が解りやすい。
まあ、スキーマが動的に増えるのは、あんま考えにくいんだが
そういうのは設計が悪いと言っても、今更なんだろう。
仮にそういうケースがあるなら漏れなら・・・
・本番環境用データソース
・テスト環境用データソース
・単体テスト用データソース
とデータソースを作っておいて、その先にテーブルのエイリアスを
入れとくか、ビューを作っておいて、ORM側であーだこーだしない様にするけど。
そういうのはORMやらアプリの仕事じゃないと思うし。
ただ変態的なスキーマな増え方だと逆にアプリでやるしかないんだろうけど・・・。
いやド新人でもSQLの方が楽だってよ
まあ、新人はSQLを学ぶべきだろう。
新人はORMを使う前にJDBCでゴリゴリとSQLでDB操作をするアプリを作ってみるものだろうなぁ。
今のORMって結局はSQLの知識がないと複雑な処理はできないからな
典型的なCRUD処理や単純に結合先と合わせて持ってくる程度の処理なら
知識がなくても作れないことも無いが、大抵は複雑なクエリ発行が必要になるものだし
逆にSQLさえ知っていれば、ORMのAPIがどんな処理をやろうとしているのか
おおよそ想像がつくようになる
更新する前提の読み込みがあるロングトランザクション系の処理の場合はORMは便利。
単にデータオブジェクトをこさえる目的だけの場合は微妙かな。
パフォーマンスが落ちてSQLチューニングが必要になった時点で行き詰まる
ロングトランザクション系の処理も正直ストアド(RPG,SQL,C,Java)上で実装した方が
ORM使うよりも楽だと感じるんだが・・・。
#とりあえずDB2だとそう感じる。
ちょろっとしたCRUD処理はORMの方が楽に書けるので、これはこれで便利だけどさー。
あぼーん
ORMはDTOの管理を軽減してくれるもの、統一的な扱い方を提供するもの、
と考えればそんなに問題はないと思うけどな。
つまり前提としてSQLを知っている人が楽をするために導入した、と。
別に両者とも併用できるわけだし、ゴリゴリ書いたほうがいいような場合は
そうやればよい。通常のUIにはORMだけで問題はないだろう。
JPAをみてると積極的にキャッシングするので、局所性がある場合パフォーマンスも悪くはない。
あれは元々EJB3の1仕様だからWebコンテナの上で動かすのはオマケだと考えると納得がいく。
あぼーん
DAOパターンを正しく実装するならJDOのがいいはずなんだけどね。
JPA使うと「EntityManagerこそがDAO」みたいになってしまう印象が。
DAOパターンを正しく実装する必要性が薄いということでは?
あぼーん
あぼーん
>>155 JPAとかはいわゆる現実解だと思うよ
厳密だけど面倒ってのがEJB2.1までのEJB+CMP+DTOになっちまうから
あぼーん
わっふるわっふる
162 :
デフォルトの名無しさん:2008/12/19(金) 22:02:29
ORというものを技術的には理解できるのだが、
それでもいまいち何に使うのかが理解できない。
テーブル構造からSQLとbeanを自動生成するとしてもだ、
テーブル単体に対してSQLを発行するわけじゃないよね?
業務の単位としての処理をどうやって自動生成するの?
手書きなの?
色んなテーブルのbeanをどんどんpersistしてやればいい。
flushするときにバッチアップデートするように処理される。
あとselectで取得したbeanはキャッシュされたりもするから速い。
SQL最適化以前にこの手のキャッシュで差が出る事も多い。
ただしORは1レコード1要素の制約にしばられるから、
横断的な更新ならupdate文を直接送らなきゃあかん。
そんなケースは少ないから大きな問題にはならんけど。
DBのテーブル定義をORMで定義されるクラス群に集約することにより
SQLだと繰り返し記述することになるテーブル構造部分や結合関連の記述を省略する
SQLの「繰り返し書くことになるめんどくさい部分」を極力ソースから省くのが目的
結合関連をEntityのメソッドで追えたり、関連Entityを追加できるようになるので
編集処理などにも向いていると思う
後は楽観ロックなどが標準装備されているFWが多いので、
こういった処理を独自で実装する必要がない
テーブル定義をマッピングする性質上、
テーブル構成と業務上のモデルにあまりにも隔たりが大きく
ビューを多用したりしているようなシステムには向かない
業務単位としてのクエリは、JPAだとJPQLを使ったり、2.0で追加されるCriteriaを使う
同様のことをS2JDBCなどは、APIを使ってなるべくタイプセーフに行えるようにしている
HQL覚えるとかいやなんだけど
SQL方言の一つだと思えばどってことない
SQLの方言を吸収するためにORMかますのに本末転倒すぎる
一つの方言で全部済むならそれでいいじゃん
Javaのオブジェクト指向とインピーダンス合わせるために使うのにHQLとか
Hibernateの設計が悪い。
インピーダンスwwww
あぼーん
>>167 方言吸収が目的というより、.netのLINQと一緒で
オブジェクトに対するクエリ発行が目的だと思う
SQLの検索系機能自体は強力だから、このメリットを活かしたままで
マッピングしたEntityをベースに使う為のもの
それでもSQLでないクエリを書くのが嫌なら、Criteria系を試してみるといい
ふと気づいたが、JPAとかじゃなくてJDBC4.0でよくね?
JDBCはSQLExceptionの処理が面倒だからなぁ
JPAの例外は全てRuntimeExceptionになっているから
AOP等で一気に例外処理の設定がしやすい
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
182 :
デフォルトの名無しさん:2008/12/30(火) 23:40:55
183 :
デフォルトの名無しさん:2008/12/30(火) 23:42:01
あぼーん
あぼーん
l:.:.:*ゞx : : (: : `ヽ、: : :.ヽ_: : ヽ、} l
ト- ': : :._ > ― f' ¨下. ̄.ト、 ̄` ヽ、 }
ノー'´ ̄ / l. ,ィ ! } ヽ._レ}-ir' i ,>
∠ィ 「` 7 十ァ-j、/l イ! ヘlニj_ハ. ハ | !
/ i .i ,' ,ィt7示x jノ j' '行h;} jノ!| ソ .l HYBERNATE使ってる人は
{ ハノV / ト'じ_;:} 弋tタ ! !i i | お正月だしちょっと人生考えたほうがいいかもしれないね!
ゝ} | 乂クソ 、 、、 ! i.| ', !
,'-| ト, 、、 ! ! l ', !
. 人ニ! | - 、 / |l ',. i
, ``| |ヽ、 '´ イ.| !| ヘ V
,' i ! |. ` 、 r' ! | | .| 、. ヽ\
,' | i| |`丶 __ _フ ´) V || ! .| i ヽ
,' レ'T. | / \_l| |__| ', /
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
ただのクソスレか
あぼーん
あぼーん
結構売れてんだな
あぼーん
197 :
デフォルトの名無しさん:2009/01/21(水) 18:31:08
Java + DB に詳しい方がいると思って質問です。
Java から Oracle に対して大量にデータ更新をする処理を何度も行うするバッチがあります。
(Spring + iBatis、Java 5、Oracle 10i)
・一度のメソッドの中で、5000件ぐらい、insert したり update する
・そういうメソッドを 30 回ぐらい呼ぶ
いまは、ふつうに for 文で対象件数分回して、そのなかで insert や update を実行しています。
こういった処理を高速化するにはどうしたらいいでしょうか?
・JDBC には addBatch() 方式があり、iBatis 経由で組み込んでちょっと実験してみたが、
気持ち早くなった気がするものの、あまり目立った効果を感じない
質問1:
JDBC addBatch() 方式は、パフォーマンスアップとして有効か?
JDBC ドライバの実装次第というのをどこかでみたが、Oracle JDBC ドライバの場合は?
質問2:
大量データの投入、更新にストアド化は有効か?
ストアドが有効な場面は、何度かSQLを呼び、結果を Java 側に fetch してきて Java 側で編集して RDB に書き戻すような場合だと
思っていますが、単に大量データを投入するような場合でも有効でしょうか。
単純な insert / update するような ストアド を RDB にロードしておき、Java からパラメータだけを配列渡しにする、みたいな。
他にも何かいいアイデアがあれば教えてください。
>>197 JavaでCSV(TSV)ファイルを作成してOracleにインポート
PreparedStatementのキャッシュが効いてないとか。
リレーション具合にも夜から一概に言えない。
CSV読み込みで高速処理できるなら。トランザクションで一括処理すれば同程度には出来るかも。
そのへんはDBAのコンサルが詳しい。
あぼーん
>>197 public void addHoge(final List a)throws DataAccessException{
/* unDivide */
getSqlMapClientTemplate().execute(new SqlMapClientCallback() {
public Object doInSqlMapClient(SqlMapExecutor executor) throws SQLException {
Iterator it = a.iterator();
executor.startBatch();
while (it.hasNext()) {
String str = (String)it.next();
executor.insert("insert_sql", str);
}
int rowsaffected = executor.executeBatch();
return new Integer(rowsaffected);
}
});
}
これ以上はストアド化する他ないかな?
DBがOracleならストアド化しとけばいいんじゃない?
あぼーん
あぼーん
あぼーん
206 :
デフォルトの名無しさん:2009/01/29(木) 19:52:08
ちょっと教えてもらいたいんだけど
整合性のとれていないDB(それがそもそも間違ってるんだが…)で
@ManyToOne の参照先エンティティが存在しなかった場合に
エンティティを自動的に生成するなりして例外を発生させない処理って
エンティティクラス内だけで実装可能?
整合性の取れてるまともなDBを作ってそっちをマスターにしたら?
今までの整合性無いDBへのリレーション維持の要求にはバッチ処理とかで旧システム互換取ればよくね? リアルタイムでもいいけど。
>>206 そういう外部キー制約に関する整合性が取れてないDBと
JPAとの相性はすこぶる悪い
他のORM使った方がいいと思う
Hibernateの場合、一応例外を発生させないような設定オプションはあるけど
それでも、できるだけ採用しない方が無難
今ウチで保守をやってるシステムだと、
・各テーブルの末尾に「削除フラグ」列があって、
ここに 1 が入っている行はオンライン処理対象外とし、
日次夜間バッチでDELETEする
・マスタ系のテーブルやコード・区分テーブルには
「適用開始年月日」「適用終了年月日」列があって、
すでに無効になったデータも履歴として管理していて、
現在有効なデータを取得する条件として
「開始日 <= システム日付」かつ「終了日 >= システム日付」
を指定している
っていう処理があるのね。
で、こういう処理ってウチだけじゃなくて、他でもやってると思うんだけど、
そういった汎用的な処理を簡素化してくれる機能付きのO/Rマッパーって無いかな?
「特に指定しなければ、デフォルトで論理削除されてないデータのみを取得する」とか
「特に指定しなければ、デフォルトで現在有効なデータを取得する」とか、
O/Rマッパーが統一的に面倒見てくれると嬉しいんだけど、どうなんだろ?
それともそういうのって、O/Rマッピングを超えてるのかなぁ……
誤:それともそういうのって、O/Rマッピングを超えてるのかなぁ……
正:それともそういうのって、「O/Rマッピング」の範疇を超えてるのかなぁ……
>>210 DBFluteってのがそこら辺の面倒みてくれたキガス
>>210 COBOL系のシステムで見られる手法でRDBとは相性が悪いが、
底辺の現場で多く使われている。
たいていキーや関連が破綻している。
>>210 ウチはサマリの集計処理とか、要らないデータの削除処理がストアド(pl/pgSQL)で動いてますね。
基本はストアドで、それを1時間に1回、あるいは1ヶ月に1回バッチで呼び出す感じかな?
SpringFramework + iBATIS + PostgreSQL(pl/pgSQL)が一番保守しやすいっス。
他の処理も全部ストアド化しておけば良かったと後悔してますがね。orz
215 :
210:2009/01/31(土) 21:05:08
>>212 サンクス!
ドキュメントを斜め読みした限りでは良い感触かも。
ちょっとexampledb試してくる。
>>214 サンクス!
ウチのシステムはテーブル名に2バイト文字が使われてる等々、
>>213の言うとおりの残念設計だったのでiBatisがダメだったんだけど、
今見たら日本語通るようになってたので、ちょっと調べてみるよ。
ただ、どっちかというと、バッチよりオンライン処理の実装でラクをしたかったり。
10年以上改修を繰り返した結果、特にオン側のコードでスパゲティ化が著しいもんで……
メンテ用と本番用のフレームワークで分けて、遮蔽しとけば済む話では?
履歴系とリアルタイム系でシステム分けたい感じだが。
あぼーん
218 :
デフォルトの名無しさん:2009/02/05(木) 03:09:14
自分は iBatis はそこそこ経験があり、
Hibernate は、簡単なシステムで経験がある程度です(複雑なjoinが必要なかった)
今度 Spring + Hibernate + JPA のサンプルを作ることになり、
http://www.amazon.co.jp/dp/4839925941 の本を見ながらやりはじめました。
この本の P.87 を見ると「EntityManager に更新に相当するメソッドはない」とありますが、
JPA でレコードを更新するときは、必ず一度 select しておかないといけないのでしょうか?
DB を更新する際に、一度 select せず、いきなり update 文で一括更新したいこととかあると思いますが、
----------------------------
例:
年度の締め処理において、「契約状態フラグ = "契約済み"」 となっているレコードを「締め済みフラグ = "締め済み"」にする。
SQL の例:
update 契約情報 set 締め済みフラグ = '締め済み'
where 契約状態フラグ = '契約済み'
----------------------------
219 :
218:2009/02/05(木) 03:10:16
(続き)
こういう場合は、以下の3択でしょうか(他にあれば指摘してください)
(1)対象データを全部 select してきて、for 文でエンティティに更新したい値をセットして反映させる
(2)JPQLか、
(3)ネイティブQuery
(1)だと大量データの時にパフォーマンスで問題がありそう。
(3)のネイティブQuery だと、JPA が持っているキャッシュとDBのズレが生じるというデメリットがある
とどこかで読んだのですが、この認識はあってますか?
(2)のJPQLだと、ネイティブQuery と同じように集合演算的に扱え、かつ JPA が持っているキャッシュと同期がとれると理解しています。
SQL を避けるために O/R マッパーを使っているのに、String で SQL モドキの言語を生成するのはイヤですが・・・
結局 データを集合的に扱いたければ、JPA や Hibernate のような O/R マッパは向かない、ということになるのかな。
JPQL使ってもキャッシュと同期は保証されない
ただし自分でEntityManager#flush()することができる
221 :
デフォルトの名無しさん:2009/02/05(木) 03:22:53
while(1)
{
wakeup;
static int day;
int time = wakeuptime();
while(1)
{
2ch;
if(time == Daytime())
{
lunch;
};
if(time == nighttime())
{
supper;
};
if( time == sleeptime();)
{
break;
}
time++;
}
day++;
sleep;
}
こんな毎日、無限ループって怖いよな;;
>>221 なんか1日が終わらない気がするけどどうでもいいや
EclipseLink関連のドキュメントで良い奴ありますか?
公式のExampleが1.0.2で動かないので、1.0.1で試してみたら動く、とか、
適当も良いところなんですが。。。
EclipseLink 1.1ってなかなか出ないね
225 :
デフォルトの名無しさん:2009/03/12(木) 16:53:18
EclipseLink 1.1age
PreparedStatementのキャッシュをコネクションを超えてプール出来ないものかねぇ。
DB側ではセッションとかも浪費してると思うと何だかね。(俺の知識が古い?)
JDBCにPreparedStatementの構文でストアド登録できる機能みたいなのが欲しい。
まあこんな機能はチラシの裏すぎるとは思うが。
_.. -――- ._
./ ,―――‐- ._` .
/) ./ / / ``\
///)ィ7T.フ厂 ̄`フi ‐-_ |〉. _人人人人人人人人人人人人人人_
/,.=゙''"/ フl/_×// |ハハl .ト、> 細かいことはいいんだよ!! <
/ i f ,.r='"-‐'つイ._T_i` .r≦lハ!|`` ^^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^ ̄
/ / _,.-‐'~| |'弋..!ノ i'+!l |
/ ,i ,二ニ⊃l |' ' ' ,‐- ..__゙ー' .!l .|
/ ノ i l゙フ..,!l .ト、 l `,! .ハ.!
,イ「ト、 ,! ,!|.../_| |l: > .ヽ.. ィ <l l|
/ iトヾヽ_/ ィ"\. | | \ \ー'/ ./ ,,;:`:;'゙
あぼーん
あぼーん
あぼーん
あぼーん
233 :
デフォルトの名無しさん:2009/04/12(日) 09:25:13
hibernateの公式いつまでメンテナンスしてるんだ…
もう3日目くらいだぞ
235 :
デフォルトの名無しさん:2009/05/18(月) 17:56:28
>>101 Z
z
z
<⌒/ヽ-、___
/<_/____/
 ̄ ̄ ̄ ̄ ̄ ̄ ̄
Hibernate について質問させて下さい。
(Hibernate バージョンは 3.2.5GA、DB は MySQL 5.0 を使用しています)
DetachedCriteria で条件分岐(case 式) を使うことはできますでしょうか?
以下のようなテーブルにおいて、
id | nameOfferer | nameOfferee
------------------------------
1 | foo | bar
2 | aho | foo
3 | hoge | baka
4 | baka | foo
「nameOfferer か nameOfferee のどちらかに
foo が含まれる箇所を抽出し、foo でない方の名前を使って昇順で
ソートされた行を抽出する」、という処理を行い、
aho
baka
bar
という結果を抽出したいのです。
HQL では以下のように記述し、動作することを確認しました。
select (case when nameOfferer=:nameUser then nameOfferee else nameOfferer end)
from FriendImpl where (nameOfferer=:nameUser or nameOfferee=:nameUser)
order by (case when nameUserOfferer=:nameUser then nameOfferee else nameOfferer end) asc
(nameUser には Query#setParameter() で "foo" をセットしています)
これと同様の処理を DetachedCriteria で書きたいのですが、case 式を使う方法が
リファレンス・ APIDOC を一通り見てもわかりませんでした。
どなたかご存知でしたら教えて頂ければ幸いです。
教えを請うのに例で baka とか aho を出すことはないだろうよ
238 :
236:2009/06/02(火) 12:47:07
>>237 そんなところをツッコまれるという発想はありませんでした…。申し訳ありません。
あぼーん
240 :
デフォルトの名無しさん:2009/06/27(土) 21:12:23
>>101 サテト
∧∧
(・ω・ )
_| ⊃/(__
/ ヽ-(___/
 ̄ ̄ ̄ ̄ ̄ ̄
「HYBERNATE使ってみたらどうですかね?」
と発言したら誰も知らなかった現実
ていうかO/Rマッパーという言葉すら通じなかった
もうやだこの現場
まぁ必要を感じないんだったらしょうがないよね。
実際そんなもん使わなくても開発はできる訳だし。
オブジェクト指向にたどり着けない香具師が、オブジェクト指向のメリットを感じるのは無理。
多くはコボルをjavaでの焼き直しに過ぎない。
業務でハイバネは無いな。責任誰が取るの? 提案者がバグもサポートも遣るよね。言い出しっぺだし。
>業務でハイバネは無いな。責任誰が取るの? 提案者がバグもサポートも遣るよね。言い出しっぺだし。
業務でapacheはないな。うんぬん
と、言ってるのと同じにしか聞こえない。
ハイバネって言ってる時点で・・・
アパチは鯖OSならサポート有るよ。
ハイバーネートはJBossでサポートないか?
アパッチぐらいならサポートあるけど、ボスは無理だろう。
Red Hat がサポート売ってるだろ。
ドメインモデルを組めない現場や、組むほどでもない業務ならHybernateは必要ないね。
iBatisでも使ってトランザクションスクリプトでやったほうがいい。
ボスのサポート契約するくらいなら、商用マッパー使ったほうがwww
商用マッパって例えば?
EclipseLink(TopLink)とかじゃね?わかんないけど多分有償サポートあると思うよ。
254 :
デフォルトの名無しさん:2009/07/02(木) 18:03:49
その手の無料ソフトのためのサポートコストと、有料ソフトの保守契約コスト考えたら?
あぼーん
SRAとかがやってくれりゃ安くで済みそうなのにな
ところで1期観てなくても観るべきか?
あぼーん
シャキーン!!
∧ ∧∩
(〃・ω・)オハヨウ
⊂ ノ
(つノ
(ノ
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
いつのまにかあぼーんになってるwww
あぼーん
あぼーん
あぼーん
270 :
デフォルトの名無しさん:2009/09/12(土) 18:47:06
ここ数ヶ月変なのに荒らされているが、このスレは2,3年前までは、
けっこう勉強になる良スレだったのになぁ
今日 Seasar カンファレンス行ってきた
中村さんの doma 聞いてきた
APT を使って Interface から Dao の具象クラスを生成するということで
おもしろそう
doma は単体でも使えるし、他の DI コンテナからも使えるようになっている。
ダウンロードしていじってみることにした
あぼーん
>>270 Interfaceは手書き?
定義書みたいなの書いてそこから生成とか?
273 :
270:2009/09/14(月) 13:40:17
>>272 手書きです。定義書みたいなのから生成、というのは触れられていませんでした。
そこらへんは S2Dao、S2JDBC といっしょです。
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
いい加減にしろよ
スレ違いかつ板違いだろうが
今期じゃないけど、またネギま来るみたいね。
まったくおまいらときたらw
しかし今更話題になりそうなO/Rマッパーなんて・・・Domaくらい?apt使ってるって以外真新しさはないけど
LINQみたいにソースに直接クエリ書いてコンパイルチェックもできたらいいのに
それ後のメンテ大変だけどなw
そうか?
コンパイラがチェックしてくれるならメンテが大変ってこともないだろう
リファクタリングもできるだろうし、むしろ楽になるかも
SeasarのS2JDBCってLINQみたいなのを目指してたんかな
コンパイラがSQLのチューニングしてくれる訳でもないし。
せいぜい型チェック程度でしょ。
シーサーは正直やっつけだと思うよ。無茶な仕様だったけどお金取れたから作ってみた的な。
>>288 意味が分からんな
コンパイラがチューニングしてくれないとメンテが大変になるのか?なんで?
SQLが別ファイルになっててもチューニングの手間は変わらんだろ
複数のSQLを1回にまとめたりその逆だったりしたらソースにSQL書いてある方が
メンテも楽そうだけどな
どの程度の規模のを想定してるか知らんがソースにSQLとかないわ
>>290 なんだ、まともに理由も書けないのか
ソースにSQLつっても文字列で埋め込む話をしてるわけじゃないのは分かってるよな?
単にクエリ埋め込んでコンパイラチェックするだけが目的なら
SQL文を別ファイルにしてSQLサポートするIDEでチェックするのとあまり変わらないけど
LINQはメソッド形式と使い分けられるから、クエリをカッコで囲んで
どこからでもCriteria的な書き方を混ぜられるのが強みだな
Javaだと言語でのサポートがないから、
S2JDBCやJPA2がやってる型セーフなCriteriaが、似たようなことやれる限界っぽいけど
JDK1.1の頃からSQLJというものがあってだな
といいたいところだがLINQと違ってSQLは静的にしか扱えないから
(動的にしたければ文字列w)勝負にならんのよね
ソースにSQL書くと何か問題あるの?
そうそう。ソースファイルに静的にプログラムコード書くと、コンパイルしないとメンテできないから、
外部ファイルにコード書いて、それ読み込んで実行するようにしなきゃ。
それなんてインタプリタw
つまり
>>285はコンパイラ型の言語はメンテできないと主張してるわけか
糞だな
永続化データの設計は、ロジックとは異なる要件/異なる責任元において設計され、
また変更される可能性があるので、プログラムコードとは分離すべき。
微妙に違う設計のDBに同じプログラムを適用するケースもあるかもしれないし、
DB側の設計変更の度にコードの修正・リコンパイルを実施するなんてナンセンスだ。
。。。という思想に基づいた発言だと思われ。
実際に問題となるほどそういうケースが発生するかどうかは知らん。
DBとロジックの設計は極力分離されるべき、という方針については俺的に同意できる。
あと、安易にコード修正を許すと、問合せ以外のロジックも見えちゃう&弄れちゃうから
気持ち悪い、というのも解らんでもない。
Javaにはヒアドキュメントがないから、ソースに埋め込んだSQLを見やすくしようとすると、
行ごとにダブルクォーテーションでくくって連結する必要がある。
ヒアドキュメントがあって、SQL部分だけをコピペして動作確認できるような言語なら、
ソースに組み込んであっても、問題が無いと思う。
コンパイルが云々に関しては、SQL修正してソース修正しなかったらテストしないのか?って言いたい。
どっちにしろ同じテストするんだから一緒だし、同じテストですまないなら、そこに問題がある。
テストは開発環境無くてもできるっしょ
>>299 AntやMavenでテスト流す場合でもコンパイル一緒にするだろ
上記のような思想に基づいてSQLを外部ファイルに外だししたシステムがあったけど、
何かの改修でSQLファイルだけいじったら、SQL側に不具合があって、システム止まって怒られてた。
ちゃんとテストしろとゆいたいですな。
OODB使えば、全て解決だぜ!
OODBにもOQLという問い合わせ言語があってだな・・・
あぼーん
あぼーん
あぼーん
あぼーん
せっかくまともな流れになってたのにまた出てきたのか池沼
氏ねよ
アニメ見てないなんて友達居なさそうだなw
>>310 見てるか見てないかじゃない、ここでする話じゃないんだよ
スレタイも読めないのか?
カルシウムの足らなさそうなのがいるなw
何を言おうがスレ違い・板違いを正当化はできねーんだよ
消えろ屑
目的は端から嫌がらせなので諭すだけ無駄
だが放置しといたら調子に乗って1年も居座りやがったからな
削除依頼してる人や管理人に迷惑かけやがって糞野郎が
316 :
デフォルトの名無しさん:2009/10/03(土) 22:30:55
あぼーん
あぼーん
あぼーん
あぼーん
321 :
デフォルトの名無しさん:2009/10/08(木) 19:52:59
質問です。hibernateでhbm2ddlを使ってテーブル作成をしているのですが、
外部キーの名前がFK0123456789ABCDEFのような名前として生成されてしまいます。
hbmファイルで外部キーの名前を指定する方法はありませんか?
>>321 <many-to-one>のcolumn属性または<column>のname属性
323 :
321:2009/10/09(金) 16:53:25
>>322 それはフィールド名ですよね?
でも自己解決しました。many-to-oneのforeign-key属性でした。
ありがとうございました。
>>323 フィールド名は<many-to-one>のname属性
column属性は公式のドキュメントによると
column (optional): the name of the foreign key column. This can also be specified by nested <column> element(s).
となってる
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
削除依頼したほうが早いかと・・・
削除ってかアク禁してもらえないの?
んでプロバイダから自宅に連絡行くようなやつ
ここまで執拗に荒らしに来るのはなんでかね。愉快犯?
ここ見始めたの最近なんだけど、過去になんかあったん?
>>334 同じく。ネタ的にDB板の方があってるだろうに、なぜかこのスレにいるんだよな?
いや、DB板見てないので、実はそっちにも出没してるのかもしれないが。
336 :
デフォルトの名無しさん:2009/10/17(土) 12:59:03
hibernate = JPA ?
337 :
デフォルトの名無しさん:2009/10/17(土) 13:09:27
JPQLからDAOクラスと入力DTOを出力DTOを自動生成するツール作りたいけどなんかよさげな方法ないかなー
>>336 Hibernate本体は違う。
JPAのインターフェースを持たせたのがHibernate EntityManager。
Hibernate独自のAPIは補助的に使う程度で、
あくまでもJPAのインターフェースで開発するのが主流。
>>337 JPA使ってるならDAOは必要ないのでは?
DTOはselect New使いたい場合ということ?
あぼーん
JPAって再帰問い合わせ(connectbyとかwith recursiveだっけ?)には対応してる?
メジャーなRDBMSはMySQL以外は対応してるから、パフォーマンス問題はなさそうだよな。
H2databaseとかは逐次呼び出しである程度遅くなってもいいし。
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
いつまでスレ違いの話題を続ける気だ。
幼稚すぎる。
1年以上に渡って黙々と嫌がらせを続けてるんだし、言うだけ無駄。
しかし、この凄まじい執念は何だろうね。
ORマッパに親でも殺されたんだろうか。怖ええ。
iBatisってあまり使われてないのかな?
今はJPA一色?
おれはs2jdbc
iBatisはSQL用意するのがめんどくさい。
型安全じゃなくて神経使うし。
確かにS2JDBCは便利だけど、
S2JDBCってS2コンテナが必要だよね。
DIコンテナがSpringしか使えない場合はどうするんだろうか。
やっぱりHibernateとかToplinkなの?
実績ではspring+hibernateが多いだろうね。
ぶっちゃけdiコンテナ自体、話にあがるほど採用されてないようにも思うけど。
個人的にはspringだったらibatisの組み合わせでいきたいかな。
やっぱりS2JDBCは便利すぎるわ。
DBFluteが気になっているけど、あんまり使われてないかな。
iBatisは仕組みがシンプルな分気楽に使い始める事ができるのがいいやね。
Hibernateは覚える事多いのと、融通が利かないのが困り者。
そもそも楽がしたくてフレームワーク導入したのに、諸々面倒が多い気がする。
s2は正直食わず嫌いなんだよな。
なんか国産フレームワークってだけでちょっと敬遠しちゃう。
S2のSmart Deployはかなり開発効率あがるよ。
O/R Mapping関係なくてスマンが。
iBatisはXMLファイル作らないといけないのか。
Domaは、どうでしょうか
どうもこうも…
まだHibernateが理解出来る事なんて条件の案件有るしなあ。仕様決めた香具師アフォ過ぎ。
s2は将来にわたってメンテされる保証が無いので却下。
長期運用システムだと商用サポート必須。
長期運用システムだとJSP/Servletのみで作るのが良い
なんでサポートなんているの??
作った時点できちんとテストして問題なければサポート
なんているの?
日本の業界の悪癖だから仕方ないな。
テストはバグを減らせるが、ゼロにはできない。
当然それはそうだけど、商用なら絶対直してくれるなんて
保証あるの?
まぁサポートなんて受けた事ないから知らないけど、
そもそもそんな根本的なバグにぶち当たった事がない…。
要は誰に責任を押し付けるかでしょうね。
仮にそこで「いやうちのフレームワークじゃないんで…」とか
言い訳したって、「いやいや、それを推したのはおたくでしょ」ってな
事にならないですかね?
バグに限った話じゃなく、外製ライブラリのトラブルシュートで
無駄な時間を食うぐらいなら、サポート買った方が断然安いし早い。
少なくとも一般的な開発レートで計算すると、そういう判断に
ならざるを得ないと思うんだけど。
自分たちで作ってテストするコストより、
よそから製品を買って年間保守サポートを想定運用年数分払う方が
安くあがる可能性もあるしね。
あと、障害が起きたときにログさえ取っておけば、
その後の対応を他社に丸投げできる分、保守開発要員をほかの案件に
投入できるという実務上のメリットもある。もちろんサポートから
「仕様です(直しません)」と言われた場合は、責任を持って代替案を
提示しなければならないことは、頭の片隅に入れておく必要はあるけど。
5年前のシステムで問題出たから調べてくれって言われて対応出来るならサポート不要だと思うよ。
漏れは面倒だから商用サポート契約しちゃうけど。
仕様ですと言われたら、商用サポート切って乗り換えを提案でだいたいうまく予算取れる。
だいたい自分たちで解決しちゃったら、予算取れないじゃん。
無料ソフト使ってシステム作って予算0でじり貧になるのは、自分で何でも解決しちゃうから。システムは金が掛かると認識させてちゃんと予算取りするのも生き残りに必要。
そういう政治的な事情以前に、実際に自分たちで手を動かして解決する方が
金掛かると思うんだけど?
レート×調査・対策にかかる時間で天秤に掛けると、サポート契約って格安だよ。
もちろん「トラブルは起こらない」という楽観的予測は論外として。
何かつまんない業界だ
そんなもんだよ
>システムは金が掛かると認識させてちゃんと予算取りするのも生き残りに必要。
言いたい事は分かるけど、そのうち中身がバレて生き残れなくなるに10票
根本的に、そもそもROIに合っていなければシステム開発業なんて
衰退の道を辿る運命じゃないかね。
そしてROIに合わせるための無理矢理の工数設定→デスマーチ。
…御愁傷様です。
いつまでスレ違いの話題を続ける気だ。
幼稚すぎる。
1年以上に渡って黙々と嫌がらせを続けてるんだし、言うだけ無駄。
しかし、この凄まじい執念は何だろうね。
ORマッパに親でも殺されたんだろうか。怖ええ。
開発目的の中心にエネルギーを集約するから仕事に付加価値が付くのであって、
何でも自分たちでやりたい、なんてのは単に開発者のエゴなんだよ。
餅は餅屋、プロがやった方が安くて早い。
面白そうだから、個人的に興味があるから、なんて理由はビジネス的にNGだよね。
そういうのは業務時間外にやっとくれ、って話になっちゃう。
>>386 いいじゃん別に。
よっぽど他に話したい事があるんなら別だが。
なんか話題あんの?
あと何か勘違いしてる様だけど俺はつい先日このスレに来たばっかり。
1年以上とか意味が分からん。
>>388 俺は開発目的を考えろという部分には全然異論ないですよ。
ただ、サポートが必要という意味がいまいちよく分からなかった
だけです。まぁ、それが責任の位置づけとか問題を丸投げできるとか、
そういう事に対する価値だとしたら、分からなくもないです。
ただ、実体のない予算取りみたいな意味なら全く同意できませんね。
それは、そのうち絶対バレるし、業界全体のためにもならない。
根本的にビジネスモデルがおかしくなってる証拠だし。
>>389 それはもう少し前のレスのコピペだよ。
もう少し前読むと関係ないアニメの話してる奴がいるの。
>389
サポート無しじゃ問題解決に余計な金と時間が掛かるケースが多い、というだけの話。
ノウハウを金で買うと思えば良い。
フレームワークの仕様(バッドノウハウ含め)を熟知したエンジニアを安定して確保するなんて
非現実的過ぎる。
自分の所のシステムだけじゃ開発ノウハウ堪らないしね。
あちこちで使われてる商用フレームワークだからこそノウハウ詰まってるしバグもみんなで潰してメリット傍受出来る。商用フレームワークの開発エンジニアの生活を保守契約払って支えてるから、そのエンジニアがオープンソースの成果物を無料で配布出来たりする訳で。
無料だからという理由でオープンソース採用しちゃったら、エンジニアが飯喰えなく成るよ。それが対費用効果的にビジネスモデルとして正しくても、エンジニアが絶滅する道を選ぶ事は無い。
ちゃんと価値有るものには対価を払うからこそ、エンジニアの価値が維持され、生活が安定してオープンソースとかの無料配布で金にならないお遊びが可能な訳で。
そういえば、O/Rマッパーで商用サポートがあるのって、
Hibernate以外に何かあったっけ?
OpenJPAとToplinkもサポートあるな
そうなると利害無視の自宅警備員プログラマこそ、真の恐怖だな。
利害関係なくすごいものを作る→本職プログラマあぼーん
そんな得体の知れないシステムが金になるとは思えないので影響なし
Apacheは?
Tomcatは?
いくらなんでもApacheやTomcatの開発者に失礼
東方キャラ
ごめんなさい、誤爆しました
東方キャラ
あぼーん
RailsのActiveRecordみたいのないの?
404 :
デフォルトの名無しさん:2009/12/05(土) 00:44:06
>>403 ActiveObject というのを以前見たことがある。
でも Rails やったことがある人ならわかると思うけど、
ActiveRecord の便利なのは、method missing による動的finder だと思うので、
Java だと限界があるのではないかな。
ActiveObject の使用例を少し見て、やっぱむりがあると思った。
あぼーん
EE6でJPA2.0になるみたいだけど、そんなに変わるんだろうか。
>>406 JPA 2.0 で、Hibernate みたいな criteria みたいなのをサポート、というのをどこかで聞いた。
キーワードもうろ覚えなので間違ってたらすみません。
Java Persistence Criteria API
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
ココハダレ?ワタシハドコ?
∧ ∧ ∧ ∧
(゚Д゚,,三,,゚Д゚)
/ |
(,,_/
/
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
え???
なんだここ?
異次元に迷い込んだようなスレ違い書き込みがあるんだけど、なんだここ?
ところでiBatisってあんまり人気が無いのかな?
SQLが柔軟に書けるってところでかなり惹かれてるんだけど。
今担当しているシステムのDBが巨大かつ複雑すぎて、
Oracleの神みたいな人がスーパーSQLを書かないと
パフォーマンスが出ないような処理もある恐竜システムになっていてね・・・
以前S2Dao使っていてHibernateとかJPAもさっくり見てみたけど、
ああいうのってSQLのチューニング的なこと無理っすよね?
(要はそういうシステムをターゲットにしていない)
生のSQLも使えるんじゃないの
生のSQLが使えるなら生のSQLだけで作ったほうがいいな
iBatis、別に人気ないわけじゃなく、けっこう使っているところ多いと思うよ
おれがアサインされるプロジェクトでは、Hibernate や JPA などの ORマッパーだと
n+1 問題等でうまくいかないことがおおいため、うちの部署はたいてい iBatis を使うことが多い。
(自分が Hibernate を使いこなせてないのもあると思いますが)
Java 屋ではなく DBA によるSQL チューニングするときも、iBais の XML を直すだけで
すむことも多いしね。
iBatis も目新しい情報はないが、サイトを見ると ibatis 3 というのが開発中なんだな。
Java5 対応ということで、
(List) queryForList()
のときに @SuppressWarning つける必要がなくなるのか。
>Hibernate や JPA などの ORマッパーだと
>n+1 問題等でうまくいかないことがおおいため
単に使い方間違ってるだけでしょ
select * from hogeで全件なめて遅いといっていたCOBOL上がりの人思い出した
iBatisは、単純でいいと思うよ。
あれ?スレの内容がまともになってる…
ジャッジメントですの
恐竜システムは酷いSQL実行してたりするからな。
オラクルならログ取れるから録ってみれば。もちろん遅く成るから周知は必要だし、ログいっぱいでシステム止めない様に、ちゃんと張り付いて監視しとけw
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
これJava?
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
いるいるww
現状、それなりに普及してて簡単に使えるのって何がオススメ?
社内用のちょっとしたシステムを作るのに利用したいんだけど。
JDBC
あぼーん
あぼーん
>>464 おれならActiveObjectかCayenne
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
むしろハジマタ
あぼーん
あぼーん
477 :
デフォルトの名無しさん:2010/10/06(水) 17:28:17
ORM(というかEclipseLink)ってResultSetみたいにフェッチでちょっとずつデータを取得するとか出来ますか?
単純にテーブルから引っ張ってくるだけのページなら、JSPに埋め込んでイテレートした方が効率いいなと思ったので質問しました。
そもそもSQLの結果セットをDTOに入れ込むという考え方はO/Rマッピングではないね。
パフォーマンス問題においてそんな細かい概念なんぞどうでもいいのです
このスレの名前いってみろ
ポイントソリューションに概念持ち込む方がおかしい
まずはそのふざけた幻想をぶち殺す
上条さんの説教聞いてると救われた気持ちになります
入信します
うぜーよマ板にいけよ
あぼーん
あぼーん
あぼーん
何なんだよ、この荒らし
アニメ版でやれよ
あぼーん
あぼーん
あぼーん
キモオタご用達のアニメの宣伝はどうでもいい
早く消えろよクズ
あぼーん
キモオタご用達のアニメの宣伝はどうでもいい
早く消えろよクズ
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
JPAでテーブルに関連付けたEntityに
「テーブルに紐付かないフィールド」を追加したいんだけどどうやんの?
エンティティクラスのフィールドは必ず何かの列にひもづいてなきゃだめなの?
@Transientじゃない?
あぼーん
あぼーん
あぼーん
あぼーん
あぼーん
515 :
デフォルトの名無しさん:2010/11/29(月) 22:03:52
JPAのpersistence.xmlで詰まった
tomcatのmyapp/WEB-INF/classes/META-INF/persistence.xmlであってる?
>>515 おれの1年半前いじっていたときのフォルダの残骸を見ると、
あっている
>>515 俺の適当な記憶だとクラスパス上にあるものが参照されるはず
クラスパス上に複数あるんじゃね?
あぼーん
あぼーん
Hibernate 3.6でSQLのバインドパラメータをログ出力する方法が分からず困ってます。
過去のバージョンではlog4jの設定でorg.hibernate.typeカテゴリのログレベルをTRACEにすれば出力されてたのに3.6では出力されません。
どなたか3.6でバインドパラメータをログ出力する方法ご存じないですか?
あぼーん
わかった。実行側(WEB-INF/lib)に
hibernate-entitymanager.libが入ってなかった。
java.persistence.EntityManager(実装が無いやつ)だけで動いてたから
persistence unit が見つかりませんとかエラーがでていたのか
525 :
520:2010/12/16(木) 09:12:07
あぼーん
あぼーん
あぼーん
あぼーん
530 :
524:2010/12/22(水) 04:05:22
>>525 traceではなくてdebugにしてみてください
531 :
デフォルトの名無しさん:2010/12/27(月) 09:45:42
@Entity
public class A{
@Entity
public static class B{
}
}
こんな状態なんだけどpersistence.xmlでBがよみとれない
内部クラスの表記って以下で間違ってる?
<class>A</class>
<class>A.B</class>
自己解決した
$マークなのね
<class>A</class>
<class>A$B</class>
533 :
520:2010/12/27(月) 17:03:25
>>530 試してみたのですが、やはりダメでした…
↓こんな感じでlog4j.xmlに指定しているのですが(泣。
<category name="org.hibernate.type">
<priority value="DEBUG"/>
</category>
うーん…
もっと上部階層のレベルから下げて実験してみたら?
<logger name="org.hibernate">
<level value="debug"/>
<appender-ref ref="myConsole"/>
</logger>
535 :
520:2010/12/28(火) 18:08:00
>>534 それも試してみたんですがやっぱり出ないんです(泣
公式のマニュアルにも特に変更されたとも記述されてないし…
これはもうソースたどるしかないかなぁ。 (-_-;
>>535 >>534 の設定で、ログレベルの trace は試してみた?
少なくとも通常の Logging フレームワークでは、ログレベルを trace から debug に上げた場合、ログの量が減るだけで
違うログが出てくると言うことはないよ。
>>536 自己解決しました。
log4j.xmlのアペンダー設定のThresholdオプションがDEBUGに設定されていたというマヌケな原因でした。
お騒がせして申し訳ありませんでした。
S2JDBCみたいなああいう系列のマッパー使ってる人いる?
流れるなんとかってやつ
void test(){
..Query query = new Query(){
....public void build(){
......select("P.name");
......select("H.age");
......from("P", Person.class);
......from("H", Home.class);
......join( "P.key = H.key" , JOIN.INNER);
......where("P.name = ? AND H.age > ?" );
......bind(1,"人の名前");
......bind(2,"家の年齢");
......result( new ResultList(){
........void invoke(String name, Integer age){
..........Printer writer = new Printer();
..........writer.print(name, age);
........}
......});
....}
..});
..query.bind("人の名前", "太郎");
..query.bind("家の年齢", i * 10);
..query.invoke();
}
あれは簡単なSQL書くには良いんだけどねえ
まあゴミだね。すぐ消えるよ。
そして消えたあとは典型的なメンテ困難ソース。
評判悪いのかw
542 :
デフォルトの名無しさん:2011/01/13(木) 01:11:38
Datanucleusってどうなん?
>>542 知らなかったので少しググってみたけど、JDOの実装の一種なのかな。
まぁ流行らないかも知れないけど、個人的に JDO はすきだ。
Hibernate を知る前に JDO は少し追いかけていたけど、
O/R マッパーが Object → DataBase を関連づけるのに対し、
JDO は、データベースにこだわらない。
データベースにこだわった O/R マッパーのほうが実業に即していたので
いろんなフレームワークが出たし流行った。
でも JDO のほうが触っていて面白いんだよね。
なんか SmallTalk などで、一生懸命オブジェクト指向しているみたいな。
オブジェクト指向しすぎるとパフォーマンス悪いからかな
まずいな〜!こんなにオブジェクト指向しすぎたら
パフォーマンス悪くなっちゃってまずいな〜!
ですよね〜
ぼくのちんちんもオブジェクト指向しちゃいました
548 :
デフォルトの名無しさん:2011/01/22(土) 00:04:45
ActiveObjectsを使ってるのだけど sumとかして合計求めたい時ってどうやってやればいいんだ?
EntityManager#findWithSQLとか使おうにもEntityクラスに何設定したらいいのか分からなくて行き詰まった。。
ちなみにDBはMySQL
549 :
548:2011/01/22(土) 01:13:12
ああ、わかった。asを使って別名付けてあげればいいのか。
で、sumした結果はBigDecimalだから上手いこと変換してあげると必要があると。。。
BeanKeeperとかpBean知ってる人いる?
プロトタイプ開発によさそうだけど
>>550 両方とも初めて知った。
BeanKeeper 、面白そう。少しいじってみようかな。
あぼーん
あぼーん
あぼーん
557 :
デフォルトの名無しさん:2011/04/29(金) 23:44:03.50
Hibernateは糞。異論は認めない。
むしろ異論を見てみたい
まともなのが出せるなら
559 :
デフォルトの名無しさん:2011/04/30(土) 00:42:12.92
>>558 そんなに異論ないほど糞なのかw
あれ最初の一歩から間違ってる感じがして記事くらいしか読んでないんだけど、
実際に使った人の感想は聞いてみたいんだよね。
S2もHibernateと似たり寄ったりだよなぁ。
つかiBatisだけでいいわ。結局複雑なクエリ発行したいときはSQL書くんだし。
561 :
デフォルトの名無しさん:2011/04/30(土) 09:34:25.37
S2はHibernateほど悪いイメージないのだが。
HQLとかLazy/Eagerみたいな糞仕様ないでしょ。
JDBCでいいじゃんw
SpringJDBCぐらいは使いたいわw
RDB使う以上、SQLは無理に避けないほうがいいんだろうな
Hibernate使って遠回りするなら、JDBCのほうがよっぽどいいと思う
565 :
デフォルトの名無しさん:2011/04/30(土) 23:15:30.50
一人くらいはHibernate支持者来てくれw
>>257 >>256以前のレスがあぼーんされているみたいだが、何が書いてあったんだ
まあそんなことより。
JavaDBに相応しいO/Rマッパーってなんだろう
Hibernateが最強かな?
JavaのHibernateの問題点を元に他の言語ではO/Rマッパーを上手く使ってると思う
そしてJavaだけはいつまでもJDBCレベルで作り続けていると
Javaの言語仕様だと、Hibernateより先の世界に行くのはめんどくさいし。
インテグレーテッドされた式木だとか、動的な処理とか、関数言語的な要素が入ってくると違うんだけど…。
中途半端なものしか出来ないなら、SQL書く方が良いわ、っと思う。
JavaでSQLベタ書きをメインにするのなら、自分だったらストアド使う
あぼーん
ストアドはデバッグしにくいから嫌い
572 :
デフォルトの名無しさん:2011/05/02(月) 00:58:51.44
Hibernate糞だからってJDBCってのは極端すぎるだろう…
そこでS2DAOですよ
2Way-SQLの所だけ文字列Utility化してくれれば、後は好きなマッパーでqueryなりexecuteなりするわ。
Javaだと2Way-SQLあたりが現実的な対応な気はする。
575 :
デフォルトの名無しさん:2011/05/02(月) 08:42:58.52
2Way-SQLは筋はいいけど条件分岐まで入れると見てられなくなりそうだな。
O/Rマッパーへの拒否反応って、だいたいO/Rマッパーそのものじゃなくて
Hibernateに対する拒否反応だよな
ここだけ5年前みたいなスレだな
Hibernateの有用性は今更疑うべくもないはずなのに糞扱いで
それに代わるのがSQLべた書き、ストアド、S2Daoって…
ネタだよな?
やっとHibernateのすばらしさを語ってくれる人が来たぞ!
579 :
デフォルトの名無しさん:2011/05/02(月) 12:16:37.57
> Hibernateの有用性は今更疑うべくもないはず
ならなんで全然普及してないんだろうね。
本当にいいものならもっと使われてるはずなんだけど。
煽りじゃなくてマジで疑問なんだよ。
俺としては、むしろHibernateの良さを語って俺を啓蒙して欲しい。
他の言語、例えばLINQ to SQLやArelなんかは良いと思うけど、Hibernateは中途半端というイメージがあって。
なら、2Way-SQLでいいやと思う人なので。
581 :
デフォルトの名無しさん:2011/05/02(月) 13:13:13.87
>579
>> Hibernateの有用性は今更疑うべくもないはず
>ならなんで全然普及してないんだろうね。
多くのプロジェクトで Java 屋さんが入る頃には腐った DB が FIX していて、
アプリからは超絶技巧のSQLを書かなきゃいけないからでは?
そういう状況なら、下手に OR マッピングをするよりは iBatis とか
S2DAO とかで直に SQL 文を書いた方が幸せ。
まともに正規化された DB を扱うなら JPA が第一候補ぢゃないの?
・JavaEE 標準技術
・使える人が多い、参考文献が多い
・たいていの JavaEE コンテナに入っている (知財部門の審査不要)
・Eclipse / NetBeans で自動生成
Hibernate を使うにしても Hibernate Entity Manager から
JPA として使う。
Hibernateも使っていないような所は、DB設計もまともにできていないような糞現場だ、
…っというのはちょっと言い過ぎだとは思うけど。
単純にDBの正規化の問題というより、必要とされるクエリのパターンの問題なんじゃないの。
単純なケース、サンプルによくあるようなWeb系のDB構造(Blogとか)みたいなものであれば、
JPA最強説に異論は無いけど。
もう少しだけ複雑なクエリを考えると、HibernateというかJavaの言語仕様的にうまく
式を表現できないんだよな〜というような話じゃないのかな。
今から新たにやるならJPA?それともHibernate?
584 :
デフォルトの名無しさん:2011/05/02(月) 14:41:15.73
> ・使える人が多い、参考文献が多い
別に使える人も参考文献も多くないよね。
むしろ少ないくらい。まあ他も似たようなものだけど。
あと標準だってのはEJB2の悪例があるし。
>>583 JPAはインターフェース、hibernateは実装クラスの1つだと考えろ。
もちろん実装クラスを直に扱えば秘密の隠し機能も使えるから
良い面もあるかもしれんが、まずはJPA経由で使えるように
なってからの方が良い。
俺はタイプセーフなSQLがほしいな。
専用言語→コンパイル→SQL文字列get()する
javaのFactoryクラス生成とかどうよ?
586 :
デフォルトの名無しさん:2011/05/02(月) 20:49:09.18
SQLの文法ミスなんて適当に一度流せば分かるんだから意味ないと思うけど。
そのための2Way-SQLだし。
JPAは2でおかしな方向にいってしまったし
JavaEE自体少なくとも日本じゃ広まってないし
Java自体Oracleがめちゃくちゃやったせいで公式絡みはコミュニティ壊滅状態だしで
Javaに限ってはもう標準なんてあてにしない方がいい
S2JDBCで十分
ちゃんとした式木が扱えるとかならともかく、Fluent Interfaceしてみたいだけだったり、
Type safeにするためのメタ情報用のクラスを自動生成したりとかださいことをするくらいなら、
2Way-SQLの方が良いよ派だな、自分は。
あぼーん
つまり、今日の日本の現場ではDDDすることなんてまず無いので、HibernateイラネっということでFA。
俺らがやってる業務システム程度では、データストア(RDB)よりの課題解決の方が有効に機能するし。
DAOをRepositoryと言い換える程度のDDDごっこをする意味も無いと言うことで。
あと、ドメインドメイン言うならHibernateとかよりもう一段オブジェクトを抽象化したものが必要だと思うし、
Persistenceな要素は敢えて排除して話をしないと変な誤解が増えるケースもあると個人的には思うけど。
594 :
デフォルトの名無しさん:2011/05/03(火) 09:13:39.49
個人的にはDDD自体砂上の楼閣だと思うけど、
少なくとも現実的には
>>593だろうね。
RDBMS寄りの方がいろいろと楽。SQLの抽象化とか業務だと誰得だし。
Javaを使わないことはあっても、RDBMSを使わない業務システムとか考えられないし。
そしてRDBMSを使わないシステムはますますHibernateとか縁がない。
今までやってきた中では、RailsやPHPのRailsクローンFWのActiveRecord系がいちばん使いやすかった
HibernateはDBを規約通りに作ればそこそこ便利だけど、教育コストが高すぎて多人数の現場に採用できないし
少人数ならそもそもJavaでやろうと思わないしで、結局使いどころが見つからない
インピーダンス・ミスマッチを解決する作業が煩わしいって本末転倒だよな
597 :
デフォルトの名無しさん:2011/05/03(火) 21:18:39.36
何かやっとマトモな話題が出てるな
あぼーん
>>581 ソレダ!
俺もそんな目に遭ったことがある。
すでに安定(しているようにみえる)して動いているシステムに
いまさらORマッピングはしたくないみたいな
マネージャが「まだいいんじゃないかな…」とか言って
新しいフレームワークを導入してもまずそれをテストしなきゃいけないから
コストがかかるから導入しないってさ
そんなにHibernateのようなオープンソースフレームワークが信用できないかねって思いつつね
元請けが書いたコードより読みやすくて全然信用できるのに
たとえオープンソースで信頼と実績があってもものすごく拒絶するんだよね
それでなんでもかんでも自作しようとする。自作したはいいがショボくて汎用性がなくて扱いづらい
>>582 実際クソ現場だと思うよ
っていうかクライアントにDB設計させてそれに合わせて作ってる
偉そうなクライアントの野郎どもがHibernateという便利なツールの実態を知っていればいいんだけどね
オープンソースプロダクトを使うのは勝手だが、
オープンソースプロダクトに不具合があったときに
「オープンソースプロダクトの不具合なので我々では直せません」と言う
低レベルの業者はなんとかならんのかね。
てめーらの勝手で使っておいて直せませんはないだろうに。
フリーライダー。。。
レベルどうこうより、どういう契約してんだそれて思ってしまう
普通は吐けない台詞だよねえ
で具体的にHibernateのどのへんが便利なの
604 :
581:2011/05/04(水) 15:25:29.52
>>603 テーブル構成が
・ちゃんと正規化されていて、
・全テーブルに人工キーのPK項目があり、
・FKの設定もきちんと設定されているならば、
テーブル構成からDBアクセスプログラム(DAO)
がサクッと自動生成されるし、
業務処理からはDBの行(レコード)をPOJOのオブジェクト
として扱える。
たとえば、
部署テーブル
[PK:ID] [部署コード] [部署名] [最終更新時刻]
従業員テーブル
[PK:ID] [従業員コード] [氏名] [FK:所属部署ID] [最終更新時刻]
という感じになっていれば
・ID の自動採番も、
・楽観ロックも
・(部署 1---n 従業員) や (従業員 1---1 部署) の読み出しも
ORマッパー側でやってくれる。
# 厳密には、自然キーをPK にしてもいいんだけど、
# 一律に、全テーブルに [ID] と [最終更新時刻] 列を作ってください
# ってお願いした方が間違えが少ない
その代わり、テーブル構成がグダグダだと、
直接 SQL 分を発行し、結果セット(ResultSet) を Map なり
List<Map> するくらいのフレームワークの方が遙かに楽。
なんつーか、ORMがどうこう以前の現場で働いてるの人も多いのな…。
どのレベルの話をしているのか、正直、それじゃかみ合わない事が出てきてもしょうが無いな、っと思った。
そんなレベルの話だったのかよ、っというガッカリ感。
陳腐な話というか、それこそ何年前の議論だよという感じ。
DB設計が糞だとかつまらない話ではなくて、LINQ to SQL、Entity Framework、Arelとか、
近年のORMを見てきた上で、その上でのHibernateのメリット/問題点や、DDDとか
アプリケーションアーキテクチャを考慮した上でのデータストアに対する戦略だとか、
そういう話になるのかと期待した俺が馬鹿でした。
2ちゃんねるごときにそこまで求めるのはどうかと思うよ。
Hibernateに管理されたEntityオブジェクトはトランザクション境界内で状態管理され
プロパティに定義した関連オブジェクトの遅延呼び出し、
変更したフィールドのトランザクション終了時の自動更新などの特長を持つ
よってEntityオブジェクトを基点とした処理ではDB関連の処理が隠蔽されるので
普通のJavaオブジェクトとしてロジック記述に集中させることができる
・・・と、ここら辺の特長をもって、ドメインなんちゃら関連の基盤としてアピールしてるみたい
他言語のActiveRecord系のライブラリが持つ機能もある程度揃えてはいるけど、
作られたのが古いので、後発のものに比べてあまり洗練されてはいない
この国の現場て604みたいなしょうもないレベルばかりなのかねえ
Hibernate便利()
____
/ \ /\ キリッ
. / (ー) (ー)\
/ ⌒(__人__)⌒ \ Hibernateが使われないのは
| |r┬-| | DB設計が糞だからだお
\ `ー'´ /
ノ \
/´ ヽ
___
/ \
/ノ \ u. \ !?
/ (●) (●) \
| (__人__) u. | クスクス>
\ u.` ⌒´ /
ノ \
/´ ヽ
____
<クスクス / \!??
/ u ノ \
/ u (●) \
| (__人__)|
\ u .` ⌒/
ノ \
/´ ヽ
611 :
581:2011/05/04(水) 21:30:37.06
>>605-610 連休の開放感からか、場違いにも日頃の鬱憤を投稿してしまいました。
スレ汚しにはなりましたが、無かったものと思って議論をお進めください。
こっちは、Spring+JPA or JavaEE6(SessionBean+JPA) を導入して貰う
だけでも一苦労。
さらに、OR マッピングできるような DB 設計をして貰うのにもう一苦労の世界。
そこまでが限界で、アプリのアーキテクチャは、トランザクション・スクリプト
でやらざるを得ない。
もちろん当初の要件はきっちり満たしたものを作るけど、将来的な拡張性は絶望的。
最近は、世の中そんなもんだと思って、特に罪悪感もなくそんなアプリを
作ってきてたけど、目が覚めました。どうもありがとう。
ドメイン駆動デザインが当たり前で、その上で Entity 層の実装はどうある
べきかなんて今のオレには夢のまた夢の世界。まったくうらやましい
ORMとかDDD以前に、なんか勘違いしている感じがするが…
アスペか?
Hibernateやドメイン駆動に幻想持ちすぎじゃね?
俺はどっちも否定しない派だけど、
>>831 が今やっていることにそれが本当に有効なの?
まあ、鬱憤の本当の原因が商流の話だったり、やってるシステムの種別だったり、
自分の立場だったりにあるというのなら、そりゃここで何かを言っても解決しないし、
職場をかえるしかねーよ。
結論としては、柔軟性抜群なiBatis系最高に落ち着くわけか
リレーショナルDBとオブジェクト指向を無理にマッピングさせようなんて
思うからインピーダンスミスマッチなんかに悩まされるんだが、
そういうのが分かってねーんだよクソオタは。
黙ってiBatisかS2Dao使ってろよアホ共が。
iBatisは今はmybatisになったらしいよ
ネーミングはちょっとダサくなったな。
S2Dao(笑)2Way-SQL()
なんだこの結論w
だって便利便利いうだけでどう便利なのか誰も言ってくれないんだもん
俺はHibernateが便利なんて言ってないけどな
LINQ to SQL、Entity Framework、Arelとか、近年のORMを見てきて出た答えがS2Dao(笑)
なんの冗談だよww
つまりJavaはオワコンということでFA?
それを言っちゃあ…
デカイ話ならDB設計とアプリ開発は別会社だし1アプリとは限らないからそれに合わせる設計もおかしい
小さい話ならそもそもそこまでコストをかけれないから他の選択肢を取る
Hibernate使うとしたらPMやPLの暴走かチーム全員どっぷり浸かってる所くらいじゃないかな
と俺は思う
S2Daoも嫌いじゃないけどな俺はw
だからiBatis使えっての
626 :
デフォルトの名無しさん:2011/05/05(木) 01:43:27.73
そんなに言うからArelの紹介記事見てみたけど、
そもそもSQLを隠蔽すること自体が目的になっててろくでもないとしか言いようがない。
一番の問題はSQLを使ってることじゃなくて、
SQLがソースに埋め込まれていて変更がしづらいことだろ。
文法を変えたところで何も変わらない。
627 :
デフォルトの名無しさん:2011/05/05(木) 02:04:07.48
iBatisじゃなくてMyBatis見てみたけど、これでいいんじゃないの。
少なくとも余計な概念とかトラブルの温床とかバッドノウハウだらけのHibernateよりはいい。
>>626 自分も見てみたけど、これってどっちかというとS2JDBCみたいなメソッドチェイン型Criteriaに近いものじゃない?
こういう形式はSQLベタより断然修正はしやすいと思うよ
629 :
デフォルトの名無しさん:2011/05/05(木) 02:16:07.47
>>628 まあ使わずに言ってるけど、
SQLの方が「直接実行できる」という大きな利点がある。なのでテストしやすい。
あとちょっと複雑なクエリになると難しい。
サブクエリのサブクエリを含むSQLくらいは普通にあるけど、この方式だと無理だよね。
S2JDBCはJavaだからIDEでの補完が出来る利点はあるけど、
これにはその利点はないし。
630 :
デフォルトの名無しさん:2011/05/05(木) 03:46:51.09
業務アプリはDBの参照・更新がメインなんでSQLを直接扱えるiBatisが一番だと思ってます。
悩みはDBベンダ依存のSQL。
大抵のSI案件はDB固定だろうけど、規模拡大とか横展開とかしてDB変えるときは
どうするのがいいんだろ。
外部結合とかCASE文あたりはSQL標準形式で書けばいいとして、日付とか文字列関数
とかキーの値生成とかがいちいち違うからなー。
>>629 にもあるけど、サブクエリのネストとか、その辺をサポートしているかどうかが
SQLを書かないタイプのORMを採用できるかどうかの分水嶺な気はする。
勿論、SQLの代わりにxQLみたいなものを書くとか、富豪的アプローチは無しで。
後、本当に複雑なクエリはストアドでやったり、そもそもOLTPとOLAPを分けたりするので、
それは除外するで良いとして。
っで、Javaでこの辺をサポートしているSQLを書かないORMてあるの?
この辺をサポートしようとすると、Expression Treeとか遅延評価とかが必要になりそうで、
Javaでは言語仕様的に難しい気がするんだけど。
タイプセーフにするために列名や演算子のメタデータクラスを作って、staticインポートして、
みたいなモドキはあると思うけど、そのレベルならSQL書いた方が良いわ、っと思う。
#その種の事を自分ではやっていたりもするけど…
これが、俺の考えるHibernateとかが採用されない理由。
> 勿論、SQLの代わりにxQLみたいなものを書くとか、富豪的アプローチは無しで。
採用されない理由っていうか、採用しない理由を必死に考えたみたいな話だなw
そもそも日本以外では採用されてるんだし
別にHibernateでも他のO/RマッパーでもSQLをそのまま書くことも可能なんだから
全ての記述をSQLに拘るのが理解できない
難しいのだけとか言ってないで、全てストアドで書けばいいんじゃない?
Javaでは単なる文字列に過ぎないSQLもソースとして解釈できるようになるのに
結局、Javaでしか仕事が出来ない人の言い訳にしか聞こえない
634 :
デフォルトの名無しさん:2011/05/05(木) 12:55:49.60
VIEW使うのが簡単だけど、それはDDDじゃないとかファビョる。
xQL使うとか言うけど、学習コストは無視。
N+1問題とかなかったことにする。生産性重視と言いつつテスト段階で出た
パフォーマンス問題が生産性を落とす原因になってるのに気づかない。
お前ファビョりすぎだろw
MyBatis 3系の使い方紹介ってどこかにある?
マッパーインタフェース使って、Springと連携させて、なるべく楽に処理を書きたいんだけど。
MyBatisはResultMapがちと面倒だな。
DBのUnderscoreとBeanのCamelを変換するだけで書かないといけないし。
SELECT句の方にASを書くのもどうかと思うし。
この辺をStrategyにして交換できるようにしてくれれば良いんだけどな。
そうすれば、JPAの@Columnアノテーションを使ったマッピングとかもできるのに。
MyBatisの@Results/@Resultアノテーションだと、マッパーのメソッド毎に書かないといけないし、
なんだそりゃって感じだが。
なんだそりゃゴミだな
とりあえず、
org.apache.ibatis.reflection.Reflector.findPropertyName()
を弄ればネーミングルールの変更には対応できるみたいだけど。
つーか、ソース見たけどMyBatisは全般的に拡張ポイントとか弱いな。
Strategyにしておいてくれればカスタマイズできるのに、っという所があって。
SELECT時のマッピングに関して言えば、Spring JDBCみたいにRowMapperを指定できるようにして欲しいわ。
myBatis(iBatis3)はわりと出たばっかだからな。
ちょっと前までSpring連携も非対応だったし。
むしろiBatis時代から古い作りのままって事だろ。
>>633 ストアドとJavaじゃ、デバッグ効率が天地。
ついでに聞かせて。
ストアド主体の場合って、単純なCRUDや、ちょっと条件句が異なるだけのクエリも全部ストアドにするの?
その作成、修正コストって結構なものになったりはしない?
誰が書いても違いの無いレベルのクエリはORMに自動生成させて、それ以上のものはストアドっていう
切り分けも現実的なケースかとは思うんだけど。
ストアドは積極的に使うものではないと思う
この辺については、全部ストアドでやればっていう人達の意見を聞きたいな。
開発効率、移植性、保守性どれも低いからな
あんな2階層時代の遺物なんぞ今更誰が好き好んで
PostgreSQLで全部ストアドにしてiBatisからcallしたんだ。
普通にselectするだけのSQLだったんだけど。
ストアドよりSQLのが速かった…。orz
だからバックグラウンドで処理しなくちゃいけないのしかストアドにしてないよ。
確か同じ内容のSQLだったかなぁ…。
もう細かいとこまでは覚えてないけど。
ストアドのが極端に遅かったのだけ覚えてる。
MyBatis + SpringでもSelectBuilder使いたいなぁ…。
651 :
デフォルトの名無しさん:2011/05/08(日) 01:22:01.57
私の場合バッチ処理が遅すぎてどうしょうもないときにストアドで書き直してました。
バッチ処理というからには複数行のデータを一括でまとめて更新すればいいんでしょうけど、
複雑な分岐が入るような処理になると対象を一件ずつ処理する設計になりがちです。
すると、SQLでデータをDBから転送してJavaなりでロジック処理して更新SQLを実行という
形になるけど、ストアドなら全てDB内で処理されるので転送処理の時間が節約できるわけです。
大量のデータを処理する場合だとかなりの時間節約になります。
INSERT/UPDATEの場合はそうなるかなぁ?
>>202 のやり方で遅いとなるとストアド化するしか無いような気はする。
だからストアドは仕方なく使うもので
>>651みたいに、これでストアドは神と認識して
なんでもかんでもストアドにしようとする思考に入って
しまうようなやつが多すぎる。勘弁してほしい。
>>653 のような、文章に書いていない事を妄想してしまう人はSEやPGに向いていない。
今更だけど、Hibernateが採用されない現状を訴えるときに、
本当にgdgdなDB設計(最近、さすがにこういうのにはお目にかからない)と、
DOA的には問題無いがORM向きにはなっていないDB設計とをいっしょくたに扱うなは勘弁な。
ストアドはアセンブリ言語のようなもの
使いどころはあるけど常に使うものじゃない
>>606 間違ってもJavaにLINQ・ラムダ式は導入しないで欲しいと願う。
あれやるなら別ファイルでやろうよ
Apache Verocityみたいな感じで
>>610 実際クソすぎてHibernateの真価がほとんど活かされず
誤解されている頭の悪い現場もあるがな
>>611 いってることはほとんど同意だし、鬱憤にも見えないが
JPAってHibernateより難しくないか?
>>658 心配しなくても、Javaでラムダが使えるようになるのなんていつかわからないし、
式木の話も無いから真LINQが導入されることも無いでしょ。
それ以前に、1.4を使い続けている現場とかも多いんでしょ。
似非LINQというか、内部DSL型は正直イマイチだと思うし、俺もJavaでは
テンプレート処理が出来る外出しSQLとDAOのメソッドを関連づけるような
フレームワークで良いと思うわ。
そもそもまともに正規化されたdbを期待するのが無謀。
そこはハイバネ用に最適化したdbでも、まともに正規化されてるとはいえないわけで。
java以前のコボラ環境の業務システムなら、コボル前提のdbに最適化されてて当たり前。dbの柔軟性こそが最適化原理主義の障害に成っている。
データベースは過去のデータが資産だから、全面的にdb載せ変えでもしない限りハイバネで扱いやすいdbに変えていくのは難しい。
結局は過去のシステムとの連携でsql駆使して回避できたほうが小手先菊からハイバネ導入せずに使いにくくてもjdbcでがんばったほうが効率的に成ってしまう。
javaにシステム移行で、過去のデータ無しで新規に仕切り直しで始められるのでもなければハイバネ採用は厳しいと思う。
ハイバネに限らずオープンソースの保守は面倒な問題だね。
業務システムなら開発時の環境で10年とか運用したりもするから、10年後まで保守し続けれるのかとか問題が発生する。
オープンソースの開発成果にただ乗りして導入したのは良いけど、早々に開発討ち切られて自分で保守なんてことになるくいらいなら、ハイバネより糞でも困らない程度に自分たちで保守できる独自フレームワークに成ってしまうのは仕方ないと思う。
まだ1.4vm用にオープンソースのフレームワークをバックマージし続けてメンテしてる業務システムなんて皆無だろ。面倒見きれないと放置に成るのがヲチ。それなら保守性が高いと主張されることの多いオープンソースを導入したメリット無い。
10年稼働に対応してくれる商用フレームワークも高額過ぎて手が出ないだろうけど。
あるいはphpやror的に使い捨て言語で凌いで、後で苦労することには目をつぶってしまうか。
>あるいはphpやror的に使い捨て言語で凌いで、後で苦労することには目をつぶってしまうか。
このチョイスに素晴らしいセンスを感じる
664 :
デフォルトの名無しさん:2011/05/12(木) 23:34:56.56
普通じゃないのか?
・使い捨てならRoRなど楽なのを使う
・10年持たせるなら最初大変でもJDBCか薄いフレームワークを使う
Twitterとかまさにそれで最初はRoRだったのが大きくなるとJavaでごりごり書いてる。
Hibernateとか出る幕なし。
あぼーん
実際ウェブ屋に発注すると後先考えないシステム納入してくれるよwww
まあie10の事も考えてウェブ作れとか無理なんだろうけど。
667 :
デフォルトの名無しさん:2011/05/16(月) 13:21:14.30
668 :
デフォルトの名無しさん:2011/05/16(月) 14:20:59.60
ドメインモデルよく知らないけど、
データベース側とJava側でそれぞれモデルを作って
それをHibernateでマッピングさせるとかアンチパターンにしか見えない。
ちょっとしたアプリを作る場合、cayenneが一番すき。
DDDの話をしたがる人はさ、どうして直ぐにPersistentな話に絡めたがるのかね?
しかも、しょぼい業務アプリみたいなものをモデルにして。
個人的には、ドメイン駆動が効果を発揮するのって、計画とかシミュレーションとか、インテリジェントな
思考モデルを扱うときだと思うんだけど。
っで、そういうモデルとRDBの構造には当然差異があるので、高度なマッピングフレームワークを使用して
Repositoryを作る…っという話なら分かるんだけど。
それが、データを画面に表示するだけの簡単なアプリケーションで扱うような、たかだかデータ構造的には
親子関係しかないようなものを持ち出して、それでやれDDDだHibernateだ言うからアンチを増やす結果にも
なっていると思うんだよね。
DDDの話をしたいなら、むしろPersistentな話が関係ない所にすべきだと思うわ。
671 :
デフォルトの名無しさん:2011/05/16(月) 22:10:07.61
>>670 そんな気がする。
あとよく分からんけどHibernateにあるようなキャッシュ機構は
業務システムではむしろトラブルの元で邪魔な気がする。
そういう意味でも業務システムとは相性が悪いんじゃね。
>>670 いったい誰と戦ってるわけ?
どのレスの事を言ってるのかよく分からん。
むしろこのスレではアンチが必死に粗探しばかりしてるように見えるんだけど。
ていうか、ここはORMのスレなんだからPersistentな話をするのが当然だし
670の個人的な考えとか
>>667のリンク先のことを言ってるのなら勝手にそっちでやれば?
みんなHibernate嫌いなんだな。
キャッシュが楽だったり、排他も楽だし、少人数でアプリ作るときは、
大規模でやるような基盤チームつくれないから結構いいとおもうんだけど。
○○というフレームワークは最高!
ただし、そのフレームワークが想定する問題を解決する範囲のみにおいて。
想定してない津波でメルトダウン発生したしなあ。
想定してない障害児にはフレームワークは役に立たない。
フレームワークじゃなくてシステムだな
つうか、なんでこのスレをアニオタのキモオタが荒らしていたの?
ああいうのって、水遁の術で撃退できるからまあどうでもいいとも言えるんだけど
なんでこのスレが狙われたんだ?
とある魔術の禁書目録
上条当麻:森久保祥太郎
インデックス:阿澄佳奈
御坂美琴:竹達彩奈
月詠小萌:花澤香菜
ステイル:大川透
神裂火織:能登麻美子
一方通行:宮野真守
土御門元春:小野坂昌也
HibernateでDDD最高!、っていうサンプルはどこかにある?
あるあるww
結局これを見ろって言うものはないのか。
ぱっとしねーなー。
イカ娘第2期のスタッフ発表でイカスレが通夜会場になっとる
GORMはそろそろ使えるようになってる?
687 :
デフォルトの名無しさん:2011/06/21(火) 02:00:08.12
"ORM が危険なアンチパターンだっていうのはどれだけ言っても言い過ぎることはない"
http://tech.a-listers.jp/2011/06/16/orm_is_an_antipattern/ ・ORMはSQLベースのモデルよりも最初のうちはシンプルで理解しやすく、手早く書く事ができる。
・効率はどんなプロジェクトでも最初の頃は十分。
・不幸にもそれらのアドバンテージはプロジェクトが大きく複雑になると消失し、
抽象化は破綻し、開発者はSQLを使わなければならなくなる。
・ORMの抽象化はほぼ100%のプロジェクトで破綻する。
・オブジェクトはリレーショナルなクエリの結果を表現するのには不適切。
・不適切にクエリをオブジェクトにマッピングすることによって、ORMを廃止しない限り
簡単には修正できない非効率性がアプリケーションのあちこちにばらまかれる
・オブジェクト指向設計はリレーショナルなデータを効率的に表現できない。
これはORMが解決できないオブジェクト指向デザインの根本的な制限だ。
こっちくんな
689 :
デフォルトの名無しさん:2011/06/21(火) 08:45:45.65
外人は率直に言うなw
690 :
デフォルトの名無しさん:2011/06/21(火) 09:55:10.57
>>687の記事ってHibernateみたいな
複雑なフレームワークがアンチパターンと言ってるだけで、
MyBatisみたいなのは否定してないんじゃない?
むしろこのスレの大多数の人が思ってることと同じ。
そもそもORMって別にSQL排除が目的じゃないよな
なんか今はそれが目的になってる感じだけど
MyBatisとDBUtilsだけでなんでもできるわ
694 :
デフォルトの名無しさん:2011/06/21(火) 22:41:43.30
ORMな人ってSQL書いたら負けとか思ってそうでキモい
SQLではなくJPQLとか、無駄に冗長なCriteriaを使えば良いんですとか、そんなこと言っているところがなおキモい。
なんだろう・・・めんまはインなんとかさんを思い出させるんだよね・・・
最適化考えたら結局sql弄ることになるしなあ。
sql埋め込むのに抵抗示すけど、じゃあ汎用命令でパフォーマンス出せよとw
pl/sql,transact-sql,sqlステートメントを使う分には問題ないとは主張に穴空きまくりだね。
もともとオブジェクト指向と言われてるオブジェクトが
本来のオブジェクトを指してないんだから
言語が矛盾してんだよ
オブジェクトであるべきはテーブルや内包される列なのにwww
保守性とか可読性とか生産性がSQL排除でSQL使うときより上がればいいんだけど
贔屓目にみても下がるからな
やっぱJDBCでよくね?
いいんじゃね?
スクリプト言語とJavaを比べて「ほーらスクリプトの生産性はこんなに高い!」
っていってステップ数比較するときの、Java側の長ったらしいコードはだいたいHibernateだな
702 :
デフォルトの名無しさん:2011/06/22(水) 22:32:01.01
せめてDbUtilsくらい使えよw
ハイバネが10年後にもメンテされて使われてるって分かってれば導入するけどねえ。
あっさり消えてる可能性が高いオープンソースだと導入するのはリスク高過ぎる。
ついつい枯れ切ってるjdbcでいいじゃんとか保守契約前提で商用フレームワ−くに頼りがち。
オープンソースのフレームワークのサポ−ト自体では飯喰えないからな。担当の業務システムのサポートをきっちりと行ってこそ飯喰えてる訳で。
>あっさり消えてる可能性が高い
禿
商用だって10年保守されてるとは到底思えん。
そんなときソースがオープンな方が最終手段が取れる分、リスクが低いと思うけどなぁ。
706 :
デフォルトの名無しさん:2011/06/23(木) 08:33:00.09
>>705 Hibernateのソースコードをメンテしたいと思うかい?
jdbcは無いだろ。せめてMyBatisぐらい使えよ。
どうせ自前で似たような仕組み作っちゃったりするんだろ?
俺々フレームワークメンテするよりは名前知られたOSSの方がまだマシ。
だからさ10年前のオープンソースをメンテしてみろってw
10年前のwin2000とかまだ普通に動いてるぞw
709 :
デフォルトの名無しさん:2011/06/23(木) 15:33:15.59
10年前のオープンソースと言ってもピンキリだろ。
10年前のオープンソースの方が、10年前に前任者が作ってそれきりなソースよりナンボかマシ。
後者が前者より高品質なことはめったに無いし、資料も無かったりする。
前者ならまだ知ってる人や資料を見つけやすい。
どっちもピンキリはあるけど。
Batis系のORMとSQL排除系のORMはわけたほうが混乱しなくていいよな
目指すところが同じORMでも全然違う気がするし
MyBatisって、DbUtilsに毛が生えただけだろ。
良くも悪くも。
>>712 おまえ iBatis とか MyBatis とかつかったことないだろ
そもそもソースコードからSQLを分離したいという発想がダメ
そういや、ソースコードからSQLを分離するメリットって何?
716 :
デフォルトの名無しさん:2011/06/24(金) 12:02:41.59
条件を修正したい時に再ビルドが不要とか。
VIEW使えばいいという話もあるが。
そこら中に同じようなSQLがコピペされるのを抑止する。
別ファイルにSQLを集約することで、SQLの保守性が向上する。
ヒント句足さなきゃいけないとか、テーブル分けるとかなったときに圧倒的に楽。
性能問題で調査するときも、SQL詳しい人にSQLだけ見てもらうとかできる。
Javaなりのソースから長ったらしいSQLを分離することで、
プログラム側の可読性も向上する。
ビジネスロジックとDBアクセスのための手続きとSQLを
全部ごっちゃにして書くバカが悪さできないようにする。
SQLもビジネスロジックだからなー
SQLはビジネスロジックでもSQL文生成はビジネスロジックでは無くて、
それがごっちゃになってるのは多々見た。
>>703-704 を呼んでいて思ったけど、
Hibernate は今後メンテされないのかな?
なんだかんだで長生きすると思うが。
そりゃ2003-2005年ごろはアップデートも頻繁にあったし、
いまは停滞している気もするけど、なんだかんだで使っている層はそれなりにいると思うんだよね。
いまは、フルマッピング形ORMを使うとしたら、Hibernate そのものというより JPA なのかな。
OpenJPA、EclipseLink はまだまだバージョンがあがっていくのだろうか。
個人的体験としては、今までSQLを別ファイル化して良いことなんか無かったな。
分けた方がかっこいいかなと思って分けてただけ。
国際化の予定が皆無なのに文字列リソースを分けるコーディングをした時のような気分。
Javaにヒアドキュメントや複数行文字列リテラルが有れば、気分も変わりそうだが。
お前ら数千行のゴリゴリSQL条件組み立てロジックをメンテさせられた苦い思い出ないの?
アレ経験してたらSQL切り出す事の良さ痛感する
SQL書かないまで行くとやり過ぎな気がするけどね
それは数千行のSQLを書くのが悪いんじゃないの?
ごめん。
数百行のSQLが散在したJavaコードで、動的にWHERE句とか
文字列連結して生成してるのは割とよく見かけるし、
何度か保守させられた。
修正クソ大変で、ちょっと間違えると
特定パターンだけシンタックスエラーとか言われるし、
たいがいの場合SQLインジェクションの脆弱性も埋め込まれてるので、
SQL切り出さない奴は首つって死ぬべき。
まあ動的に条件変わるようなのは、SQL切り出しても面倒なんだけど。
「SQL切り出し」とは?
>>726 他言語のコードにリテラル文字列として埋め込まれたSQL文を何らかの形で
分離・集約して管理すること。
>個人的体験としては、今までSQLを別ファイル化して良いことなんか無かったな。
のことですね
SQLリテラル派だけど、動的に文字列連結なんかしねえよ。
view作っておいてwhereとorderbyだけ連結(といってもダラダラ書くんじゃなくて生成器にする)でしょ
経験的には分けるメリットは感じられなかったな。
システムの利用者がどんな情報を求めてるかも会わせて作り込むことがほとんどだったし。
普段の仕事でも実際の仕事する人が別に居て伝言ゲームしてたりする状況に仕事しやすいと感じちゃってるとか?
プログラマ思考的に、プログラマはプログラムの仕事さえ遣ってれば、顧客と会話することも上司や同僚と会話することも無駄とmvc的に分けて別の人に任せたほうがいいと思ってるとか?
>>730 それだとHibernateのCriteriaクエリと一緒になるんじゃね?
>>731 伝言ゲームは最悪だが、MVCの分割や役割分担には意味があるぞ?
一人のプログラマにJavaもSQLもHTMLもJavaScriptもCSSも全て精通していろ、
というのは今となっては無茶な話だ。
必ずしも分けろとは言わないが、SQLだけ特定のパッケージに集約なりは必須だろ。
対象とするシステムの種別によって、動的な組み立ての必要性は大小があるよね。
集計済みの結果を表示するものなら不要。
検索条件の有無、ページング、ソートありなものなら必要。
>一人のプログラマにJavaもSQLもHTMLもJavaScriptもCSSも全て精通していろ
別に無茶じゃないと思うが・・
ドカタコーダーとばかり仕事しすぎじゃね?
世の中のSEを名乗る人材の9割は土方以下のコーダー。
そういう人たちを使って仕事を回す知恵も必要だよ。
恵まれた環境でしか保守できないようなプロジェクトじゃ
成り立たない現場もある。
>>735 どんだけスーパーマン有り気な仕事してんだよw
その基準で仕事したら世の中の大半の職場は回らないよ。
仮に全部やってますって奴がいても、HTMLがテーブルでレイアウトしてたり、
プログラムが中途半端だったり、全部プロレベルの超人なんてまずいねーよw
739 :
デフォルトの名無しさん:2011/06/25(土) 23:57:07.30
精通のレベルにもよるがJavaもSQLもHTMLもJavaScriptもCSSも一通り分かるのって普通じゃ?
まあうちは少数精鋭かもしれんが、他の会社どれだけレベル低いんだよ…
JavaとSQLはセットだし、HTMLとJavaScriptとCSSもセットだから実質2つだな
プロレベルっていうのがすごく抽象的だからあれだけど、とりあえず普通の仕事でつかえる程度のレベルなら
つかえないやつのほうが少ないと思う
CSSは例えが悪すぎる。デザイン重視のサイトならデザイナに外注すべきだろ。
JavaとC++とアセンブラに精通していろ、ならスーパーマンかもしれんが
SQL,HTML,JavaScriptあたりはJavaでWeb系やってりゃある程度精通するだろ。
もちろん向上心ない奴ならいつまでもダメだろうが、そんな話じゃないよな。
742 :
デフォルトの名無しさん:2011/06/26(日) 00:43:13.55
WebKitw
最近はブラウザ側のコーディング比重が大きくなっているから
DBアクセスとビジネスロジック・コントローラまでを担当するサーバ側と
Viewを担当するクライアント側に分けて開発者集めればいいんじゃない?
最近は社内にデザイナーも雇わないと失注するな
厳しい世の中になってきた。
745 :
デフォルトの名無しさん:2011/06/26(日) 10:53:27.06
SQLファイル外出しの利点の1つはCRUDの調査をSQLファイルのみ
grepすればできるところ。あとはeclipseでそのSQLを呼び出している
メソッドを見つけて、Javaからどうやって呼び出しているかを見ればよいと。
あと、ビューでもservletから文字列出力で作るよりテンプレートエンジンで
作るほうが、どんな出力になるかの見通しがいいですよね。
テンプレート見ればだいたい想像がつく。
SQLだってテンプレートを元に作るほうが見通しがいいわけです。
バインド変数があるからビューのテンプレートエンジンと同じものは
使えず、SQL専用のものが必要ですが。
で、MyBatisはまさにそういうものかなと。Hibernateとかは全く別ものだけど。
SQL外出しなら別にHibernateでも出来るから
そこがORマッパーの違いというほどの機能でもない
/ | /: : :/: !:/ !ハ: : !Vい: ::!
/ :| /: : :/ T ナー匕 Vト、_レ:┌―――――――┐
/ ' /: : :/ r ⌒` '⌒V: | 青の祓魔師 .|
`=ニニニV: : : :| ヽ ヒリ ヒ} 〉.| 出演依頼の .|
{|: |: |: : :! ` ー , ー‐ ! .| お知らせ |
'. j :ム:|∨:', !: r―-、 r―ヘ
∨: :{ r|: :ヘ / ̄ ア' 人/ 二ニ> (二 }
/: : : ヽ|: :|: :ヽ 、 こ_ ノ ,∠.: :/ つ (二.,}
/ : : /: :/: :| : : \` ーr< >' ノ
スレチだけど、うちは社内にデザイナーいるよ。
最近のシステム開発は、技術のニーズがエッジ(UIのリッチ化、データストア処理の最適化)よりになってきている気はする。
>>748 > データストア処理の最適化
って具体的にはどういうこと?
RDBに入れていたのを、データ件数が多くなって検索処理をあげるために、NoSQLに移行しました、見たいなの?
ちょっと違うかもしれないけど、最近BIツール、あるいはBI的な機能への要求が多くなってきた。
スクラッチで検索画面、登録画面を作っても Excel みたいに柔軟に情報検索したりグラフが描けない。
でもまともなBIツールはないし、高いんだよな。おれたちもJava開発は知識があっても、BIツールの使い方は詳しくないし
cssってデザイナ任せでも仕事料減らないからなあw むしろ仕事増やしてくれる元凶w
css入りhtml5とjavaのマッピングフレームワーク無いの?
java的に使いにくいcssを作り出すのを抑制する機能がアドビのつ−るに有ればいいのに。
ジャバ側である程度仕様決めてビューのマニュフェストをxmlで吐いて、それをアドビツールで読み込むとちゃんとjava側を考慮してそのまま使えるhtml5を吐き出してくれるとかw
自分でデータベース系のサイト組んだことあるデザイナとしか仕事したくないw
biは求められてもちょっと違う気がする。sap的にbiの一部を切り抜いて定型業務化されたお決まりのものなら組み込む意味あるけど、
biを使いこなして新たな収益を見つける様なのだと、顧客情報や企業ノウハウの流出に考慮した上での、biツール専用のオンメモリデータベースを用意して業務データベースから定期バッチでレプリケーションして
業務に支障を与えない様に自由に儲かる何かを探し出してもらったほうが糞高いbiツールの元が取れそうに思うけどね。
おれらがデータベースを駆使して儲ける方法まで探してやるのは何か違うし、仮に儲けること探すなら経営者として事業部長を拝命するなりしてそれなりの報酬貰わないと割に合わない気がするw
まあそれよりit馬鹿のままじゃ全然無理過ぎるから、経営系の大学に入り直したほうがいいかもしれないw
まずは改行を覚えた方が良いと思うよ
>>750 Javaでコントロールしようと考えるのがまずおかしい
クライアントとサーバでしっかり切り分けろよ
753 :
デフォルトの名無しさん:2011/06/28(火) 08:36:09.67
典型な知ったかだなwww
>>750 Eclipse3.7で導入されたWindowsBuilder使ってGWTやれ。捗るぞ。
ウチの場合はBIっつうか、役員連中がよく分からない基準で、
営業成績とか売上状況をいろんな切り口から見たい、って駄々こねて、
情報システム部がその都度SQL書いたりして頑張ってる、ってケースが多いな。
直感的なグラフでバーっと表示して、知りたい情報がパパっと見られて、
問題点がスパッと切り出せるのが理想なんだと。
んなもん知るか。
756 :
デフォルトの名無しさん:2011/07/02(土) 09:24:32.80
役員向けにグラフも作成できない情シスは脳無し過ぎる
役員が営業部長にこーんなグラフが欲しいんだけど
営業部長が情シス部長にあーんなグラフが欲しいんだけど
情シス部長がシステム担当SE(こいつはコード書けない)にそーんなグラフが
システム担当SEが俺(別システム担当コード書ける)にこーんな仕様で、
って謎の伝言ゲームが行われている我が社。
俺に拒否権も選択権も無いのに動きが悪いからって査定下げられたオワタ。
ところでHibernateが叩かれてるみたいだけど、
JPA規格の部分だけ使えば他のフレームワークとも切り替えられていいんじゃね?
と机上の空論を展開してみる。
切り替えるタイミングっていつ来るのさ
使ってるフレームワークがオワコンになったら。。。とか?
JSFとかJPAとか規格化されてる奴なんかだと偉い人にウケがいい、とか無いかな?
760 :
デフォルトの名無しさん:2011/07/02(土) 12:10:43.93
EJB2が実質オワコンになったような例もあるから安心出来ない。
というか自分はEJB3もオワコンになると読んでるけどね。
期待のstruts2も終わってた気がw
結局JSP+Servlet+JDBCがいいな
複雑なフレームワークほど、人員が確保出来なくなるとメンテ不能になるはず。
>>763 正しくは、スキルの高い人員を1人でも確保できないと保守不能になる だな。
>>763 単純なフレームワークだと、その上に俺々フレームワーク構築されてメンテ不能か、
重複コードだらけでメンテ不能になるけどな。
ヲレヲレじゃなくてもメンテされてない古いフレームワークのまま放置されてたりで大差ない。
ヲレヲレでもメンテされてたほうがまだいい。
ヲレヲレをヲレヲレフレームワークで呼べばいいだけだし。
propertiesファイル使うiBatisモドキとSpringモドキを作らされた俺が通りますよ。
propertiesファイルに書かれたSQLをIDで指定して実行する、
インタフェース指定すると、propertiesファイルに書かれたクラスをロードする、
とかいう、それぞれの劣化版みたいなの。
2006年ぐらいに。
内部での評判は、イレギュラーなことをやろうとすると機能が足りない、
中途半端でメリットが判らない、と散々だった。俺もそう思った。
後々iBatisとSpringの存在を知って、当時のSEは何でそれら使わずこんなの設計したんですか?
と聞いたら、マネージャーが、集めた中国人プログラマのスキル的に使えない
と思って却下したと言っていた。
こんなわけ判らないものより、既知のものの方がみんな使いやすかったと思うんだ・・・。
Nか?
Nです。
770 :
デフォルトの名無しさん:2011/07/06(水) 19:42:03.96
おっとSDEの悪口は(r
日本のIT業はどこもそんなもんじゃね
>>761 擦れ違いだが、Struts2 って終わっちゃったの?
自分自身はほとんど触ったことないけど、SpringMVC + Spring を選択しないケースや、選択しない層が
わりと Struts2 を選んでいて、Struts2 の ver.2 系になってからは、そこそこ実績も聞こえるようになってきたと思ったのだけど。
Struts2とかSpringMVCとかはもういい
裏側なんて難しくないしめんどくさくも無いからどれでも大差ないDBアクセスはORに切り離されてるし
ViewをJSPやvelocityじゃなくてHTMLで書きたいわ
>>773 Wicket や Click は、ちょっと違うか(HTML に、フレームワーク固有のコードが入るっけ?)
たぶん
>>773 がのぞむのは、HTML の各要素に id属性を振って、
サーバサイドから HTML を DOM で舐めて、id のタグを置き換えるとか、そんなのがいいということかな?
teeda がそんなのだっけ。
>>773 さんが、こんなのがいいというフレームワークがあれば教えてほしい。
>>774 まんま名前上がってる奴だね、どれも下火過ぎて泣ける・・・
teedaは最新じゃJSPに戻してたはずだけど
ORは色々出るのにView切るだけのは出てこないよねFreeMarker、velocityくらい?
と思ってググったら結構あるのねw知らないだけでした
mayaaもあるでよ
Struts2とSpringMVCはコントローラの汚くなりかたが逆方向に向かってて面白いな。
つうかこれのどっちかしか使えないってのは有り得ないのでまさにどっちでもいい。
個人的にはこの2つに比べてのClickの残念さが際立つ感がある。
ViewはなんだかんだでJSPが一番無難で次点でVelocityだなぁ。
FreeMarkerは5年後も存在するとは思えない。
wicketをもっとDOMにしたようなのはどうよ?
画面をHTML・CSSなしで全部Javaにするとソース書く量が多くなるから
HTMLから下書きソースを生成するジェネレータ必須だけど。
class MyPage extends Page {
Head head = new Head().in(this);
Body body = new Body().in(this);
Form form = new Form().in(body);
Div div = new Div().text("name").in(form);
TextField field = new TextField().in(form)
}
Ruby の haml みたいだな。
http://haml-lang.com/ haml を Java 上でも動かせるようにしたらいいんじゃね?
ついでに Spring Integration とかやってみるとか。
それだとやっぱりhtmlもどきを別に編集する必要があるからなー。
wicketもxhtmlのみにもかかわらずタグidの階層間違えたりしやすかったから
100% JavaでHTML出力するのがいいと思う。
>>780 100%javaじゃ何の意味もない
客に見せてそのまま預けてデザインさせてそのまま使うってのがいい
>>781 客がJSP書くのか?
それとも客の目の前でデザインを変えて即システムを動かしてみたいのか?
後者なら上位レイヤーにCMSでもおくしかないと思うが。
俺はホームページビルダーとかデザイナーツールから
でてきたHTMLをツールを使って100% javaソースに変換して
そこから繰り返し処理や分岐、ロジックのソースを書き足せばいいと思うのだが
783 :
779:2011/07/14(木) 13:34:53.07
まぁ
>>780 (=
>>782 ?) の考えていることもわかる。
デザイナーとかがいなくて、プログラマが HTML 層まですべてやれる場合、
Java でやったら、手間はかかるかもしれないけどかなり構造的というか論理的な HTML が
作れるかも。
HTML のテストもしやすそう。
784 :
デフォルトの名無しさん:2011/07/16(土) 02:56:40.72
おいおまいら、RDBとのマッピングの話しる!
スレの名前見るといいよ
フルスタックはもういらねってことで
__ _,,.. -─‐- .、.._ _|__ノ
ヽ . ´ __`丶_ / .ヽ
} / ,. ´: : : : : : : : :` 、 、___ノ
/\/ /: : : : : : : : : :、: : : : : : : : \ / /
._/ \ ./ : : : : :/\: : : : : ∧: :、 : : !⌒/ /
\ \ /: : : :∧: /⌒ \ : :/ ∨、\:.|. / /
\ '{.: :/ : / ∨,,.__` ∨ __, /ヽ}/ /
∨ イ |:〃゙ ̄` '⌒ヾ{ : :j/ /
ヽ マ:j! ´´´ ´´´ ; : / /
Y } /  ̄ ̄} j∨ / 今週から全国のミニストップとセーブオンで
∧ ./:ハ. { ,′ 人:ヽ. /
. / ∧ /:/ 丶、 、_ノ / \`く\ イカ娘フェアが開催されるでゲソよ〜♪
___/_厶/; ' \_}>ーr<ヽ >:ー-=:ー‥ ニ二 : 丶、
/,-─ァ ┬─:‐ヘ .}|丶、 ヘ.l l l / /: \ : :\ `ヽ: \ヘ
: : > /: :/ /: :∧ !ヾ、 // l ′/\ \: :.\__ \: : :',
`^ .|: : | /: :/ ', / ヾ、 // { /\: :\ \ : : :\ /_/
|: : | // ∧ / `∨/ ∨ \: :\.  ̄\ :\、
.ノ: :ノ |: :| /: :ト′ Y >; : > <: : : : >
<: :<__ ヽヽ ./: :/'; } <: : < \/
ノ: : ://: /<: :< ! .:::::.:. .::::.:.;′ .ゝ └,
`ヽ;/.」: ∠ \:ヽ,| =- 〈 \/
\_/. \:} _. {
ノ │
みんな、ミニストップでイカ娘コラボ商品を買ったかいw
俺はえび満月とティシュとカレースナックを買って
うちわをもらったzo!
JPAで生成したテーブルのカラムにインデックスを貼るのって出来ないので
しょうか。
もちろんスキーマ生成した後にRDBMS上から手作業でインデックスを貼る
ことは出来るのですが、出来るのであればJavaソース上のアノテーション
でインデックス作成の指定をしたいです。
OpenJPAにはあるけどJPAには少なくても1.1にはないよ
JPA2.0調べてみるか諦めろ
う〜ん、やはりそうですか。プロジェクトではHibernateを使って
いるのですが。
でもJPAの規格にも無いって何を考えているのだろう。
JPQLでID以外の属性で絞り込みをする度にフルテーブルスキャン
がかかるのですが。WHERE句を使うなって事か。
インデックスってこまめに張り替えるもんじゃないし、別にいらないだろ
JPA2.0にもなかったよ
XMLでテーブル定義すればできたような覚えがあるけど
テーブル生成だけはアノテーションやめるか
JDO or OpenJPA使うよろし
おれはAntでテーブル生成SQLを自動化してる
そもそもO/Rマッピングすべきではないね
RDBMS間のSQLの仕様や方言の違いを考慮してDBスキーマ作成用の
SQLを複数用意したりSQL生成する仕掛けを手作りせずとも、Javaの
コード上でよろしくアノテーションつけておけば後はJPAの実装が
ターゲットのRDBMSに向けたSQLをよろしく自動生成してくれると
思ったのに・・・
インデックス一本張ろうとしただけで破綻してしまうのね。切ない。
共同プロジェクトの中の一部分を作っているだけなのでJPAの実装は
Hibernateで動かせないし、うちだけDB作成用のSQLを添付しますと
言ったら嫌な顔されるだろうなぁw
796 :
デフォルトの名無しさん:2011/07/29(金) 15:20:24.80
こうしてアンチHibernateがまた一人生まれるのであった
O/Rマッピングは甘え。
hibernate4.0には@Indexアノテーションあったけど
JPAインターフェースでは使えないんだよな
JDBC最強説w
ご免なさい。インデックスの話また蒸し返します。
単純に興味があるので聞きたいのですが、JPAの2.0でもインデックス
作成をアノテーションで指定出来ないという事は規格の作成者たちは
必要性が薄い、無くても別の解決策があると考えているんですよね?
おそらく。
となると、例えばdouble値として身長、体重を持つ人物エンティティ
を永続化したとして、DBから人物を身長で絞り込んで引っ張ってきて
アレコレする、という操作はどう実装するのでしょうか。
単純にエンティティクラス定義にアノテーションつけてスキーマ作成
した場合は何時だってフルテーブルスキャンになりますよね。
操作自体はごくごく一般的だと思うので、何か自分の知らない上手い
解決策(全然違うデータモデリングとか)が存在すると思うのですが。
>>800 インデックス貼って最適化とかは、O/Rマッピングで抽象化すべき範疇じゃなくて、
RDBMSごとに行うもの、という認識なんじゃない?
インデックスといっても、微妙に種類だってあるわけだし。
俺はいつもDB作ってからJava側を生成する感じでいたから、
生成して欲しいという感覚がよく分からんが・・・。
テーブル定義のSQLなら、モデリングツールなんかで自動生成してくれたり
もするし、そういうのでもいいんじゃない?ERMasterとか。
RDBMS毎と言えばそもそもDDLやDMLからして方言の違いがあるわけで、
JPAのスキーマ自動生成とかJPQLとかはその上に一段抽象化された層を
重ねる事でその辺の差を吸収してくれるものだと期待していたので。
どうしてそこからインデックスを外すのかなぁと。インデックスの種類に
してもデフォルトのB-Treeで大敗して初めてRDBMS毎の最適化を考えれば
良いのではないかと。
なぜこんな事を気にするのかというと、今関わっているプロジェクトでは
開発側はPostgres+Hibernateで統一されているのだけど、出来た成果物
自体は(HibernateのDialect定義が提供されている範囲で)任意のRDBMSが
走っている環境上に展開出来る事を意図しているみたいなので。
なんでスキーマ定義の直書きやJDBC直叩きば御法度で、スキーマ定義から
DB操作までJPAのAPIの範囲内で済ませなさいと言うお達しなんです。
>>802 そういう済ませなさいという決断をする前に
DDLの主な操作がJPAだけで出来るかどうか調査するべきだろ
出来ない時点でその決断自体が間違っていたんだよ
>>803 そう思う。そう思う。下っ端の僕に言わないでぇ(涙)
でも本当に不思議。だってキー以外にインデックス張らないなんて。
JPAのアノテーションで生成されたスキーマって全行スキャンかけても
困らない程度にテーブルが小さいか、条件絞り込みの必要無いアプリ
にしか使えないような。
本当に不思議、というか本当に使われているの?
>>804 だから、普通は使えるかどうか調査してから使うもんだろw
とりあえず、Hibernateのindex属性またはアノテーションを使えるよう
上を説得するのがいちばん現実的じゃないの?
血Cの監督の水島ってガンダムとかやってる方の水島かと思ったら
イカちゃんとかやってる方の水島だったのな
クソツマンネーからガンダムやってる方かと思ってたわ
さすがの水島も脚本とキャラデが絶望的なんじゃどうしようもないな
まさに水島の無駄遣いだよなぁ
素直にイカ2期をやらせておけばよかったのに
>>791 Hibernateアノテーションにあったはず。
BSジャパンで今日からイカ娘の再放送\(^o^)/ハジマタ
毎週金曜23:00-0:00
2010年、人気アイドル声優
8人以上知ってたら重症
平野綾 …アイドル声優の模範のような活動を展開、アンチも多い
水樹奈々 …オリコン常連。声優活動も積極的
釘宮理恵 …ショタからツンデレまで。中毒者多数
井上麻里奈…モデル顔負け、多彩な才能を持つ
茅原実里 …長門で有名。歌手としても活躍中
小清水亜美…いいとも出演で有名になる
堀江由衣 …ピークは過ぎたが人気今だ衰えず
日笠陽子 …けいおんでブレイク、非常にアグレッシブで芸人声優との声も
花澤香菜 …棒声優,彼氏などあったが実力を付け大沢の次期エースに成長
戸松遥 …実力はあるが事務所のゴリ押しもあってアンチも多い
悠木碧 …子役出身、09頃から露出が増え人気急上昇
伊藤かな恵 …あむちゃん。新人賞を取り今波に乗る1人
喜多村英梨…多彩な才能、演技の幅も広く実力派。しかし影は薄い
豊崎愛生 …08頃から頭角を現す。現在波に乗っている若手の1人
竹達彩奈 …けいおんでブレイク、アイム期待の新鋭
井口裕香 …インデックスでブレイク、大沢期待の新鋭、しかし役に恵まれず
金元寿子 …ソラノヲトで注目される、イカ娘に抜擢され波に乗る新人
後藤沙緒里 …今にも消えそう
イカ娘ウェットタオル買ったわw 2つもww
万能文化イカ娘
Hibernateのマッピング定義って
XML書くのとアノテーションで指定するのどっちがおぬぬめ?
hibernate.orgのドキュメントみるとXMLが基本なんだろうけど
アノテーションも専用のドキュメントがRedHatにあったり、立ち読みした本はアノテーションメインだったり
結局どっちやねん、てキブンになったので
イカ娘は、イカちゃんがかわいい作品であって
イカ娘という作品がとても面白いわけではない。
1期のころからそれを勘違いしてる人多いよね
でも2期のイカちゃんはちょっとあざとくないか?
1期の自然なかわいさとちょっと違う
>>818 好みでいいんじゃないの?
XMLであれば、マッピング情報はXMLだけを眺めればよい。
アノテーションにすると、*.java まで追いかけなければならないので、ちょっと面倒。
だけど XML 書くのめんどくさい。
あと XML 形式だと、Hibernate とは関係ないソースから持ってきた
エンティティクラスのソースを、ソース修正なしで Hibernateで扱えるが、
アノテーションにするなら、持ってきたソースを修正して、アノテーション情報を追記していかないといけない。
つまりソースを共有できない(そういう局面があるかどうかは別だけど)
./ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
| ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄| |
| 花王 ランチタイムデモ in 東京 開催決定だゲソ! | |
| | |
| 集合時間 10月21日 金曜日 午前11時30分 | |
| 集合場所 中央区 坂本町公園 (花王本社のすぐ近く) | |
| 東京メトロ 東西線・日比谷線 茅場町駅12番出口すぐ | |
| | |
| フジテレビと花王と韓国の問題に関心のある人間は大集合だゲソ | |
| | |
| 手ぶらで一人でも、家族や仲間といっしょでも、仮装でもOKでゲソ | |
| みんなで約1時間、数千人の侵略、もとい大行進を楽しまなイカ! | |
|_____________________________|/
/ |i |/: : : : : : : : : : : : : : : ヽ\ ./
< /'|i |: : : : : : : : : : : ハ: :.∧__ : : : \ ./
ゝ..イ´|i | : : 人.: : : : : / ∨'''∨.: : : : : 〃
i : : |i |:|: :| \ : :./_/≠=ミ∨.: : : : :`\
i : : |i |:ト┼===ヽ:/ ´ んハ . ∨ : :.∧ ̄
i: : |i |.W/ ん下 弋:リ i∨/ ヽ∧
_∨|i |::| .{. 弋:リ , i: : i丿 ∧
/〆 二ヽ,ト _ ,,...-‐┐ i |',: : :∧
i ´ ___`Y.∧ <: : : : : : | ./l :|ゝ-- ∧
∨. ,-‐-_).i: ゝ._ ゝ: : : _/ | /: :i .}
>>823 アノテーションのほうがラクではあるけど
ケアレスミスしたときにトレースするのが大変だな
Eclipseのhibernate tool(JBossToolsの中にあった)で
アノテーション形式でエンティティビーン(?)が児童生成できるのにはビビタ
> あと XML 形式だと、Hibernate とは関係ないソースから持ってきた
> エンティティクラスのソースを、ソース修正なしで Hibernateで扱えるが、
あれ、そっちだとエンティティくらすは継承の記述が必要じゃなかったか
827 :
823:2011/10/10(月) 01:19:52.44
>>826 もう昔なので忘れてしまったけど、XML形式だと、
エンティティクラスは、完全なPOJOでよかったと思う。
以前のソースを引っ張り出して見直したが、スーパークラスも特に何も指定しなくてよい。
アノテーションみたいに、import javax.persistence... という記述がいらないので、
POJOをコンパイルするだけなら j2ee.jar みたいなのがいらない。
>>827 xmlは管理がめんどくせ
といいながらhibernate.cfg.xmlを引っ張った後に
「アノテーションが定義されてないよニヤリ」みたいなエラーがでるのはなんとかしてほしい…
自動生成だから書いてあるっての @Entity のパッケージも間違ってないっての!! もうわけわかんね
SQLQueryでCHAR(N)型取得しようとするとN文字のうち先頭文字しか取得できなくてわろた
フォーラムとか見回してみたらバグなのな
今更CHAR使うなとかはいわないでくれ orz
複合キーのテーブルからHibernate toolsでEntityクラス作ったら
複合キーの項目に関しては更新ができないのな
シリアル型項目のプライマリキー追加して
元複合主キーはユニーク制約つけておけばいいかな
キー更新するとかどういう状況だよ
>>831 複合ユニーク項目(更新あり)なので
「サロゲートキー用意してさらにあんたの作ったクソテーブル正規化していいっすか」
といったら殴られた場合とか
ついでにそのオッサンはVARCHAR禁止令を出してた
これは無理矢理SQLを使ってる奴に永続化を叩き込むチャンスにはなった…
JPAの話題はここでいいのかしらん
良いんじゃないのかな。
836 :
デフォルトの名無しさん:2011/10/23(日) 18:37:26.15
>>828 アノテーションで定義すると
ソースファイルに散在することになる
後々のメンテ管理を考えるとお勧めできない
「?オブジェクトはリレーショナルなクエリの結果を表現するのには不適切。」
この一言に尽きるな
誰がORMとSQL撲滅を関連付けちゃったんだろう
839 :
デフォルトの名無しさん:2011/10/23(日) 21:18:07.27
客先から見たら
DBなんて高速で問い合わせして結果を返してくれるのが一番だ
ドメイン駆動がどうたら〜、
ビジネス層からの呼び出しは良くない〜
だからJPAのDDDこそが〜
そんなの客にとっちゃ、どうでも良いんだよ
エセ技術者のエゴを客に押し付けるなよ
840 :
デフォルトの名無しさん:2011/10/23(日) 21:54:22.30
JPA・DDD・Hibernate
このスレだと異常な叩かれ方だな
コンプレックスを抱えた人が多いんだろうか?
まぁ、なんだかんだいって難しいからね(笑)
とあるプロジェクトであるレコードが辞書で管理された単語への参照を持っていたのだが、
その辞書というのが単語数1万件程度で20弱の階層を持つツリーとして管理されていた。
で、そのチームから出てきたコードではJPAでレコードと単語をオブジェクトにマッピング
していたのだが、参照が全部EAGERだったので、レコードを一つDBから引っ張ると参照
している単語をDBから引っ張り、さらにその単語の親や子供を引っ張り、さらにその
祖父母や孫、と辞書内の全ての単語を雪崩的に引っ張るので結果的に一つレコードを
引っ張るのに5000件ほどSELECT文を実行する大変面白いインプリだった。
単にLAZYに書き換えてもテストが通らなかったので面倒なので突き返した。
ORM使うのはかまわないけれども、一応生成されるDBスキーマやSQL文のレビューは
ちゃんとして欲しい。
>>839 そんなのより客にとっては開発費用が先だろ
作る側も効率化が「できれば」開発期間が少なくなって安く提案できるし
というわけでうちの上司はORMが嫌いらしい
あと速さが重視される部分て
最後はストアドプロシージャゴリゴリなんで、あれをなんとかしてほしいな…
844 :
デフォルトの名無しさん:2011/10/23(日) 23:54:53.06
叩かれるのは本質的に簡単なものを間違って難しくしてるから。
845 :
デフォルトの名無しさん:2011/10/24(月) 00:31:16.43
>>842 こういうのを使うと
中でどんな効率の悪いSQLが生成されてるのか怖いな
そもそも直接SQLで問い合わせるのが一番高速なのに
わざわざ変なフレームワークで改悪SQLを流してるんだから
技術的に見れば後退してるよな
ORM使うのは嫌いじゃないけれどもRDBの素養がない人間に使わせるのは大嫌い。
847 :
デフォルトの名無しさん:2011/10/24(月) 00:42:21.60
>>844 エンティティなんて「ただの入れ物」なのに
それを神格化させすぎなんだよ
ORMに固執するあまり実際の業務で必要なデータを扱うときには
まるで実用には値しない
あるテーブルを副問い合わせして、group byしたものを別のテーブルとjoinした結果と
別のテーブルとexistsする、とか
そんな要求は普通にあるのだが
こういう場合はHibernateやらJPAではどうやって実現するんだ?
まさか「直接SQLで取得して下さい」とか言うんじゃねーだろうなw
そんなことしたら、ワザワザ定義ファイルとかを作ったり、クラスを作ったりして
素のJDBCでSQL書くよりも、余計に手間かかるじゃねーかw
何の為のORMなんだ?w
最初に有名になったのがiBatisなら
変な方向に進んでいくこともなかったんだろうが・・・
849 :
デフォルトの名無しさん:2011/10/24(月) 00:44:22.17
>>845 遅い上にEAGER/LAZYという概念を意識する必要があって
SQL直書きより分かりづらくなってるからどうしようもないね。
こんなゴミを標準にするくらいなら標準なんてない方がマシ。
851 :
デフォルトの名無しさん:2011/10/24(月) 00:45:46.83
>>846 この手のFWが浸透してきたら
それしか知らない若い奴とか増えてるのかも
ちょっと前までは一人でSQLから画面から何から何までやるのが当然だったんだが
852 :
デフォルトの名無しさん:2011/10/24(月) 00:55:20.67
フレームワークが増えるのはいいが
人間は退化してるようだな
特に開発要員、フレームワークの使い方に特化してるが
基本のJavaのコア部分やSQLなど知識ないのもいるからな
宗教はろくでもないってことだな
854 :
デフォルトの名無しさん:2011/10/24(月) 20:46:47.05
>>850 副問い合わせの入れ子の
JPQLなんて見たことないがw
>>854 まぁ見たことはないが、仕様的には書けるんじゃないのかなw
EXISTSみたいな述語もあるみたいだし。
856 :
デフォルトの名無しさん:2011/10/24(月) 20:59:14.13
理論的に書けるのと
実践は全然違う
たとえ文法上書けたとしても
パフォーマンスが異常に遅くて使い物にならんとか
生成されるSQLが糞すぎるとか容易に想像できる
実際にやってみると良いんじゃないのかな。
JPQLはSELECT文の構造もSQLのそれととよく似ているし、パス表現を沢山の
JOINに置き換える事を除けばJPQLでのSELECT文からそれとそこそこよく似た
SQLのSELECT文を吐くよ。
858 :
デフォルトの名無しさん:2011/10/24(月) 21:16:09.09
Hibernateでテーブルとのマッピングの際に
何かのツールがあるのか?
まさかエンティティクラスとhibernate.cfg.xmlと各定義の.hbm.xmlを
全部手書きとか爆笑回答するんじゃねーだろうな?w
それならば
JDBCで直接書いたほうが遥かに開発コストが高いだろ
今はアノテーションが主流だし
ツールだって無い訳がないだろ
ちょっと馬鹿すぎない?
JPQLで出来なければ迷わずSQL書けばいい
システムの大部分を占める簡単なSQLをいちいち書く方が馬鹿らしいわ
RailsのActiveRecordくらいお手軽ならそれも通じるんだが・・・
862 :
デフォルトの名無しさん:2011/10/24(月) 22:17:24.13
小規模ならそれこそActiveRecordの方がいいし、
大規模ならSQL直書きする薄いフレームワークの方が開発効率もいいし、
Hibernateほどうんこなものはないね。
フルスタックのRailsと比べたらアノテーションを付けるとこまでの準備が多少面倒ではあるけど、
その先は(言語自体の差は別として)同じくらいか、むしろ型情報が多い分Java(+IDE)の方が
楽な意味もある
大規模ならSQL直書きって…
864 :
デフォルトの名無しさん:2011/10/24(月) 22:33:17.30
>>859 具体名が全く出てこないのが不思議だなぁ
幾つか出てるけど、案件で実用には耐えられないんだろw
865 :
デフォルトの名無しさん:2011/10/24(月) 22:35:15.10
>>862 Hibernateが生成するウンコSQLに任せてたら
パフォーマンス自殺行為だからな
シビアな要求には直SQLに勝るものは無い
>>864 ツールが出力するのはあくまでも雛形みたいなものなんだから
気の済むまで手を加えればいい
それが不満なら自分で作ればいいだけの話だろ
867 :
デフォルトの名無しさん:2011/10/24(月) 22:42:58.50
>>866 開発効率を上げる為にツール導入してるのに
そのツールを自作しろとか
本末転倒も甚だしいなw
>>866 フレームワークは与えられたマッピング情報やクエリに忠実にSQLを生成するだけなんだから、
うんこSQLを生成させてるお前が悪い
チューニングまで期待しているとしたらその方がおかしい
それに更新系はむしろORMの方が効率が良い
>>867 ツールやプログラムってのはそういうもの
全く本末転倒じゃないよ
870 :
デフォルトの名無しさん:2011/10/24(月) 22:47:55.23
>>868 うんこSQLしか吐き出さないんだから
信者がいくらフォローしても無駄なんだよカス
SQL経験がある奴は、副問い合わせの取り方・順序など
書き方に工夫をするが
一方Hibernateが吐き出すウンコSQLは何も考えてない糞
とりあえず通ればいい的な糞ツールだからなw
お得意のORMマッピングがどーたらこーたらで改善してみろよカス
DDDなら素晴らしいパフォーマンスが得られるんだろw
>>870 だから、与えられた情報に忠実にSQLを生成するだけだって言ってるだろ
それが問題になる箇所は自分でSQLを書けばいいの
その割合がかなり多いなら、そもそもORMがそのシステムに向いていないか
ORMの使用を考慮したDB設計になっていない
ORMは優れたツールだけど所詮はツールだから、使うほうがうんこなら力を
発揮させることはできないってこと
872 :
デフォルトの名無しさん:2011/10/24(月) 23:13:53.15
>>871 設計をうまく出来れば何とかなるとでも思ってるのか?w
どんだけお花畑なんだよw
そもそもRDBをjavaのオブジェクトに落とし込むんだから
効率的な設計など夢のまた夢なんだよ
実際は出来上がったモデル見るとカスのようなエンティティ設計ばかり
これが現実だ
オマエラ、ホントにそのネタ好きね。
よく飽きもせずに同じ話を繰り返すわ。
>>872 おまえ見苦しいわ
それはJavaでRDBを扱う事自体を否定してるようなもんで、ORM云々とか関係ないだろ
だったら全部ストアドで書いとけよ
ほんと阿呆らしい
875 :
デフォルトの名無しさん:2011/10/24(月) 23:23:45.98
ORM信者が今日も必死に抵抗してるなw
>>874 javaでSQLを直書きすればいいだけの話を
ORMとかウダウダ言ってる時点で馬鹿丸出しだな
877 :
デフォルトの名無しさん:2011/10/24(月) 23:29:48.80
>>875 正確にはHibernate信者だなw
iBATISとか誰も否定してない。
ORM信者が作ったシステムを俺がSQL直書きでリプレイスしたら
サックサクに動くって大評判
今までのはなんだったの?って言われた。
>>875,876,877,878
おまえ見苦しいわ
880 :
デフォルトの名無しさん:2011/10/24(月) 23:36:31.47
Railsが流行り始めのころは、もっぱらHibernateとActiveRecordを比較して
「ほーらJavaはこんなに無駄だらけだけどRubyはお手軽!素晴らしい!」
って宣伝が行われまくってたくらいHibernateはうんこだからな
883 :
デフォルトの名無しさん:2011/10/25(火) 23:04:41.21
>>883 どう見てもJavaとRubyの言語の差だな
比べるなら同じ言語で比べないと
>>885 Beanまで書くならアノテーションはあった方がいいな
CoCの考え方はJavaに馴染まない
JPAのEagerとLazyはJPQLの中で操作すべきだったと思う。
Beanで設定したら融通きかないじゃん。
888 :
デフォルトの名無しさん:2011/10/27(木) 19:48:40.22
MyBatis3.0.5のSqlBuilderなんだけどさ、
public static String insertMessage(PostMessage message){
BEGIN();
INSERT_INTO("MESSAGE");
VALUES("NAME, MAIL", "${name}, ${mail}");
VALUES("MESSAGE, DAY", "${message}, ${day}");
return SQL();
}
って未実装じゃね?
889 :
デフォルトの名無しさん:2011/10/28(金) 10:18:53.65
iBATIS
全く使える気がしない
JDBCで直接書くよりも効率悪い
外部ファイルに一々SQLを書くなんてアホらしい
しかも戻りの型まで指定するとか
よけいに開発コストかかりそうだ
890 :
888:2011/10/28(金) 12:57:29.67
間違えてた…。
死にたい…。
みんなが言ってるJDBCって、SpringのJDBC?
それとも生のJDBC?
MyBatisは常に第二候補だな
柔軟で使いやすいけど第一候補としては確かに作業量が多すぎる
まぁ、素のJDBCは無いけどw
Hibernate Toolのリエンジニアリング機能は便利だのう
そのままSpringのSimpleJDBCTemplate用に使ってしまうが
鯛で海老を釣るみたいな話だなw
897 :
デフォルトの名無しさん:2011/11/04(金) 16:40:48.16
ただのシンタックスシュガーだ
そもそも主キーがないDBとかもあるのに
マッピングどうするんだ?
>>901 それはマッピング以前にサロゲートキーをつけるつけないの問題では
複合ユニーク項目があるならともかく
一意性がまったくないテーブルは怖いな
一行だけしか使わない設定テーブルとかあるだろう
主キーなんて必要の無い
ミニストップでいろいろイカちゃんグッズ売ってるなw
でも、あれを買うのはかなり敷居が高いわww
そうだ、ミニストップで深夜にバイトすればいいわw
どこの誤爆か気になる
誤爆じゃねーだろw
新参か?
ゆかちのよだれ声は天下一品
ゼロ魔のタバサの中の人が いのくちゆか(猪口有佳)
タバサの使い魔のシルフィードっていうかイルククゥの中の人が 井口 裕香(いぐちゆか)
ついでに言うと、アイマス(インベルの方)の春香は井口さんだが、
いまやってるアイマスの春香は中村檜里子さんだ。
井口は「うざかわいい」という新ジャンルを切り開いた偉大な声優
かわいいぬ
916 :
デフォルトの名無しさん:2011/12/16(金) 08:07:31.36
Hibernate信者息してる?
【ウェブアプリケーションという不幸 】
現在、多くのプログラマ(素人)がウェブアプリケーションというものがベストな正しい方向だと勘違いしている。
ソフトウェアの作るにおいてそのアプリケーションに応じた状態遷移を実装するというのは基本中の基本である。
その点においてウエブブラウザというある状態遷移が実装されているアプリケーションの上に
また別のアプリケーションを実装するのは論外である。
そこまでするなら普通にアプリケーションを実装してダウンロードして使ってもらえばいいのである。
ウェブアプリケーションとは虚構にしか他ならない。
ウェブアプリケーションを作ろうとしているあなた。
今すぐ普通のアプリケーションとし設計し始めてはいかがだろう。
そうすればきっと後悔しないですむ。
HTMLやHTTPを悪者にはしていない。
TCP/IPができあがり、その応用として、ファイルを送ったりするようになった。
ファイルの中身のテキストにデータ構造をもたせ、それはつまりツリー構造なわけだが
その実装としてのハイパーテキスト、つまりHTMLという送る側と送られる側で決め事(プロトコル)
をつくり、画像や音楽など表現の幅を広げることは当然の成り行きだっただろう。
そして、その送る側としてのHTMLファイルサーバ、つまりWebサーバ、送られる側としてのプロトコルの解釈・表示系としての
ブラウザというアプリケーション。
ここまではいい。
だが、そこから先が素人の発想というか、いそがばまわれを忘れた者の愚かな発想。
つまりブラウザ上で、アプリケーションを動かすという発想なのである。
ブラウザというのは、おくられてきたステートレスな通信内容の一瞬の表示手段でしかない。
つまりアプリケーションのためのひとつのパーツなのである。
Windowsでいえば、コントロールのひとつ。(実際WebBrowserというコントロールがある。)
JavaならWebClietnだ(これは、ブラウザではないが。)。
包含関係が逆なのである。
ブラウザ上にアプリケーションを作るのは愚かなブームである。
>>919 スマホではアプリが主流になってきたね。
正解だね。
イカ2の終了に号泣したわ。。。
イカちゃんもいいけど清美もいいなあ。。。
,, ,' ´゙ 、 、
/ ./ ヽ.\
/ /, ______ヽ \
.く / _ノ ' ヽ\ >
\/ (≡) ,(≡)\/ イカンデショ!イカンデショ!
/ " ⌒(__人__)⌒"\
| |r┬-| | ___________
\ `ー'´ / | | |
__/ \ | | |
| | / , ヽ | | |
| | / / r、 \. | | |
| | | ⌒ ーnnn |rnn⌒) |_|___________|
 ̄ \__、("二) ̄ ̄ ̄ ̄ ̄l二二l二二 _|_|__|_
JPAで同じ構造のテーブル間でデータを簡単に移動させる上手い方法って何か無いかな?
同じプロパティのエンティティビーン作ってプロパティをコピーして
別テーブルにINSERTして元データDELETEとかすごください。
フラグやコードをプロパティに追加して領域を識別するのも実装上は当然有りだけど、
自分が今どこにいるかをエンティティに持たせるってのが、やっぱダサイなと。
そもそも同じ構造のテーブル間でバケツリレーという
行為自体が根本的にスマートでない。
ファイルとの関連を持ったレコードを削除したいわけよ。
普通にやるならエンドユーザ側の削除要求はフラグ立ててコミットして返して、
バックエンドでフラグ立ってるレコードに紐付いたファイルを削除してから
レコードを削除ってのがロールバックを考慮した妥当な処理だと思うんだ。
でもそれって滅茶苦茶DB構造意識しまくりじゃん
オブジェクト指向にしたほうがいいよ
S+ エイワス
S アレイスター=クロウリー オティヌス
S− 右方のフィアンマ オッレルス
A+ ミーシャ=クロイツェフ 一方通行(天使)
A 風斬氷華
B+ インデックス アウレオルス=イザード キャーリサ(カーテナ全開) エリザード
B キャーリサ(カーテナ欠片) 後方のアックア 前方のヴェント(天罰) 騎士団長(カーテナ) 傾国の女(デュランダル) マリアン=スリンゲナイヤー(戦乱の剣)
B− 神裂火織 一方通行 マタイ=リース レイヴィニア=バードウェイ ローラ=スチュワート ブリュンヒルド=エイクトベル 騎士団長
B−−エツァリ 左方のテッラ ワシリーサ テクパトル 少女(赤い洪水) 女魔術師(ヴィーダルの靴) 垣根帝督 削板軍覇 投擲の槌 前方のヴェント(女王艦隊) サンドリヨン
C 黒夜海鳥(サイボーグ) オリアナ=トムソン 御坂美琴 麦野沈利 食蜂操祈 結標淡希 ステイル=マグヌス マーク=スペース エーラソーン ヴィース=ワインレッド ファイブオーバー EquDarkmatter ニコライ=トルストイ ビアージオ=ブゾーニ
木原病理 木原加群
C− 建宮斎字 闇咲逢魔 シェリー=クロムウェル 騎士(カーテナ) 天草式(相互強化) 幻想猛獣 レアシック リチャード=ブレイブ ベイロープ 車輪の大蛇
D+ 駒場利徳(武器あり) 駆動鎧 シルバークロース=アルファ 騎士 土御門元春(開発後) テオドシア=エレクトラ 相園 美央
D 白井黒子 絹旗最愛 黒夜海鳥 番外個体 五和 木山春生(能力有) レッサー フロリス ランシス ステファニー=ゴージャスパレス アウレオルス=ダミー カリニーチェ=I=ニーキノシ サローニャ=A=イリヴィカ マリアン=スリンゲナイヤー
D- ショチトル アニェーゼ=サンクティス サーシャ=クロイツェフ トチトリ 天草式メンバー ルチア 木原乱数 ウートガルザロキ
D-- 手塩恵未 杉谷 アニェーゼ部隊 シスターズ 服部半蔵 アンジェレネ フレイス 近江手裏 雲川鞠亜
E 海原光貴 婚后光子 釧路帷子 査楽 黄泉川愛穂 心理定規(ドレスの少女) 切斑芽美
E- 浜面仕上 郭
F 固法美偉 黒妻綿流 丘原燎多(超電磁砲原作版)実生好子
明日のスマイルイカちゃんは休みなのか・・orzまで読んだ
936 :
デフォルトの名無しさん:2012/10/10(水) 13:28:49.82
保守あげ
変なアニメの話はするなよ
iBatisからMyMatisに移行してみたが、微妙にXMLの書き方が変わってた
ハンナ・ウィンド
hanna wind
スオムス空軍飛行24戦隊所属
44末17歳、大尉
使い魔はワシミミズク
スオムス空軍二位のスーパーエース
一位は501JFW所属のユーティライネン中尉
個人携行レベルの火器であれば、拳銃から対戦車ライフルまであらゆる銃器を
器用に扱い、射撃のハンナ、回避のエイラと並び称される。
その能力から、502、503への参加要請があったが、新人の精神的中核である点と、
本人の希望によりスオムスに留まる。
弱点らしい弱点がなく、すべての要素がバランスよくまとまった、高レベルのオール
ラウンドファイター
国を、仲間を愛し、柔らかな微笑を絶やさない、優しい天才。
同24戦隊所属のカタヤイネン曹長と、容姿が瓜二つに似ている点が冗談の種にされている
が、上級将校の視察の際、人違いされたまま曹長を演じきるなど、以外とイタズラ好きな面も。
高い戦果を挙げながら問題児として扱われていたカタヤイネン曹長と、絵に
描いたような優等生であるウィンド大尉だが、互いに死線をくぐった戦友として、
強い絆で結ばれている。
http://www.ne.jp/asahi/humikane/e-wacs/wind.JPG
コミケは楽しかったかい?
一年に一度の外出()
コミケで並んでいたら、あまりにも長い時間待っている為か、
ウンコ漏らしている奴がいた・・・
もう尻が茶色、それこそ何か足元に茶色い液体が滴っていて
本人もなんか小刻みに震えていて、たまに屁もしているのか、
刺激臭が風に乗って・・・ 回りもあまりの臭さに
○←ウンコ漏らしている奴
●←一般人
先頭 ○ ○ 最後尾
○○○○ ● ○○○○○○○○○
○○○○○ ○○○○○○○○○
○ ○
こんな状態の列
さすがにやばいと思い、スタッフ呼んで「近くにトイレあるのだから行け」
と言ったが、 「いみ”ゃこごでひぎかえじたら、かえじゃないないじゃすか!」
と、日本語でおkな状態
周りからも「くせぇ」「迷惑だ」と非難の声が出始めて、
オロオロ状態、スタッフも困惑状態で、
スタッフが奴の肩に手をかけたその瞬間
その瞬間一瞬体がビクンっ!と仰け反って
「お"あ"おくぁwせdrftgyふじこlp!!」(マジ聞き取れない声)
ブウウウウウウウウウ!!!!ビチビチビチッ!と言う音とともに
奴は持っていた鞄を投げ出して、ケツを押さえながらトイレに駆け込んでいった。
無論通った後は茶色い液体・・・
一触即発とはあの事だったな、その後どうなったかは知らない。
【とある魔術と科学の週刊詳報】演じれば演じるほど、自分との距離が近くなっていく――インデックスを演じる井口裕香さんにインタビュー!
http://news.dengeki.com/elem/000/000/581/581711/ ――本作は劇場版の前日譚ということですが、劇場版でのインデックスの活躍ぶりは?
もちろんあります! 当麻に「お腹すいた」って言ってみたり、「お腹すいたー!」って言ったり、後はそうですね、「お腹すいたんだよ!」って言ってますね。
……冗談です(笑)。劇場版オリジナルキャラクターのアリサと出会い、当麻と一緒に戦っています。
954 :
デフォルトの名無しさん:2013/08/30(金) NY:AN:NY.AN
>>953 頭と体のバランスってこんなおかしかったのか・・・
やっぱり2次元に限るな。
しかしみんなSQL自分で書くのがそんなに嫌いなんかね
SQL直書きなら、可読性も修正もパフォーマンス調整も簡単にできるのに、50行近いよくわからないメソッドチェーンとかかまして、そいつが書きだされるSQLで苦しんでさ
こうするとDBに依存しないとかいうけど、趣味でも不特定多数に配布するもんでもないのに
DBを開発中に別のにしようぜ!なんて言い出すプロジェクトなんてそんな時点で破綻しきってるだろ
JDBCかmyBatisがあれば十分ってことかな?
ゆかちのシンフォギア売り切れてると思ったら棚にまだ並んでないだけだった
タイトルもキャラ名も覚えてないからかやのんのを持っていって「これの次のありますか?」って聞いたらあったわ
2013/09/30付
**9 --- *12,044 *12,044 *1 戦姫絶唱シンフォギアG キャラクターソング8 小日向未来(井口裕香)
*14 --- **6,531 **6,531 *1 Distance JUJU
*15 --- **4,842 **4,842 *1 JEALOUSNESS 朝日奈椿&梓&棗(鈴村健一&鳥海浩輔&前野智昭)
*22 --- **3,579 **3,579 *1 GENERATIONS 柿原徹也
*25 *10 **2,803 *13,664 *2 戦姫絶唱シンフォギアG キャラクターソング7 暁切歌(茅野愛衣)
*27 *26 **2,536 214,874 11 自由への進撃 Linked Horizon
*35 *45 **1,819 *13,576 *4 テニプリFEVER テニプリオールスターズ
*37 *22 **1,662 *27,669 *3 Faraway/Kiss you miwa
*38 *34 **1,651 *85,376 *6 Fight For Liberty/Wizard CLUB UVERworld
*39 *32 **1,592 *22,594 *5 サークルゲーム Galileo Galilei
*40 *19 **1,513 *23,978 *3 TVアニメ『Free!』キャラクターソング Vol.3 松岡凛(宮野真守)
*42 --- **1,487 **1,487 *1 O.P.E.N FANTASY Please(Pile)&Secret(AINA(楠田亜衣奈))
*43 *29 **1,395 *15,939 *3 戦姫絶唱シンフォギアG キャラクターソング6 雪音クリス(高垣彩陽)
*48 *41 **1,281 *52,873 *7 SPLASH FREE STYLE FIVE
*49 *21 **1,264 **4,911 *2 〜中二病奥義・三曲の極み〜 小鳥遊六花(内田真礼),Black Raison d'être,ZAQ
*53 --- **1,075 **1,075 *1 Dear friend 風間恭輔(小野大輔)
*55 *43 **1,051 **7,832 *3 ラブリンク/この空の向こう〜ドキドキ!プリキュアといっしょ〜 吉田仁美/吉田仁美・黒沢ともよ with ドキドキ!プリキュア
*57 *53 **1,027 *15,923 *4 戦姫絶唱シンフォギアG キャラクターソング5 月読調(南條愛乃)
*58 *27 **1,016 *18,862 *3 TVアニメ『Free!』キャラクターソング Vol.5 竜ヶ崎怜(平川大輔)
*60 *54 ***,999 *24,025 *5 great escape cinema staff
*62 *30 ***,918 *17,762 *3 TVアニメ『Free!』キャラクターソング Vol.4 葉月渚(代永翼)
*63 *42 ***,910 **9,075 *4 secret base 〜君がくれたもの〜 12 years after special package 本間芽衣子(茅野愛衣),安城鳴子(戸松遥),鶴見知利子(早見沙織)
ゆかち圧勝キタコレwww
_人人人人人人人人人人人人人人人_
'> 井口の時代がやってきた!!! <
 ̄^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^ ̄
___
(_) /、____\
l| / |::::::::::::::::::::::| 〉
r‐'、_ノ 厶:-v、‐:v=イゝ xく)
T⌒\ |:l '⌒ ⌒Yレく:::∧
|::::::::/ 从" 「 フ ノ:| }::::::〉
\/ }:}>rz< }:! __j/
/V:\_i/ V|V j丁\
∨レヘ:八 /::∧ {:ノ/
/ /::∧:ヘ ∨
/ /::/ '::::. '.
/ /::/ :';:::. '、
/ /::/ ';:::. ヽ
/ /::/ ';:::. ヽ
. /{. /::/ :';:::.
. \ /::/ ';:ヘ. 〉
ー─-、______j_;;j/
962 :
デフォルトの名無しさん:2014/03/01(土) 09:32:00.06
荒れてるな
Mybatisより、DBFluteの方がいいよね?
967 :
デフォルトの名無しさん:2014/03/18(火) 04:11:23.94 ID:bra5vcIi
勉強がてらspringとhibernateやってますが詰まってます
作業環境 All in one Eclipse4.2 + springmvc + hibernate4 + tomcat7 + mysql5.5
Hibernate Toolsのリバースエンジニアリングを使ってテーブルから自動生成した
Daoクラスをインスタンス化すると下のようなエラーが出て一向に解決できません
「javax.naming.NameNotFoundException: 名前 SessionFactory はこのコンテキストにバインドされていません」
何を知りたいかというとDaoクラスのSessionFactoryをtomcat側で定義したJNDIにバインドさせるには
hibernateまたはtomcatまたはspringのどのファイルのどこをどのように書けばいいか教えてください
ぼくちんの頭じゃいろいろぐぐってもわかりませんでした
よろしくおねがいします
968 :
967:2014/03/19(水) 07:58:48.72 ID:abPsgLRs
やっぱできねーなぁ。意味わからん
公式にも日本語のドキュメント置いてないし
tomcatのjndiからコンテキストは取得できるがどう頑張ってもhibernateのほうにバインドできん
ググっても同じようなエラーに遭遇してるのたくさんいるっぽいが解決できてない感じだし
やっぱhibernate糞だわ
969 :
967:2014/03/19(水) 17:26:30.63 ID:abPsgLRs
とりあえず解決
AJのハイライトはでかい女にぶつかったから「あ、すいません」て謝ったら
移動中のゆかちんで「こっちこそごめんなさい」と謝られた上に
人ごみに押されて超至近距離のゆかちんに「あ!が、頑張って下さい…」ってキモヲタ全開で言ったら
あの笑顔で会釈されて一気に推しになったところ
あれマスクとかして顔隠さないと駄目だわ
キスできる距離だったもの
声優はアイマスぐらいしか分からん
アイマス?
975
976
977
978
979