ハイベルナー学習ノート（七）
ヒップホップの中のセッション
第十一章を見て、ヒップホップの境界が分かりました。
恒久化文脈は理論上の概念である。でも、ヒップホップの中ではこれがヒップホップのSeesionになりました。
実際には、Hibernaneにも運行範囲があります。sessionからsessionまで、このセッションでは、すべてのデータが徐々に同期し、更新はHibernaneによって制御されます。対象は長い間、チューブ抜けと瞬時の3つの中間を走ります。
get CurrenntSession()Session伝播
この方法はとても便利な方法です。定義的にはseesion factoryが一つのスレッドにsessionを作成します。そしてここのスレッドでは、この方法をどこで呼び出してもそのセッションに戻ります。しかし、このセッションの文脈は彼のsessionと同じではありません。このセッションの文脈はこのsessionに従って作られたTransationの文脈です。。
この方法の最初の役割は、論理の上でより明確にすることです。もしこの方法がないなら、いくつかの方法がsessionを共有する必要がある場合、一つの方法にすべての機能が含まれているか、あるいはSessionをパラメータとして伝える必要があります。
もちろんこの方法を使う時、原子性が重要な問題だと思います。いくつかの方法が連続して働いて一つの目標を達成する時、どれぐらいの量がデータベースの中で事務を行うべきかを明確にします。
ヒップホップを使って会話します。FushMode.MANUALは時間を考えてユーザーにあげます。
ここでは、Sessionを一時的に休止状態にしておく必要があると思います。この時はseessionのflashmodeをこれにして、マネージャーに任せて管理しています。
udateとsave
ヒベルナは、オブジェクトがデータベースに挿入されるか、またはデータベースの記録を更新するかを自動的に検出します。つまり、オブジェクトが新しいか古いかを確認して、関連する草のグループを確認します。
1）識別子属性はnullである。
2）バージョンまたはタイムスタンプ属性（存在すれば）はnullです。
3）同一の耐久性クラスの新しい例（Hibernate内部で作成されたもの）は、指定されたインスタンスと同じデータベース識別子値を有する。
4）マッピングドキュメントでクラスにunsaved-valueを提供し、識別子属性の値が一致します。unsaved-value属性はバージョンとタイムスタンプマッピング要素に対しても使用できます。
5）同じ識別子値を含む死体データは、二級キャッシュにはない。
6）org.hibernate.interceptorの実装を提供し、あなた自身のコードのインスタンスを確認した後、Interceptorから。isUnsaved()はBoolean.Trueに戻ります。
孤児の削除
実は、伝播の持続化を理解したら、これはすべての操作の中で最も効率的に実現するのが難しいということが分かります。ヒベルナでは、一つのタグを使うだけで関連機能が実現できます。
締め括りをつける
前に写るように工夫してみましたので、このブロックは理解面ではあまり難しくないです。
しかし、伝播の恒久化に対しては、私に深い感銘を与えました。伝播持久とは、オブジェクトが恒久化されたり、除去されたりした後のことです。相手もそれに応じて相手をする。
これは簡単に見えるが、操作するのはかなり面倒だ。コピー中の深度コピーと浅いコピーは似たような複雑さがあります。実はコピー中です。知られているオブジェクトの深度コピーは複雑すぎないかもしれません。どんどんnewすれば問題が解決できます。
しかし、未知のオブジェクトに対しては、何もありません。私が考えている方法は反射と再帰だけです。もちろんhibernateにはxmlのドキュメントがあります。そんなに下手にしなくてもいいです。
伝播耐久化はヒベルナでカスケードといいます。オブジェクトが永続化されると、ヒベルナは自動的にオブジェクトを保存する必要があるかどうかを判断します。これは伝播の持続化と概念的な違いがある。しかし、似たような効果があります。
カスケードはいい機能だと思います。面倒なコードをたくさん減らすことができます。しかし、実際の操作では、クラスとクラスの関係が簡単でない限り、プログラマがコントロールできる基準で決定します。
ヒベルナによると。大きな作業が簡略化されました。複雑さが簡略化されました。ここで失礼します。カスケードという操作は反射を用いた。そして完全に依存すると推定される。これは性能に影響があります。大きいかもしれません。大きくないかもしれません。でも、しっかりと住めば。冒険する必要があるか？
一括更新
実はHbernateは大量更新にとって、そんなに役に立たないわけではありません。creat Query文を通じて、HQLで行うことができます。
大量の加入データについては、よく知っていると思います。Hibernateはjdbcに対して自分で書くので、問題はHibernateが大きなメモリを消費することです。利点は、複雑な関係に関心を持たないことです。
もちろんヒップホップも一定の提案を提供しています。例えばsession.flashとsession.cllearを使います。あるいはSttelessionです。
フィルタ
本の例を作ったら。フィルタを使ったら、実は生成されたsqlのwhereに条件が多くなっています。
この例を見れば分かります。設定と生成のsql文
ヒベルナの事件、ブロック。
デザインはjavaの既存のイベントモデルと変わらないと思います。でも想像すると、基本的にはこのようなmvcのパターンです。
ここはこれから実際の状況に会って書くつもりです。こんなことばかり言っているから、本を読むほうがいいです。
第十一章を見て、ヒップホップの境界が分かりました。
恒久化文脈は理論上の概念である。でも、ヒップホップの中ではこれがヒップホップのSeesionになりました。
実際には、Hibernaneにも運行範囲があります。sessionからsessionまで、このセッションでは、すべてのデータが徐々に同期し、更新はHibernaneによって制御されます。対象は長い間、チューブ抜けと瞬時の3つの中間を走ります。
get CurrenntSession()Session伝播
この方法はとても便利な方法です。定義的にはseesion factoryが一つのスレッドにsessionを作成します。そしてここのスレッドでは、この方法をどこで呼び出してもそのセッションに戻ります。しかし、このセッションの文脈は彼のsessionと同じではありません。このセッションの文脈はこのsessionに従って作られたTransationの文脈です。。
この方法の最初の役割は、論理の上でより明確にすることです。もしこの方法がないなら、いくつかの方法がsessionを共有する必要がある場合、一つの方法にすべての機能が含まれているか、あるいはSessionをパラメータとして伝える必要があります。
もちろんこの方法を使う時、原子性が重要な問題だと思います。いくつかの方法が連続して働いて一つの目標を達成する時、どれぐらいの量がデータベースの中で事務を行うべきかを明確にします。
ヒップホップを使って会話します。FushMode.MANUALは時間を考えてユーザーにあげます。
ここでは、Sessionを一時的に休止状態にしておく必要があると思います。この時はseessionのflashmodeをこれにして、マネージャーに任せて管理しています。
udateとsave
ヒベルナは、オブジェクトがデータベースに挿入されるか、またはデータベースの記録を更新するかを自動的に検出します。つまり、オブジェクトが新しいか古いかを確認して、関連する草のグループを確認します。
1）識別子属性はnullである。
2）バージョンまたはタイムスタンプ属性（存在すれば）はnullです。
3）同一の耐久性クラスの新しい例（Hibernate内部で作成されたもの）は、指定されたインスタンスと同じデータベース識別子値を有する。
4）マッピングドキュメントでクラスにunsaved-valueを提供し、識別子属性の値が一致します。unsaved-value属性はバージョンとタイムスタンプマッピング要素に対しても使用できます。
5）同じ識別子値を含む死体データは、二級キャッシュにはない。
6）org.hibernate.interceptorの実装を提供し、あなた自身のコードのインスタンスを確認した後、Interceptorから。isUnsaved()はBoolean.Trueに戻ります。
孤児の削除
実は、伝播の持続化を理解したら、これはすべての操作の中で最も効率的に実現するのが難しいということが分かります。ヒベルナでは、一つのタグを使うだけで関連機能が実現できます。
締め括りをつける
前に写るように工夫してみましたので、このブロックは理解面ではあまり難しくないです。
しかし、伝播の恒久化に対しては、私に深い感銘を与えました。伝播持久とは、オブジェクトが恒久化されたり、除去されたりした後のことです。相手もそれに応じて相手をする。
これは簡単に見えるが、操作するのはかなり面倒だ。コピー中の深度コピーと浅いコピーは似たような複雑さがあります。実はコピー中です。知られているオブジェクトの深度コピーは複雑すぎないかもしれません。どんどんnewすれば問題が解決できます。
しかし、未知のオブジェクトに対しては、何もありません。私が考えている方法は反射と再帰だけです。もちろんhibernateにはxmlのドキュメントがあります。そんなに下手にしなくてもいいです。
伝播耐久化はヒベルナでカスケードといいます。オブジェクトが永続化されると、ヒベルナは自動的にオブジェクトを保存する必要があるかどうかを判断します。これは伝播の持続化と概念的な違いがある。しかし、似たような効果があります。
カスケードはいい機能だと思います。面倒なコードをたくさん減らすことができます。しかし、実際の操作では、クラスとクラスの関係が簡単でない限り、プログラマがコントロールできる基準で決定します。
ヒベルナによると。大きな作業が簡略化されました。複雑さが簡略化されました。ここで失礼します。カスケードという操作は反射を用いた。そして完全に依存すると推定される。これは性能に影響があります。大きいかもしれません。大きくないかもしれません。でも、しっかりと住めば。冒険する必要があるか？
一括更新
実はHbernateは大量更新にとって、そんなに役に立たないわけではありません。creat Query文を通じて、HQLで行うことができます。
大量の加入データについては、よく知っていると思います。Hibernateはjdbcに対して自分で書くので、問題はHibernateが大きなメモリを消費することです。利点は、複雑な関係に関心を持たないことです。
もちろんヒップホップも一定の提案を提供しています。例えばsession.flashとsession.cllearを使います。あるいはSttelessionです。
フィルタ
本の例を作ったら。フィルタを使ったら、実は生成されたsqlのwhereに条件が多くなっています。
<filter name="RankLimit"
condition=":currentUserLink
>= (select i.rank from session_item i
where i.type_id=TYPE_ID)"></filter>
<!-- sql
select
item0_.TYPE_ID as TYPE1_37_,
item0_.LAST_UPDATED as LAST2_37_,
item0_.description as descript3_37_,
item0_.active as active37_,
item0_.rank as rank37_
from
SESSION_ITEM item0_
where
? >= (
select
i.rank
from
session_item i
where
i.type_id=item0_.TYPE_ID
)
-->この例を見れば分かります。設定と生成のsql文
ヒベルナの事件、ブロック。
デザインはjavaの既存のイベントモデルと変わらないと思います。でも想像すると、基本的にはこのようなmvcのパターンです。
ここはこれから実際の状況に会って書くつもりです。こんなことばかり言っているから、本を読むほうがいいです。