Friday, May 23, 2008

HIBERNATE - Relational Persistence for Idiomatic Java - 17

HIBERNATE - Relational Persistence for Idiomatic Java
Hibernate Reference Documentation
Hibernateレファレンスドキュメンテーション
3.2.2

Table of Contents(コンテンツテーブル)
Preface(序文)
1. Introduction to Hibernate(Hibernateの紹介)
2. Architecture(アーキテクチャ)
3. Configuration(設定)
4. Persistent Classes(永続クラス)
5. Basic O/R Mapping(基本的なO/Rマッピング)
6. Collection Mapping(コレクションのマッピング)
7. Association Mappings(関連マッピング)
8. Component Mapping(コンポーネントマッピング)
9. Inheritance Mapping(継承マッピング)
10. Working with objects(オブジェクトを扱う)
11. Transactions And Concurrency(トランザクションと並行性)
12. Interceptors and events(インターセプタとイベント)
13. Batch processing(バッチ処理)
14. HQL: The Hibernate Query Language(HQL : Hibernateクエリ言語)
15. Criteria Queries(Criteriaクエリ)
16. Native SQL(ネイティブSQL)
17. Filtering data(データのフィルタリング)
17.1. Hibernate filters(Hibernateのフィルタ)

Chapter 17. Filtering data(17章:データのフィルタリング)
Hibernate3 provides an innovative new approach to handling data with "visibility" rules. A Hibernate filter is a global, named, parameterized filter that may be enabled or disabled for a particular Hibernate session.
Hibernate3では「可視性」ルールに基づいてデータを扱うための画期的な方法を用意しています。Hibernate filter はグローバルで、名前付きで、パラメータ化されたフィルタです。これはHibernateセッションごとに有効無効を切り替えられます。
17.1. Hibernate filters(Hibernateのフィルタ)
Hibernate3 adds the ability to pre-define filter criteria and attach those filters at both a class and a collection level. A filter criteria is the ability to define a restriction clause very similiar to the existing "where" attribute available on the class and various collection elements. Except these filter conditions can be parameterized. The application can then make the decision at runtime whether given filters should be enabled and what their parameter values should be. Filters can be used like database views, but parameterized inside the application.
Hibernate3はフィルタクライテリアをあらかじめ定義し、これらのフィルタをクラスやコレクションレベルに加える機能を加えました。フィルタクライテリアは制約節を定義する機能です。これらのフィルタ条件はパラメータ化できるということを除き、クラスやさまざまなコレクション要素で利用可能な「where」句に非常によく似ています。アプリケーションは、与えられたフィルタを可能にすべきか、そしてそのパラメータ値を何にすべきかを実行時に決定することができます。フィルタはデータベースビューのように使用されますが、アプリケーション内ではパラメータ化されます。
In order to use filters, they must first be defined and then attached to the appropriate mapping elements. To define a filter, use the <filter-def/> element within a<hibernate-mapping/> element:
フィルタを使うためにはまず、適切なマッピング要素に定義、追加しなくてはなりません。 フィルタを定義するためには、 <hibernate-mapping/> 要素内で <filter-def/> 要素を使用します。:
<filter-def name="myFilter">
    <filter-param name="myFilterParam" type="string"/>
</filter-def>
Then, this filter can be attached to a class:
そうしてフィルタはクラスへと結び付けられます。:
<class name="myClass" ...>
    ...
    <filter name="myFilter" condition=":myFilterParam = MY_FILTERED_COLUMN"/>
</class>
or, to a collection:
また、コレクションに対しては次のようになります。:
<set ...>
    <filter name="myFilter" condition=":myFilterParam = MY_FILTERED_COLUMN"/>
</set>
or, even to both (or multiples of each) at the same time.
どちらに対しても(また、それぞれを複数)同時に設定することもできます。
The methods on Session are: enableFilter(String filterName)getEnabledFilter(String filterName), and disableFilter(String filterName). By default, filters are not enabled for a given session; they must be explcitly enabled through use of theSession.enabledFilter() method, which returns an instance of the Filter interface. Using the simple filter defined above, this would look like:
Session 上のメソッドは enableFilter(String filterName),getEnabledFilter(String filterName), disableFilter(String filterName) です。デフォルトでは、フィルタは与えられたセッションに対して使用 できません Filter インスタンスを返り値とするSession.enabledFilter() メソッドを使うことで、フィルタは明示的に使用可能となります。上で定義した単純なフィルタの使用は、このようになります:
session.enableFilter("myFilter").setParameter("myFilterParam", "some-value");
Note that methods on the org.hibernate.Filter interface do allow the method-chaining common to much of Hibernate.
org.hibernate.Filterインターフェイスのメソッドは、Hibernateの多くに共通しているメソッド連鎖を許していることに注意してください。
A full example, using temporal data with an effective record date pattern:
有効なレコードデータパターンを持つ一時データを使った完全な例です:
<filter-def name="effectiveDate">
    <filter-param name="asOfDate" type="date"/>
</filter-def>

<class name="Employee" ...>
...
    <many-to-one name="department" column="dept_id" class="Department"/>
    <property name="effectiveStartDate" type="date" column="eff_start_dt"/>
    <property name="effectiveEndDate" type="date" column="eff_end_dt"/>
...
    <!--
        Note that this assumes non-terminal records have an eff_end_dt set to
        a max db date for simplicity-sake
    -->
    <filter name="effectiveDate"
            condition=":asOfDate BETWEEN eff_start_dt and eff_end_dt"/>
</class>

<class name="Department" ...>
...
    <set name="employees" lazy="true">
        <key column="dept_id"/>
        <one-to-many class="Employee"/>
        <filter name="effectiveDate"
                condition=":asOfDate BETWEEN eff_start_dt and eff_end_dt"/>
    </set>
</class>
Then, in order to ensure that you always get back currently effective records, simply enable the filter on the session prior to retrieving employee data:
常に現在の有効レコードを返却することを保証するために、単純に、社員データの検索より前にセッション上のフィルタを有効にします。
Session session = ...;
session.enabledFilter("effectiveDate").setParameter("asOfDate", new Date());
List results = session.createQuery("from Employee as e where e.salary > :targetSalary")
         .setLong("targetSalary", new Long(1000000))
         .list();
In the HQL above, even though we only explicitly mentioned a salary constraint on the results, because of the enabled filter the query will return only currently active employees who have a salary greater than a million dollars.
上記のHQLでは、結果の給料の制約について明示的に触れただけですが、有効になっているフィルタのおかげで、このクエリは給料が100万ドル以上の現役の社員だけを返します。
Note: if you plan on using filters with outer joining (either through HQL or load fetching) be careful of the direction of the condition expression. Its safest to set this up for left outer joining; in general, place the parameter first followed by the column name(s) after the operator.
(HQLかロードフェッチで)外部結合を持つフィルタを使うつもりなら、条件式の方向に注意してください。これは左外部結合のために設定するのが最も安全です。一般的に、演算子の後カラム名に続けて最初のパラメータを配置してください。
After being defined a filter might be attached to multiple entities and/or collections each with its own condition. That can be tedious when the conditions are the same each time. Thus <filter-def/> allows defining a default condition, either as an attribute or CDATA:
フィルタの定義された後に、複数のエンティティと各コレクションと持ったコンディションと添付されます。コンディションが何回も同じだったら退屈でしょう。<filter-def/>は特質またはCDATAとして、デフォルトのコンディションの定義を許可します。
<filter-def name="myFilter" condition="abc > xyz">...</filter-def>
<filter-def name="myOtherFilter">abc=xyz</filter-def>
This default condition will then be used whenever the filter is attached to something without specifying a condition. Note that this means you can give a specific condition as part of the attachment of the filter which overrides the default condition in that particular case.
このディフォルトのコンディションはエンティティまたはコレクションとコンディションを明確にしていないときに添付されるときに使われます。という意味は、添付フィルタにコンディションを明確に定義することが出来、これはデフォルトのコンディションにオーバーライドします。

No comments:

Post a Comment