abblog: HIBERNATE - Relational Persistence for Idiomatic Java

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マッピング)

5.1. Mapping declaration(マッピング定義)

5.1.1. Doctype

5.1.1.1. EntityResolver

5.1.2. hibernate-mapping

5.1.3. class

5.1.4. id

5.1.4.1. Generator

5.1.4.2. Hi/lo algorithm(Hi/Loアルゴリズム)

5.1.4.3. UUID algorithm(UUIDアルゴリズム)

5.1.4.4. Identity columns and sequences()識別子カラムとシーケンス

5.1.4.5. Assigned identifiers(識別子の割り当て)

5.1.4.6. Primary keys assigned by triggers(トリガーにより割り当てられた主キー)

5.1.5. composite-id

5.1.6. discriminator

5.1.7. version (optional)

5.1.8. timestamp (optional)

5.1.9. property

5.1.10. many-to-one

5.1.11. one-to-one

5.1.12. natural-id

5.1.13. component, dynamic-component

5.1.14. properties

5.1.15. subclass

5.1.16. joined-subclass

5.1.17. union-subclass

5.1.18. join

5.1.19. key

5.1.20. column and formula elements

5.1.21. import

5.1.22. any

5.2. Hibernate Types(Hibernateの型)

5.2.1. Entities and values(エンティティと値)

5.2.2. Basic value types(基本的な型)

5.2.3. Custom value types(カスタム型)

5.3. Mapping a class more than once(1つのクラスに１つ以上のマッピング)

5.4. SQL quoted identifiers

5.5. Metadata alternatives(メタデータの代替手段)

5.5.1. Using XDoclet markup(XDoclet マークアップの使用)

5.5.2. Using JDK 5.0 Annotations(JDK 5.0 アノテーションの使用)

5.6. Generated Properties(生成プロパティ)

5.7. Auxiliary Database Objects(補助的なデータベース・オブジェクト)

Chapter 5. Basic O/R Mapping(第5章：基本的なO/Rマッピング)

5.1. Mapping declaration(マッピング定義)

Object/relational mappings are usually defined in an XML document. The mapping document is designed to be readable and hand-editable. The mapping language is Java-centric, meaning that mappings are constructed around persistent class declarations, not table declarations.

オブジェクト/リレーショナルマッピングは通常XMLドキュメントで定義します。マッピングドキュメントは、読みやすく手作業で編集しやすいようにデザインされています。マッピング言語はJava中心、つまりテーブル定義ではなく永続クラスの定義に基づいて構築されています。

Note that, even though many Hibernate users choose to write the XML by hand, a number of tools exist to generate the mapping document, including XDoclet, Middlegen and AndroMDA.

多くのHibernateユーザはXMLマッピングの記述を手作業で行いますが、XDoclet, Middlegen, AndroMDAというようなマッピングドキュメントを生成するツールがいくつか存在します。

Lets kick off with an example mapping:

サンプルのマッピングからはじめましょう。

<?xml version="1.0"?>

<!DOCTYPE hibernate-mapping PUBLIC

"-//Hibernate/Hibernate Mapping DTD 3.0//EN"

"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping package="eg">

<class name="Cat"

table="cats"

discriminator-value="C">

</id>

<discriminator column="subclass"

type="character"/>

<property name="birthdate"

type="date"

not-null="true"

update="false"/>

<property name="color"

type="eg.types.ColorUserType"

not-null="true"

update="false"/>

<property name="sex"

not-null="true"

update="false"/>

<property name="litterId"

column="litterId"

update="false"/>

<many-to-one name="mother"

column="mother_id"

update="false"/>

<set name="kittens"

inverse="true"

order-by="litter_id">

<one-to-many class="Cat"/>

</set>

<subclass name="DomesticCat"

discriminator-value="D">

<property name="name"

type="string"/>

</subclass>

</class>

</class>

</hibernate-mapping>

We will now discuss the content of the mapping document. We will only describe the document elements and attributes that are used by Hibernate at runtime. The mapping document also contains some extra optional attributes and elements that affect the database schemas exported by the schema export tool. (For example the not-nullattribute.)

マッピングドキュメントの内容を説明します。ただし、ここではHibernateが実行時に使うドキュメント要素と属性についてのみ説明します。マッピングドキュメントは、いくつかのオプション属性と要素を含んでいます（例えばnot-null属性）。それらはスキーマエクスポートツールが出力するデータベーススキーマに影響を与えるものです。

5.1.1. Doctype(Doctype)

All XML mappings should declare the doctype shown. The actual DTD may be found at the URL above, in the directory hibernate-x.x.x/src/org/hibernate or in hibernate3.jar. Hibernate will always look for the DTD in its classpath first. If you experience lookups of the DTD using an Internet connection, check your DTD declaration against the contents of your claspath.

XMLマッピングでは、お見せしたようなドキュメント型を必ず定義すべきです。実際のDTDは、上記のURLのhibernate-x.x.x/src/org/hibernateディレクトリ、またはhibernate.jar内にあります。Hibernateは常に、そのクラスパス内でDTDを探し始めます。インターネットにあるDTDファイルを探そうとしたなら、クラスパスの内容を見て、DTD宣言を確認してください。

5.1.1.1. EntityResolver(EntityResolver)

As mentioned previously, Hibernate will first attempt to resolve DTDs in its classpath. The manner in which it does this is by registering a custom org.xml.sax.EntityResolverimplementation with the SAXReader it uses to read in the xml files. This customEntityResolver recognizes two different systemId namespaces.

前述したように、Hibernateはまずクラスパス内でDTDを解決しようとします。org.xml.sax.EntityResolverのカスタム実装をXMLファイルを読み込むためのSAXReaderに登録することによって、DTDを解決します。このカスタムのEntityResolverは2つの異なるシステムID名前空間を認識します。

? a hibernate namespace is recognized whenever the resolver encounteres a systemId starting with http://hibernate.sourceforge.net/; the resolver attempts to resolve these entities via the classlaoder which loaded the Hibernate classes.

Hibernate名前空間は、リゾルバがhttp://hibernate.sourceforge.net/で始まるシステムIDに到達したときに、認識されます。そしてリゾルバは、Hibernateのクラスをロードしたクラスローダを用いて、これらのエンティティを解決しようとします。

? a user namespace is recognized whenever the resolver encounteres a systemId using a classpath:// URL protocol; the resolver will attempt to resolve these entities via (1) the current thread context classloader and (2) the classloader which loaded the Hibernate classes.

ユーザ名前空間は、リゾルバがURLプロトコルのclasspath://を使ったシステムIDに到達したときに、認識されます。そしてリゾルバは、(1)カレントスレッドのコンテキストクラスローダー、または(2)Hibernateのクラスをロードしたクラスローダを使って、これらのエンティティを解決しようとします。

An example of utilizing user namespacing:

下記は、ユーザ名空間を使った例です。

<?xml version="1.0"?>

<!DOCTYPE hibernate-mapping PUBLIC

"-//Hibernate/Hibernate Mapping DTD 3.0//EN"

"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd" [

<!ENTITY types SYSTEM "classpath://your/domain/types.xml">

<hibernate-mapping package="your.domain">

...

</id>

<class>

&types;

</hibernate-mapping>

Where types.xml is a resource in the your.domain package and contains a customSection 5.2.3, "Custom value types".

ここでtypes.xmlはyour.domainパッケージ内のリソースであり、カスタムSection 5.2.3, "Custom value types"を含みます。

5.1.2. hibernate-mapping

This element has several optional attributes. The schema and catalog attributes specify that tables referred to in this mapping belong to the named schema and/or catalog. If specified, tablenames will be qualified by the given schema and catalog names. If missing, tablenames will be unqualified. The default-cascade attribute specifies what cascade style should be assumed for properties and collections which do not specify acascade attribute. The auto-import attribute lets us use unqualified class names in the query language, by default.

この要素にはいくつかオプション属性があります。schema属性とcatalog属性は、このマッピングが参照するテーブルが、この属性によって指定されたスキーマと(または)カタログに属することを指定します。この属性が指定されると、テーブル名は与えられたスキーマ名とカタログ名で修飾されます。これらの属性が指定されていなければ、テーブル名は修飾されません。default-cascade属性は、cascade属性を指定していないプロパティやコレクションに、どのカスケードスタイルを割り当てるかを指定します。auto-import属性は、クエリ言語内で修飾されていないクラス名を、デフォルトで使えるようにします。

<hibernate-mapping

schema="schemaName" (1)

catalog="catalogName" (2)

default-cascade="cascade_style" (3)

default-access="field|property|ClassName" (4)

default-lazy="true|false" (5)

auto-import="true|false" (6)

package="package.name" (7)

(1)	schema (optional): The name of a database schema. (データベースのスキーマ名)
(2)	catalog (optional): The name of a database catalog. (データベースのカタログ名)
(3)	default-cascade (optional - defaults to none)(オプション - ディフォルトはNone): A default cascade style. (ディフォルトのカスケードスタイル)
(4)	default-access (optional - defaults to property)(オプション - ディフォルトはproperty): The strategy Hibernate should use for accessing all properties. Can be a custom implementation of PropertyAccessor. (Hibernateがプロパティにアクセスする際に採るべき戦略。PropertyAccessorを実装することでカスタマイズ可能。)
(5)	default-lazy (optional - defaults to true)(オプション - ディフォルトはtrue): The default value for unspecifed lazy attributes of class and collection mappings. (lazy属性が指定されていないクラスやコレクションマッピングに対するデフォルト値。)
(6)	auto-import (optional - defaults to true)(オプション - ディフォルトはtue): Specifies whether we can use unqualified class names (of classes in this mapping) in the query language. (クエリ言語内で、（このマッピング内のクラスの）修飾されていないクラス名を使えるかどうかを指定します。)
(7)	package (optional)(オプション): Specifies a package prefix to assume for unqualified class names in the mapping document. (package(オプション): マッピングドキュメント内で修飾されていないクラス名に対して割り当てる、パッケージの接頭辞(prefix)を指定します。)

If you have two persistent classes with the same (unqualified) name, you should setauto-import="false". Hibernate will throw an exception if you attempt to assign two classes to the same "imported" name.

（修飾されていない）同じ名前の永続クラスが2つあるなら、auto-import="false"を設定すべきです。 2つのクラスに"インポートされた"同じ名前を割り当てようとすると、Hibernateは例外を投げます。

Note that the hibernate-mapping element allows you to nest several persistent <class>mappings, as shown above. It is however good practice (and expected by some tools) to map only a single persistent class (or a single class hierarchy) in one mapping file and name it after the persistent superclass, e.g. Cat.hbm.xml, Dog.hbm.xml, or if using inheritance, Animal.hbm.xml.

hibernate-mapping要素は、最初の例で示したようにいくつかの永続<class>マッピングをネストできます。しかし、１つのマッピングファイルではただひとつの永続クラス(またはひとつのクラス階層)にマッピングするようにし、さらに永続スーパークラスの後で指定するべきでしょう(いくつかのツールはこのようなマッピングファイルを想定しています)。例えば次のようになります。：Cat.hbm.xml,Dog.hbm.xml, または継承を使うならAnimal.hbm.xml。

5.1.3. class(クラス)

You may declare a persistent class using the class element:

class要素を使って、永続クラスを宣言できます。

<class

name="ClassName" (1)

table="tableName" (2)

discriminator-value="discriminator_value" (3)

mutable="true|false" (4)

schema="owner" (5)

catalog="catalog" (6)

proxy="ProxyInterface" (7)

dynamic-update="true|false" (8)

dynamic-insert="true|false" (9)

select-before-update="true|false" (10)

polymorphism="implicit|explicit" (11)

where="arbitrary sql where condition" (12)

persister="PersisterClass" (13)

batch-size="N" (14)

optimistic-lock="none|version|dirty|all" (15)

lazy="true|false" (16)

entity-name="EntityName" (17)

check="arbitrary sql check condition" (18)

rowid="rowid" (19)

subselect="SQL expression" (20)

abstract="true|false" (21)

node="element-name"

(1)	name (optional)(オプション): The fully qualified Java class name of the persistent class (or interface). If this attribute is missing, it is assumed that the mapping is for a non-POJO entity. (永続クラス（またはインターフェイス）の完全修飾Javaクラス名。もしこの属性を指定しなければ、POJOではないエンティティに対するマッピングとして扱われます。)
(2)	table (optional - defaults to the unqualified class name)(オプション - デフォルトは修飾されていないクラス名): The name of its database table. (データベーステーブル名)
(3)	discriminator-value (optional - defaults to the class name): A value that distiguishes individual subclasses, used for polymorphic behaviour. Acceptable values include null and not null. (ポリモーフィックな振る舞いに使われる個々のサブクラスを識別するための値。値はnullかnot nullのいずれかを取ります。)
(4)	mutable (optional, defaults to true)(オプション - デフォルトはtrue): Specifies that instances of the class are (not) mutable. (そのクラスのインスタンスが更新可能（または不可能）であることを指定します。)
(5)	schema (optional)(オプション): Override the schema name specified by the root <hibernate-mapping> element. (ルートのhibernate-mapping要素で指定されたスキーマ名をオーバーライドします。)
(6)	catalog (optional)(オプション): Override the catalog name specified by the root <hibernate-mapping> element. (ルートのhibernate-mapping要素で指定されたカタログ名をオーバーライドします。)
(7)	proxy (optional)(オプション): Specifies an interface to use for lazy initializing proxies. You may specify the name of the class itself. (遅延初期化プロキシに使うインターフェイスを指定します。永続化するクラス名そのものを指定することも可能です。)
(8)	dynamic-update (optional, defaults to false)(オプション - デフォルトはfalse): Specifies that UPDATE SQL should be generated at runtime and contain only those columns whose values have changed. (値が変更されたカラムだけを含むSQLのUPDATE文を、実行時に生成することを指定します。)
(9)	dynamic-insert (optional, defaults to false)(オプション - デフォルトはfalse): Specifies that INSERT SQL should be generated at runtime and contain only the columns whose values are not null. (値がnullではないカラムだけを含むSQLのINSERT文を、実行時に生成することを指定します。)
(10)	select-before-update (optional, defaults to false) (オプション - デフォルトはfalse): Specifies that Hibernate should never perform an SQL UPDATE unless it is certain that an object is actually modified. In certain cases (actually, only when a transient object has been associated with a new session using update()), this means that Hibernate will perform an extra SQL SELECT to determine if an UPDATE is actually required. (select-before-update(オプション, デフォルトはfalse): オブジェクトが変更されたのが確実でないならば、HibernateがSQLのUPDATEを決して実行しないことを指定します。ある特定の場合(実際的には、一時オブジェクトがupdate()を使い、新しいセッションと関連付けられた時だけ)、UPDATEが実際に必要かどうかを決定するために、Hibernateが余分なSQLのSELECT文を実行することを意味します。)
(11)	polymorphism (optional, defaults to implicit) (オプション - デフォルトはimplicit): Determines whether implicit or explicit query polymorphism is used. (implicit（暗黙）かexplicit（明示）の、どちらのクエリポリモーフィズムを使うか決定します。)
(12)	where (optional)(オプション)specify an arbitrary SQL WHERE condition to be used when retrieving objects of this class (このクラスのオブジェクトを検索するときに使用する、任意のSQLのWHERE 条件を指定します。)
(13)	persister (optional)(オプション): Specifies a custom ClassPersister. (カスタムClassPersisterを指定します。)
(14)	batch-size (optional, defaults to 1) (オプション - デフォルトは1) specify a "batch size" for fetching instances of this class by identifier. (識別子でこのクラスのインスタンスを復元するときの「バッチサイズ」を指定します。)
(15)	optimistic-lock (optional, defaults to version) (オプション - デフォルトはversion): Determines the optimistic locking strategy. (楽観ロック戦略を決定します。)
(16)	lazy (optional)(オプション): Lazy fetching may be completely disabled by setting lazy="false". (lazy="false"と設定することで、遅延フェッチができなくなります。)
(17)	entity-name (optional, defaults to the class name) (オプション - デフォルトはクラス名): Hibernate3 allows a class to be mapped multiple times (to different tables, potentially), and allows entity mappings that are represented by Maps or XML at the Java level. In these cases, you should provide an explicit arbitrary name for the entity. See Section 4.4, "Dynamic models" andChapter 18, XML Mapping for more information. (Hibernate3ではクラスが複数回マッピングでき（場合によっては違うテーブルに対しても）、JavaレベルでMapやXMLで表現されるエンティティマッピングが可能です。これらの場合、エンティティに対して任意の名前を、明示的に付けなくてはなりません。詳しくはSection 4.4, "Dynamic models"とChapter 18, XML Mappingを参照してください。)
(18)	check (optional)(オプション): A SQL expression used to generate a multi-row check constraint for automatic schema generation. (check（オプション）：自動的にスキーマを生成するために、複数行のcheck制約を生成するSQL式。)
(19)	rowid (optional)(オプション): Hibernate can use so called ROWIDs on databases which support. E.g. on Oracle, Hibernate can use the rowid extra column for fast updates if you set this option to rowid. A ROWID is an implementation detail and represents the physical location of a stored tuple. (Hibernateは、それをサポートしているデータベースでROWIDと呼ばれるものを使うことができます。例えばOracleを使っているとき、このオプションにrowidを設定すれば、Hiberanteはupdateを高速化するためにrowidという特別なカラムを使うことができます。ROWIDは詳細な実装であり、保存されたタプルの物理的な位置を表しています。)
(20)	subselect (optional)(オプション): Maps an immutable and read-only entity to a database subselect. Useful if you want to have a view instead of a base table, but don't. See below for more information. (不変かつ読み取り専用であるエンティティをデータベースの副問合せ（subselect）にマッピングします。もし元のテーブルの代わりにビューを持ちたければ有用ですが、そうでないのなら有用ではありません。より詳しい情報は下記を参照してください。)
(21)	abstract (optional)(オプション): Used to mark abstract superclasses in <union-subclass> hierarchies. (union-subclass階層内の抽象スーパークラスにマークするために使います。)

It is perfectly acceptable for the named persistent class to be an interface. You would then declare implementing classes of that interface using the <subclass> element. You may persist any static inner class. You should specify the class name using the standard form ie. eg.Foo$Bar.

永続クラスの名前にインターフェイスを指定してもまったく問題ありません。そのときは<subclass>要素を使って、そのインターフェイスを実装するクラスを定義してください。staticな内部クラスでも永続化できます。そのときは標準形式、例えばeg.Foo$Barを使ってクラス名を指定してください。

Immutable classes, mutable="false", may not be updated or deleted by the application. This allows Hibernate to make some minor performance optimizations.

mutable="false"指定をした不変クラスは、アプリケーションによる更新や削除が出来ないことがあります。これにより、Hibernateがパフォーマンスを少し改善します。

The optional proxy attribute enables lazy initialization of persistent instances of the class. Hibernate will initially return CGLIB proxies which implement the named interface. The actual persistent object will be loaded when a method of the proxy is invoked. See "Proxies for Lazy Initialization" below.

オプションのproxy属性により、クラスの永続インスタンスの遅延初期化が可能になります。Hibernateは最初に、指定したインターフェイスを実装したCGLIBプロキシを返します。実際の永続オブジェクトはプロキシのメソッドを呼び出すときにロードします。以下の「遅延初期化のためのプロキシ」を参照してください。

Implicit polymorphism means that instances of the class will be returned by a query that names any superclass or implemented interface or the class and that instances of any subclass of the class will be returned by a query that names the class itself. Explicitpolymorphism means that class instances will be returned only by queries that explicitly name that class and that queries that name the class will return only instances of subclasses mapped inside this <class> declaration as a <subclass> or <joined-subclass>. For most purposes the default, polymorphism="implicit", is appropriate. Explicit polymorphism is useful when two different classes are mapped to the same table (this allows a "lightweight" class that contains a subset of the table columns).

暗黙的ポリモーフィズムとは、次の二つを意味しています。一つはクラスのインスタンスが、スーパークラスや実装したインターフェイス、またそのクラスを指定するクエリによって返されることで、もう一つはそのクラスのサブクラスのインスタンスが、そのクラス自身を指定したクエリによって返されることです。また、明示的ポリモーフィズムとは、次の二つを意味しています。一つはクラスのインスタンスが、そのクラスを明示的に指定したクエリによってのみ返されることで、もう一つはクラスを指定したクエリが、class要素の中でsubclassや joined-subclassとマッピングされているサブクラスのインスタンスだけを返すことです。ほとんどの用途ではデフォルトのpolymorphism="implicit"が適切です。明示的なポリモーフィズムは、2つの違ったクラスが同じテーブルにマッピングされているときに有用です（これによってテーブルカラムのサブセットを含む、「軽量な」クラスが可能になります）。

The persister attribute lets you customize the persistence strategy used for the class. You may, for example, specify your own subclass oforg.hibernate.persister.EntityPersister or you might even provide a completely new implementation of the interface org.hibernate.persister.ClassPersister that implements persistence via, for example, stored procedure calls, serialization to flat files or LDAP. See org.hibernate.test.CustomPersister for a simple example (of "persistence" to aHashtable).

persister属性を指定することで、クラスの永続化戦略をカスタマイズできます。例えばorg.hibernate.persister.EntityPersister自身のサブクラスを指定したり、また例えばストアドプロシージャコール、フラットファイルへシリアライズ、LDAPなどを通した永続性を実装するorg.hibernate.persister.ClassPersisterインターフェイスの完全に新しい実装を提供できます。簡単な例としてorg.hibernate.test.CustomPersisterを見てください（これはHashtableの「永続化」です）。

Note that the dynamic-update and dynamic-insert settings are not inherited by subclasses and so may also be specified on the <subclass> or <joined-subclass> elements. These settings may increase performance in some cases, but might actually decrease performance in others. Use judiciously.

dynamic-updateとdynamic-insertの設定はサブクラスに継承されません。そのためsubclassやjoined-subclass要素を指定することも出来ます。これらの設定はパフォーマンスを向上させる事もありますが、落とすこともありますので、慎重に使用してください。

Use of select-before-update will usually decrease performance. It is very useful to prevent a database update trigger being called unnecessarily if you reattach a graph of detached instances to a Session.

select-before-updateの使用は通常パフォーマンスを落とします。もしSessionへ分離インスタンスのグラフを再追加するなら、データベース更新のトリガを不必要に呼び出すのを避けるという点で、非常に有用です。

If you enable dynamic-update, you will have a choice of optimistic locking strategies:

dynamic-updateを有効にすれば、楽観ロック戦略を選ぶことになります。

? version check the version/timestamp columns

versionはバージョン/タイムスタンプカラムをチェックします

? all check all columns

allはすべてのカラムをチェックします。

? dirty check the changed columns, allowing some concurrent updates

dirtyは変更したカラムをチェックし、同時更新できるようにします。

? none do not use optimistic locking

none楽観ロックを使用しません

We very strongly recommend that you use version/timestamp columns for optimistic locking with Hibernate. This is the optimal strategy with respect to performance and is the only strategy that correctly handles modifications made to detached instances (ie. when Session.merge() is used).

Hibernateで楽観的ロック戦略を使うなら、バージョン/タイムスタンプカラムを使うことを非常に強くお勧めします。楽観的ロックはパフォーマンスの観点からも最適であり、さらに分離インスタンスへの修正（つまりSession.marge()が使われるとき）を正確に扱うことのできる唯一の戦略でもあります。

There is no difference between a view and a base table for a Hibernate mapping, as expected this is transparent at the database level (note that some DBMS don't support views properly, especially with updates). Sometimes you want to use a view, but can't create one in the database (ie. with a legacy schema). In this case, you can map an immutable and read-only entity to a given SQL subselect expression:

Hibernateのマッピングにとってビューと普通のテーブルの間に違いはなく、データベースレベルでは透過的です（ただしビューを完全にはサポートしていないDBMSもあります。特に、更新のあるビューに対してはそうです）。ビューを使いたくても、データベースで作成できないことがあります（例えば、レガシースキーマの場合）。この場合には、不変かつ読み取り専用のエンティティに与えられたSQLの副問合せ文をマップできます。

select item.name, max(bid.amount), count(*)

from item

join bid on bid.item_id = item.id

group by item.name

</subselect>

...

</class>

Declare the tables to synchronize this entity with, ensuring that auto-flush happens correctly, and that queries against the derived entity do not return stale data. The<subselect> is available as both as an attribute and a nested mapping element.

テーブルをこのエンティティと同期するように定義してください。オートフラッシュが確実に起こるように、また導出エンティティに対するクエリが古いデータを返さないようにするためです。subselectは属性とネストしたマッピング属性のどちらでも利用できます。

5.1.4. id

Mapped classes must declare the primary key column of the database table. Most classes will also have a JavaBeans-style property holding the unique identifier of an instance. The <id> element defines the mapping from that property to the primary key column.

マップされたクラスはデータベーステーブルの主キーカラムを定義しなければなりません。ほとんどのクラスにはインスタンスのユニークな識別子を保持するJavaBeansスタイルのプロパティもあります。id要素は、そのプロパティから主キーカラムへのマッピングを定義します。

<id

name="propertyName" (1)

type="typename" (2)

column="column_name" (3)

unsaved-value="null|any|none|undefined|id_value" (4)

access="field|property|ClassName"> (5)

node="element-name|@attribute-name|element/@attribute|."

</id>

(1)	name (optional)(オプション): The name of the identifier property. (識別子プロパティ名)
(2)	type (optional)(オプション): A name that indicates the Hibernate type. (Hibernateの型を示す名前)
(3)	column (optional - defaults to the property name)(オプション - デフォルトはプロパティ名): The name of the primary key column. (主キーカラム名)
(4)	unsaved-value (optional - defaults to a "sensible" value)(オプション - デフォルトはsensible値): An identifier property value that indicates that an instance is newly instantiated (unsaved), distinguishing it from detached instances that were saved or loaded in a previous session. (インスタンスが新しくインスタンス化された（セーブされていない）ことを示す、識別子プロパティの値。以前のSessionでセーブまたはロードされた一時的インスタンスと区別するために使います。)
(5)	access (optional - defaults to property)(オプションデフォルトはproperty): The strategy Hibernate should use for accessing the property value. (プロパティの値へアクセスするためにHibernateが使う戦略です。)

If the name attribute is missing, it is assumed that the class has no identifier property.

name属性がなければ、クラスには識別子プロパティがないものとみなされます。

The unsaved-value attribute is almost never needed in Hibernate3.

unsaved-value属性はHibernate3ではほとんどの場合、必要ではありません。

There is an alternative <composite-id> declaration to allow access to legacy data with composite keys. We strongly discourage its use for anything else.

複合キーを持つレガシーデータにアクセスできるように、composite-idという代替のマッピング定義があります。しかし他の用途への使用は全くおすすめできません。

5.1.4.1. Generator

The optional <generator> child element names a Java class used to generate unique identifiers for instances of the persistent class. If any parameters are required to configure or initialize the generator instance, they are passed using the <param>element.

オプションのgenerator子要素は、永続クラスのインスタンスのユニークな識別子を生成するために使う、Javaクラスを指定します。ジェネレータインスタンスの設定、もしくは初期化にパラメータが必要であれば、param要素を使って渡すことができます。

<param name="table">uid_table</param>

<param name="column">next_hi_value_column</param>

</generator>

</id>

All generators implement the interface org.hibernate.id.IdentifierGenerator. This is a very simple interface; some applications may choose to provide their own specialized implementations. However, Hibernate provides a range of built-in implementations. There are shortcut names for the built-in generators:

すべてのGeneratorは、インターフェイスorg.hibernate.id.IdentifierGeneratorを実装します。これはとても単純なインターフェイスなので、特別な実装を独自に用意するアプリケーションもあるかもしれません。しかしHibernateは組み込みの実装をいくつも用意しています。組み込みのジェネレータには以下のショートカット名があります：

increment

generates identifiers of type long, short or int that are unique only when no other process is inserting data into the same table. Do not use in a cluster.

long,short, int型の識別子を生成します。これらは他のプロセスが同じテーブルにデータを挿入しないときだけユニークです。クラスタ内では使わないでください。

identity

supports identity columns in DB2, MySQL, MS SQL Server, Sybase and HypersonicSQL. The returned identifier is of type long, short or int.

DB2, MySQL, MS SQL Server, Sybase, HypersonicSQLの識別子カラムをサポートします。返される識別子の型はlong,short,intのいずれかです。

sequence

uses a sequence in DB2, PostgreSQL, Oracle, SAP DB, McKoi or a generator in Interbase. The returned identifier is of type long, short or int

DB2, PostgreSQL, Oracle, SAP DB, McKoiのシーケンスや、InterbaseのGeneratorを使用します。返される識別子の型はlong,short, intのいずれかです。

hilo

uses a hi/lo algorithm to efficiently generate identifiers of type long, short or int, given a table and column (by default hibernate_unique_key and next_hi respectively) as a source of hi values. The hi/lo algorithm generates identifiers that are unique only for a particular database.

long,short, int型の識別子を効率的に生成するhi/loアルゴリズムを使います。hi値のソースとして、テーブルとカラムを与えます(デフォルトではそれぞれhibernate_unique_keyと next_hi)。hi/loアルゴリズムは特定のデータベースに対してのみユニークな識別子を生成します。

seqhilo

uses a hi/lo algorithm to efficiently generate identifiers of type long, short or int, given a named database sequence.

long,short, int型の識別子を効率的に生成するhi/loアルゴリズムを使います。指定されたデータベースシーケンスを与えます。

uuid

uses a 128-bit UUID algorithm to generate identifiers of type string, unique within a network (the IP address is used). The UUID is encoded as a string of hexadecimal digits of length 32.

(IPアドレスが使用される)ネットワーク内でユニークな文字列型の識別子を生成するために、128ビットのUUIDアルゴリズムを使用します。UUIDは長さ32の16進数字の文字列としてエンコードされます。

guid

uses a database-generated GUID string on MS SQL Server and MySQL.

MS SQLサーバとMySQLでデータベースが生成するGUID文字列を使用します。

native

picks identity, sequence or hilo depending upon the capabilities of the underlying database.

使用するデータベースの性能によりidentity,sequence,hiloのいずれかが選ばれます。

assigned

lets the application to assign an identifier to the object before save() is called. This is the default strategy if no <generator> element is specified.

save()が呼ばれる前に、アプリケーションがオブジェクトに識別子を代入できるようにします。generatorが指定されていなければ、これがデフォルトの戦略になります。

select

retrieves a primary key assigned by a database trigger by selecting the row by some unique key and retrieving the primary key value.

あるユニークキーによる行の選択と主キーの値の復元により、データベーストリガが割り当てた主キーを取得します。

foreign

uses the identifier of another associated object. Usually used in conjunction with a<one-to-one> primary key association.

他の関連オブジェクトの識別子を使います。普通は、one-to-one主キー関連と組み合わせて使います。

sequence-identity

a specialized sequence generation strategy which utilizes a database sequence for the actual value generation, but combines this with JDBC3 getGeneratedKeys to actually return the generated identifier value as part of the insert statement execution. This strategy is only known to be supported on Oracle 10g drivers targetted for JDK 1.4. Note comments on these insert statements are disabled due to a bug in the Oracle drivers.

データベースシーケンスを実際の価値生成のために利用するが、インサートステートメント実行の一部として実際に発生する識別子価値を返すためにこれをJDBC3 getGeneratedKeysと結合する専門シーケンス生成戦略。この戦略は、Oracle 10gのドライバーtargettedがJDK 1.4のためにサポートされることが知られているだけです。インサートステートメントについてのコメントは、オラクルドライバのバグのために無効にされます。

5.1.4.2. Hi/lo algorithm (Hi/Loアルゴリズム)

The hilo and seqhilo generators provide two alternate implementations of the hi/lo algorithm, a favorite approach to identifier generation. The first implementation requires a "special" database table to hold the next available "hi" value. The second uses an Oracle-style sequence (where supported).

hiloとseqhiloGeneratorは、識別子生成の代表的なアプローチであるhi/loアルゴリズムの2つの代替実装を提供します。1番目の実装は、次回に利用される"hi"値を保持する「特別な」データベーステーブルを必要とします。2番目の実装は、Oracleスタイルのシーケンスを使います（サポートされている場合）。

<param name="table">hi_value</param>

<param name="column">next_value</param>

</generator>

</id>

<param name="sequence">hi_value</param>

</generator>

</id>

Unfortunately, you can't use hilo when supplying your own Connection to Hibernate. When Hibernate is using an application server datasource to obtain connections enlisted with JTA, you must properly configure the hibernate.transaction.manager_lookup_class.

残念ながらHibernateへの独自のConnectionを提供するときには、hiloを使えません。HibernateがJTAでリストされている接続を取得するためにアプリケーションサーバーのデータソースを使用しているときには、hibernate.transaction.manager_lookup_classを適切に設定しなければなりません。

5.1.4.3. UUID algorithm(UUIDアルゴリズム)

The UUID contains: IP address, startup time of the JVM (accurate to a quarter second), system time and a counter value (unique within the JVM). It's not possible to obtain a MAC address or memory address from Java code, so this is the best we can do without using JNI.

UUIDには以下のものが含まれます：IPアドレス、JVMのスタートアップタイム（4分の1秒の正確さ）、システム時間、（JVMに対してユニークな）カウンタ値。JavaコードからMACアドレスやメモリアドレスを取得することはできないので、JNIが使えないときの最良の方法です。

5.1.4.4. Identity columns and sequences(識別子カラムとシーケンス)

For databases which support identity columns (DB2, MySQL, Sybase, MS SQL), you may use identity key generation. For databases that support sequences (DB2, Oracle, PostgreSQL, Interbase, McKoi, SAP DB) you may use sequence style key generation. Both these strategies require two SQL queries to insert a new object.

識別子カラムをサポートしているデータベース（DB2, MySQL, Sybase, MS SQL）では、identityキー生成を使えます。シーケンスをサポートするデータベース（DB2, Oracle, PostgreSQL, Interbase, McKoi, SAP DB）では、sequenceスタイルのキー生成を使えます。どちらの戦略も、新しいオブジェクトを挿入するために、SQLクエリを2つ必要とします。

<param name="sequence">person_id_sequence</param>

</generator>

</id>

</id>

For cross-platform development, the native strategy will choose from the identity,sequence and hilo strategies, dependant upon the capabilities of the underlying database.

クロスプラットフォームの開発では、native戦略は identity,sequence,hilo戦略の中から1つを選択しますが、これは使用しているデータベースの能力に依存します。

5.1.4.5. Assigned identifiers(識別子の割り当て)

If you want the application to assign identifiers (as opposed to having Hibernate generate them), you may use the assigned generator. This special generator will use the identifier value already assigned to the object's identifier property. This generator is used when the primary key is a natural key instead of a surrogate key. This is the default behavior if you do no specify a <generator> element.

アプリケーションに識別子を割り当てさせたいのであれば(Hibernateが生成するものではなく）、assignedGeneratorを使うことができます。この特別なGeneratorは、すでにオブジェクトの識別子プロパティに代入された値を識別子に使います。このGeneratorは主キーが代理キーの代わりに自然キーである場合に使用します。generator要素を指定しない場合のデフォルトの動作になります。

Choosing the assigned generator makes Hibernate use unsaved-value="undefined", forcing Hibernate to go to the database to determine if an instance is transient or detached, unless there is a version or timestamp property, or you defineInterceptor.isUnsaved().

assignedGeneratorを選択すると、Hibernateはunsaved-value="undefined"を使用します。そして、バージョンやタイムスタンプのプロパティがない場合やInterceptor.isUnsaved()を定義しなかった場合には、インスタンスが一時的(transient)なものであるのか、またはセッションから分離(detached)したものかどうかを決めるために、データベースを調べます。

5.1.4.6. Primary keys assigned by triggers(トリガーにより割り当てられた主キー)

For legacy schemas only (Hibernate does not generate DDL with triggers).

レガシースキーマのためだけ指定します。(Hibernateはトリガーを使ってDDLを生成しません)

<param name="key">socialSecurityNumber</param>

</generator>

</id>

In the above example, there is a unique valued property named socialSecurityNumberdefined by the class, as a natural key, and a surrogate key named person_id whose value is generated by a trigger.

上の例の中で、クラスで自然キーとして定義されたsocialSecurityNumberという名前のユニークな値のプロパティと値がトリガにより生成されるperson_idという名前の代理キーがあります。

5.1.5. composite-id

<composite-id

name="propertyName"

class="ClassName"

mapped="true|false"

access="field|property|ClassName">

node="element-name|."

<key-property name="propertyName" type="typename" column="column_name"/>

<key-many-to-one name="propertyName class="ClassName" column="column_name"/>

......

</composite-id>

For a table with a composite key, you may map multiple properties of the class as identifier properties. The <composite-id> element accepts <key-property> property mappings and <key-many-to-one> mappings as child elements.

複合キーのあるテーブルに対し、識別子プロパティとしてクラスの複数のプロパティをマッピングすることができます。composite-id要素は、子要素として key-propertyプロパティマッピングとkey-many-to-oneマッピングを受け入れます。

<composite-id>

<key-property name="medicareNumber"/>

<key-property name="dependent"/>

</composite-id>

Your persistent class must override equals() and hashCode() to implement composite identifier equality. It must also implements Serializable.

複合識別子の等価性を実装するためには、永続クラスがequals()とhashCode()をオーバーライドしなければなりません。またSerializableも実装しなければいけません。

Unfortunately, this approach to composite identifiers means that a persistent object is its own identifier. There is no convenient "handle" other than the object itself. You must instantiate an instance of the persistent class itself and populate its identifier properties before you can load() the persistent state associated with a composite key. We call this approach an embedded composite identifier, and discourage it for serious applications.

残念ながら複合識別子のためのこの方法は、永続オブジェクトが自身の識別子であることを意味しています。オブジェクト自身を識別子とする以上の便利な「扱い方」はありません。複合キーに関連した永続状態をload()出来るようになる前に、永続クラス自身をインスタンス化し、識別子プロパティを設定しなければなりません。組み込みの複合識別子と呼ばれるこのアプローチは、本格的なアプリケーションには向いていません。

A second approach is what we call a mapped composite identifier, where the identifier properties named inside the <composite-id> element are duplicated on both the persistent class and a separate identifier class.

2つ目の方法はマップされた複合識別子と呼ばれるもので、composite-idエレメント内で指定した識別プロパティが永続クラスと分離した識別子クラスの両方に重複して存在します。

<composite-id class="MedicareId" mapped="true">

<key-property name="medicareNumber"/>

<key-property name="dependent"/>

</composite-id>

In this example, both the composite identifier class, MedicareId, and the entity class itself have properties named medicareNumber and dependent. The identifier class must override equals() and hashCode() and implement. Serializable. The disadvantage of this approach is quite obvious--code duplication.

この例では、複合識別子クラス（MedicareId）とエンティティクラス自身の両方が、medicareNumberとdependentという名前のプロパティを持ちます。識別子クラスは、equals()とhashCode()をオーバライドし、Serializableを実装しなくてはなりません。この方法には、明らかにコードが重複するという不都合があります。

The following attributes are used to specify a mapped composite identifier:

次の属性はマッピングした複合識別子を指定するために使用します。

? mapped (optional, defaults to false)(オプション - デフォルトはfalse): indicates that a mapped composite identifier is used, and that the contained property mappings refer to both the entity class and the composite identifier class. (マッピングした複合識別子が使用されることと、包含されたプロパティのマッピングが、エンティティクラスと複合識別子クラスの両方を参照することを示します。)

? class (optional, but required for a mapped composite identifier)(オプション - ただし、マッピングした複合識別子は必須): The class used as a composite identifier. (複合識別子として使用するクラス。)

We will describe a third, even more convenient approach where the composite identifier is implemented as a component class in Section 8.4, "Components as composite identifiers". The attributes described below apply only to this alternative approach:

3つ目のさらに便利な方法は、複合識別子をSection 8.4, "Components as composite identifiers"内のコンポーネントクラスとして実装することです。下で記述している属性は、この代替方法にのみ適用されます。

? name (optional, required for this approach)(オプション - このアプローチでは必須): A property of component type that holds the composite identifier (see chapter 9). (複合識別子を保持するコンポーネントタイプのプロパティ(9章を参照してください).)

? access (optional - defaults to property) (オプション - デフォルトはproperty): The strategy Hibernate should use for accessing the property value. (Hibernateがプロパティの値にアクセスするために使用すべき戦略。)

? class (optional - defaults to the property type determined by reflection) (オプション - デフォルトはリフレクションにより決定されるプロパティの型): The component class used as a composite identifier (see next section).( 複合識別子として使われるコンポーネントのクラス（次の節を見てください）。)

This third approach, an identifier component is the one we recommend for almost all applications.

この3つ目の方法は識別子コンポーネントと呼び、ほとんどすべてのアプリケーションに対して推奨する方法です。

5.1.6. discriminator

The <discriminator> element is required for polymorphic persistence using the table-per-class-hierarchy mapping strategy and declares a discriminator column of the table. The discriminator column contains marker values that tell the persistence layer what subclass to instantiate for a particular row. A restricted set of types may be used: string,character, integer, byte, short, boolean, yes_no, true_false.

discriminator要素は、table-per-class-hierarchyマッピング戦略を使うポリモーフィックな永続化に必要であり、テーブルの識別カラムを定義します。識別カラムは、ある行に対して永続層がどのサブクラスをインスタンス化するかを伝えるマーカー値を含んでいます。以下のような型に制限されます：string,character, integer, byte,short,boolean, yes_no,true_false.

<discriminator

column="discriminator_column" (1)

type="discriminator_type" (2)

force="true|false" (3)

insert="true|false" (4)

formula="arbitrary sql expression" (5)

(1)	column (optional - defaults to class)(オプション - デフォルトはclass) the name of the discriminator column. (識別子カラム名)
(2)	type (optional - defaults to string) (オプション - デフォルトはstring)a name that indicates the Hibernate type (Hibernateの型を示す名前)
(3)	force (optional - defaults to false) (オプション - デフォルトはfalse) "force" Hibernate to specify allowed discriminator values even when retrieving all instances of the root class. (ルートクラスのすべてのインスタンスを検索する場合であっても、Hibernateが使用できる識別カラムの指定を「強制」します。)
(4)	insert (optional - defaults to true) (オプション - デフォルトはtrue) set this to false if your discriminator column is also part of a mapped composite identifier. (Tells Hibernate to not include the column in SQL INSERTs.) (もし識別カラムがマッピングする複合識別子の一部ならば、falseと設定してください。(HibernateにSQLのINSERTには含まれないことを知らせる))
(5)	formula (optional) (オプション)an arbitrary SQL expression that is executed when a type has to be evaluated. Allows content-based discrimination. (formula(オプション)型が評価されるときに実行される任意のSQL式。コンテンツベースの識別を可能にします。)

Actual values of the discriminator column are specified by the discriminator-valueattribute of the <class> and <subclass> elements.

識別カラムの実際の値は、classと subclass要素のdiscriminator-value属性で指定されます。

The force attribute is (only) useful if the table contains rows with "extra" discriminator values that are not mapped to a persistent class. This will not usually be the case.

永続クラスへマッピングされない｢余分な」識別値を持つ行がテーブルにあれば、（そのときに限り）force属性は有効です。ただし、普通はそういうことはありません。

Using the formula attribute you can declare an arbitrary SQL expression that will be used to evaluate the type of a row:

formula属性を使うと、行の型を評価するために任意のSQL式を宣言できます。

<discriminator

formula="case when CLASS_TYPE in ('a', 'b', 'c') then 0 else 1 end"

type="integer"/>

5.1.7. version (optional)

The <version> element is optional and indicates that the table contains versioned data. This is particularly useful if you plan to use long transactions (see below).

version要素はオプションであり、テーブルがバージョンデータを含むことを示します。これはロングトランザクションを使うつもりなら、特に役立ちます（以下を見てください）。

<version

column="version_column" (1)

name="propertyName" (2)

type="typename" (3)

access="field|property|ClassName" (4)

unsaved-value="null|negative|undefined" (5)

generated="never|always" (6)

insert="true|false" (7)

node="element-name|@attribute-name|element/@attribute|."

(1)	column (optional - defaults to the property name)(オプション - デフォルトはプロパティ名): The name of the column holding the version number. (バージョン番号を保持するカラム名)
(2)	name: The name of a property of the persistent class. (永続クラスのプロパティ名)
(3)	type (optional - defaults to integer) (オプション - デフォルトはinteger): The type of the version number. (バージョン番号の型。)
(4)	access (optional - defaults to property) (オプション - デフォルトはproperty): The strategy Hibernate should use for accessing the property value. (プロパティの値へのアクセスにHibernateが使う戦略。)
(5)	unsaved-value (optional - defaults to undefined) (オプション - デフォルトはundefined): A version property value that indicates that an instance is newly instantiated (unsaved), distinguishing it from detached instances that were saved or loaded in a previous session. (undefined specifies that the identifier property value should be used.) (インスタンスが新しくインスタンス化されたことを示す（セーブされていないことを示す）バージョンプロパティの値。以前のSessionでセーブまたはロードされた一時的なインスタンスと区別するために使います。（undefinedは識別子プロパティの値が使われることを指定します。）)
(6)	generated (optional - defaults to never) (オプション - デフォルトはnever): Specifies that this version property value is actually generated by the database. See the discussion of Section 5.6, "Generated Properties". (このバージョンのプロパティの値が、データベースによって生成されたことを指定します。Section 5.6, "Generated Properties"生成プロパティの議論を見てください。)
(7)	insert (optional - defaults to true) (オプション - デフォルトはtrue): Specifies whether the version column should be included in SQL insert statements. May be set to false if and only if the database column is defined with a default value of 0. (SQLのinsert文にバージョン・カラムを含めるべきかどうかを指定します。もしデータベース・カラムのデフォルト値が0と定義されるときには、falseに設定すると良いでしょう。)

Version numbers may be of Hibernate type long, integer, short, timestamp or calendar.

バージョン番号は Hibernateのlong,integer, short,timestamp, calendar型のいずれかです。

A version or timestamp property should never be null for a detached instance, so Hibernate will detact any instance with a null version or timestamp as transient, no matter what other unsaved-value strategies are specified. Declaring a nullable version or timestamp property is an easy way to avoid any problems with transitive reattachment in Hibernate, especially useful for people using assigned identifiers or composite keys!

バージョンやタイムスタンプのプロパティは、分離されたインスタンスに対してnullであってはなりません。そのためどのようなunsaved-value戦略が指定されても、Hibernateはnullのバージョンやタイムスタンプを持ったすべてのインスタンスを、一時的なものであると判断します。nullを許容するバージョンやタイムスタンプのプロパティを定義することは、過渡的に一時オブジェクトとすることを防ぐ簡単な方法です。特に識別子の割り当てや複合キーを使用しているときには特に有用です。

5.1.8. timestamp (optional)

The optional <timestamp> element indicates that the table contains timestamped data. This is intended as an alternative to versioning. Timestamps are by nature a less safe implementation of optimistic locking. However, sometimes the application might use the timestamps in other ways.

オプションのtimestamp要素は、テーブルがタイムスタンプデータを含むことを示します。これはバージョン付けの代わりの方法として用意されています。タイムスタンプはもともと楽観的ロックにおける安全性の低い実装です。しかしアプリケーションは異なる用途で使うこともあるかもしれません。

<timestamp

column="timestamp_column" (1)

name="propertyName" (2)

access="field|property|ClassName" (3)

unsaved-value="null|undefined" (4)

source="vm|db" (5)

generated="never|always" (6)

node="element-name|@attribute-name|element/@attribute|."

(1)	column (optional - defaults to the property name)(オプション - デフォルトはプロパティ名): The name of a column holding the timestamp. (タイムスタンプを保持するカラムの名前。)
(2)	name: The name of a JavaBeans style property of Java type Date or Timestamp of the persistent class. (永続クラスであるJava のDate型またはTimestamp型の、JavaBeansスタイルプロパティの名前。)
(3)	access (optional - defaults to property) (オプション - デフォルトはproperty): The strategy Hibernate should use for accessing the property value. (プロパティの値へのアクセスにHibernateが使う戦略。)
(4)	unsaved-value (optional - defaults to null) (オプション - デフォルトはnull): A version property value that indicates that an instance is newly instantiated (unsaved), distinguishing it from detached instances that were saved or loaded in a previous session. (undefined specifies that the identifier property value should be used.) (インスタンスが新しくインスタンス化された（セーブされていない）ことを示すバージョンプロパティの値。以前のSessionでセーブまたはロードされた一時的なインスタンスと区別するために使われます。（undefinedと指定すると、識別子プロパティの値が使われます。）)
(5)	source (optional - defaults to vm) (オプション - デフォルトはvm): From where should Hibernate retrieve the timestamp value? From the database, or from the current JVM? Database-based timestamps incur an overhead because Hibernate must hit the database in order to determine the "next value", but will be safer for use in clustered environments. Note also, that not all Dialects are known to support retrieving of the database's current timestamp, while others might be unsafe for usage in locking due to lack of precision (Oracle 8 for example). (Hibernateはどこからタイムスタンプの値を取得するべきでしょうか？データベースからでしょうか、現在のJVMからでしょうか？データベースによるタイムスタンプは、Hibernateが"次の値"を決定するためにデータベースをヒットしなければならないため、オーバヘッドを招きます。しかしクラスタ環境ではJVMから取得するより安全です。データベースの現在のタイムスタンプの取得をサポートするすべてのデータベース方言が知られているわけではないことに注意してください。また一方で、精密さを欠くために、ロックで使用するには安全でないものもあります(例えばOracle 8)。)
(6)	generated (optional - defaults to never) (オプション - デフォルトはnerver): Specifies that this timestamp property value is actually generated by the database. See the discussion of Section 5.6, "Generated Properties". (このタイムスタンプ・プロパティの値が、データベースによって生成されることを指定します。Section 5.6, "Generated Properties"生成プロパティを参照してください。)

Note that <timestamp> is equivalent to <version type="timestamp">. And <timestamp source="db"> is equivalent to <version type="dbtimestamp">

timestampはversion type="timestamp"と等価であることに注意してくださいtimestamp source="db"はversion type="dbtimestamp"と等価であることに注意してください。

5.1.9. property

The <property> element declares a persistent, JavaBean style property of the class.

property要素は、クラスの永続的なJavaBeanスタイルのプロパティを定義します。

<property

name="propertyName" (1)

column="column_name" (2)

type="typename" (3)

update="true|false" (4)

insert="true|false" (4)

formula="arbitrary SQL expression" (5)

access="field|property|ClassName" (6)

lazy="true|false" (7)

unique="true|false" (8)

not-null="true|false" (9)

optimistic-lock="true|false" (10)

generated="never|insert|always" (11)

node="element-name|@attribute-name|element/@attribute|."

index="index_name"

unique_key="unique_key_id"

length="L"

precision="P"

scale="S"

(1)	name: the name of the property, with an initial lowercase letter. (小文字で始まるプロパティ名。)
(2)	column (optional - defaults to the property name)(オプション - デフォルトはプロパティ名): the name of the mapped database table column. This may also be specified by nested <column> element(s). (マッピングされたデータベーステーブルのカラムの名前。ネストした<column>要素でも指定できます。)
(3)	type (optional)(オプション): a name that indicates the Hibernate type. (Hibernateの型を示す名前。)
(4)	update, insert (optional - defaults to true) (オプション - デフォルトはtrue) : specifies that the mapped columns should be included in SQL UPDATE and/or INSERTstatements. Setting both to false allows a pure "derived" property whose value is initialized from some other property that maps to the same colum(s) or by a trigger or other application. (マッピングされたカラムがSQLのUPDATEやINSERTに含まれることを指定します。両方ともfalseに設定すると、同じカラムにマッピングされた他のプロパティやトリガや他のアプリケーションによって初期化された純粋な「導出」プロパティが可能になります。)
(5)	formula (optional)(オプション): an SQL expression that defines the value for acomputed property. Computed properties do not have a column mapping of their own. (計算プロパティのための値を定義するSQL式。計算されたプロパティは自身のカラムへのマッピングがありません。)
(6)	access (optional - defaults to property) (オプション - デフォルトはproperty): The strategy Hibernate should use for accessing the property value. (プロパティの値へのアクセスにHibernateが使う戦略。)
(7)	lazy (optional - defaults to false) (オプション - デフォルトはfalse): Specifies that this property should be fetched lazily when the instance variable is first accessed (requires build-time byte code instrumentation). (インスタンス変数に最初にアクセスしたときに、プロパティを遅延して取得するよう指定します。(バイトコード実装を作成する時間が必要になります)。)
(8)	unique (optional)(オプション): Enable the DDL generation of a unique constraint for the columns. Also, allow this to be the target of a property-ref. (カラムにユニーク制約をつけるDDLの生成を可能にします。また、property-refのターゲットとすることもできます。)
(9)	not-null (optional)(オプション): Enable the DDL generation of a nullability constraint for the columns. (カラムにnull値を許可するDDLの生成を可能にします。)
(10)	optimistic-lock (optional - defaults to true) (オプション - デフォルトはtrue): Specifies that updates to this property do or do not require acquisition of the optimistic lock. In other words, determines if a version increment should occur when this property is dirty. (このプロパティの更新に楽観ロックの取得を要求するかどうかを指定します。言い換えれば、このプロパティがダーティであるときにバージョンを増やすべきかを決定します。)
(11)	generated (optional - defaults to never) (オプション - デフォルトはnever): Specifies that this property value is actually generated by the database. See the discussion ofSection 5.6, "Generated Properties". (プロパティの値が、データベースによって生成されたことを指定します。Section 5.6, "Generated Properties"生成プロパティを参照してください。)

typename could be:

typenameには以下の値が可能です：

1. The name of a Hibernate basic type (eg. integer, string, character, date, timestamp, float, binary, serializable, object, blob).

Hibernateの基本型の名前（例 integer, string, character, date, timestamp, float, binary, serializable, object, blob）。

2. The name of a Java class with a default basic type (eg. int, float, char, java.lang.String, java.util.Date, java.lang.Integer, java.sql.Clob).

デフォルトの基本型のJavaクラス名（例int, float, char, java.lang.String, java.util.Date, java.lang.Integer, java.sql.Clob）。

3. The name of a serializable Java class.

シリアライズ可能なJavaクラスの名前。

4. The class name of a custom type (eg. com.illflow.type.MyCustomType).

カスタム型のクラス名（例com.illflow.type.MyCustomType）。

If you do not specify a type, Hibernate will use reflection upon the named property to take a guess at the correct Hibernate type. Hibernate will try to interpret the name of the return class of the property getter using rules 2, 3, 4 in that order. However, this is not always enough. In certain cases you will still need the type attribute. (For example, to distinguish between Hibernate.DATE and Hibernate.TIMESTAMP, or to specify a custom type.)

型を指定しなければ、Hibernateは正しいHibernateの型を推測するために、指定されたプロパティに対してリフレクションを使います。Hibernateはルール2, 3, 4をその順序に使い、getterプロパティの返り値のクラスの名前を解釈しようとします。しかしこれで常に十分であるとは限りません。場合によっては、type属性が必要な場合があります。（例えばHibernate.DATEとHibernate.TIMESTAMPを区別するため、またはカスタム型を指定するためなどです。）

The access attribute lets you control how Hibernate will access the property at runtime. By default, Hibernate will call the property get/set pair. If you specify access="field", Hibernate will bypass the get/set pair and access the field directly, using reflection. You may specify your own strategy for property access by naming a class that implements the interface org.hibernate.property.PropertyAccessor.

access属性で、実行時にHibernateがどのようにプロパティにアクセスするかを制御できます。デフォルトではHibernateはプロパティのget/setのペアをコールします。access="field"と指定すれば、Hibernateはリフレクションを使いget/setのペアを介さずに、直接フィールドにアクセスします。インターフェイスorg.hibernate.property.PropertyAccessorを実装するクラスを指定することで、プロパティへのアクセスに独自の戦略を指定することができます。

An especially powerful feature are derived properties. These properties are by definition read-only, the property value is computed at load time. You declare the computation as a SQL expression, this translates to a SELECT clause subquery in the SQL query that loads an instance:

特に強力な特徴は生成プロパティです。これらのプロパティは当然読み取り専用であり、プロパティの値はロード時に計算されます。計算をSQL式として宣言すると、このプロパティはインスタンスをロードするSQLクエリのSELECT句のサブクエリに変換されます。

<property name="totalPrice"

formula="( SELECT SUM (li.quantity*p.price) FROM LineItem li, Product p

WHERE li.productId = p.productId

AND li.customerId = customerId

AND li.orderNumber = orderNumber )"/>

Note that you can reference the entities own table by not declaring an alias on a particular column (customerId in the given example). Also note that you can use the nested <formula> mapping element if you don't like to use the attribute.

特定のカラム(例ではcustomerIdがそれにあたります)のエイリアスを宣言することなく、エンティティ自身のテーブルを参照できることに注意してください。もし属性を使用したくなければ、ネストした<formula>マッピング要素を使えることにも注意してください。

5.1.10. many-to-one

An ordinary association to another persistent class is declared using a many-to-oneelement. The relational model is a many-to-one association: a foreign key in one table is referencing the primary key column(s) of the target table.

他の永続クラスへの通常の関連はmany-to-one要素を使って定義します。リレーショナルモデルは多対一関連です。つまりあるテーブルの外部キーは、ターゲットとなるテーブルの主キーカラムを参照しています。

<many-to-one

name="propertyName" (1)

column="column_name" (2)

class="ClassName" (3)

cascade="cascade_style" (4)

fetch="join|select" (5)

update="true|false" (6)

insert="true|false" (6)

property-ref="propertyNameFromAssociatedClass" (7)

access="field|property|ClassName" (8)

unique="true|false" (9)

not-null="true|false" (10)

optimistic-lock="true|false" (11)

lazy="proxy|no-proxy|false" (12)

not-found="ignore|exception" (13)

entity-name="EntityName" (14)

formula="arbitrary SQL expression" (15)

node="element-name|@attribute-name|element/@attribute|."

embed-xml="true|false"

index="index_name"

unique_key="unique_key_id"

foreign-key="foreign_key_name"

(1)	name: The name of the property. (プロパティ名)
(2)	column (optional)(オプション): The name of the foreign key column. This may also be specified by nested <column> element(s). (外部キーカラムの名前。ネストしたcolumn要素でも指定できます。)
(3)	class (optional - defaults to the property type determined by reflection)(オプション- デフォルトはリフレクションにより決定されるプロパティの型): The name of the associated class. (関連クラス名)
(4)	cascade (optional) (オプション): Specifies which operations should be cascaded from the parent object to the associated object. (どの操作を、親オブジェクトから関連オブジェクトへとカスケードさせるかを指定します。)
(5)	fetch (optional - defaults to select) (オプション - デフォルトはselect): Chooses between outer-join fetching or sequential select fetching. (外部結合フェッチか順次選択フェッチ（sequential select fetch）を選択します。)
(6)	update, insert (optional - defaults to true) (オプション - デフォルトはtrue) specifies that the mapped columns should be included in SQL UPDATE and/or INSERTstatements. Setting both to false allows a pure "derived" association whose value is initialized from some other property that maps to the same colum(s) or by a trigger or other application. (マッピングされたカラムがSQLのUPDATEまたはINSERT文に含まれることを指定します。両方ともfalseに設定すると、その値が同じカラムにマッピングされた他のプロパティやトリガや他のアプリケーションによって初期化された純粋な「導出」プロパティが可能になります。)
(7)	property-ref: (optional) (オプション) The name of a property of the associated class that is joined to this foreign key. If not specified, the primary key of the associated class is used. (この外部キーに結合された関連クラスのプロパティ名。何も指定しなければ、関連クラスの主キーが使われます。)
(8)	access (optional - defaults to property) (オプション - デフォルトはproperty): The strategy Hibernate should use for accessing the property value. (プロパティの値へのアクセスにHibernateが使う戦略。)
(9)	unique (optional)(オプション): Enable the DDL generation of a unique constraint for the foreign-key column. Also, allow this to be the target of a property-ref. This makes the association multiplicity effectively one to one. (外部キーカラムに対してユニーク制約をつけたDDLの生成を可能にします。また、property-refのターゲットにすることもできます。これにより関連の多重度を効果的に一対一にします。)
(10)	not-null (optional) (オプション): Enable the DDL generation of a nullability constraint for the foreign key columns. (外部キーカラムに対して、null値を許可するDDLの生成を可能にします)
(11)	optimistic-lock (optional - defaults to true) (オプション - デフォルトはtrue): Specifies that updates to this property do or do not require acquisition of the optimistic lock. In other words, dertermines if a version increment should occur when this property is dirty. (このプロパティの更新に楽観的ロックの取得を要求するかどうかを指定します。言い換えれば、このプロパティがダーティであるときにバージョンを増やすべきかを決定します。)
(12)	lazy (optional - defaults to proxy) (オプション - デフォルトはproxy): By default, single point associations are proxied. lazy="no-proxy" specifies that the property should be fetched lazily when the instance variable is first accessed (requires build-time bytecode instrumentation). lazy="false" specifies that the association will always be eagerly fetched. (デフォルトでは、多重度１の関連がプロキシとなります。lazy="no-proxy"は、インスタンス変数に最初にアクセスしたときに、プロパティを遅延フェッチするよう指定します(ビルド時にバイトコード実装が必要になります)。lazy="false"は関連を常に即時にフェッチするよう指定します。)
(13)	not-found (optional - defaults to exception) (オプション - デフォルトはexception): Specifies how foreign keys that reference missing rows will be handled: ignore will treat a missing row as a null association. (欠落した行を参照する外部キーをどのように扱うかを指定します。ignoreは欠落した行をnull関連として扱います。)
(14)	entity-name (optional) (オプション): The entity name of the associated class. (関連したクラスのエンティティ名。)

Setting a value of the cascade attribute to any meaningful value other than none will propagate certain operations to the associated object. The meaningful values are the names of Hibernate's basic operations, persist, merge, delete, save-update, evict, replicate, lock, refresh, as well as the special values delete-orphan and all and comma-separated combinations of operation names, for example, cascade="persist,merge,evict"or cascade="all,delete-orphan". See Section 10.11, "Transitive persistence" for a full explanation. Note that single valued associations (many-to-one and one-to-one associations) do not support orphan delete.

cascade属性にnone以外の意味のある値をを設定すると、関連オブジェクトへある操作が伝播することになります。意味のある値とはHibernateの基本操作の名前のことで、delete-orphanとall、操作名をカンマで区切った組み合わせ（例えばcascade="persist,merge,evict"やcascade="all,delete-orphan"）、またそれだけでなくpersist, merge, delete, save-update, evict, replicate, lock, refreshのことを指します。詳しい説明はSection 10.11, "Transitive persistence"を見てください。値が一つの関連(many-to-oneとone-to-one関連)は、単独での削除（orphan delete)をサポートしていないことに注意してください。

A typical many-to-one declaration looks as simple as this:

典型的なmany-to-one宣言は次のようにシンプルです。：

<many-to-one name="product" class="Product" column="PRODUCT_ID"/>

The property-ref attribute should only be used for mapping legacy data where a foreign key refers to a unique key of the associated table other than the primary key. This is an ugly relational model. For example, suppose the Product class had a unique serial number, that is not the primary key. (The unique attribute controls Hibernate's DDL generation with the SchemaExport tool.)

property-ref属性は、外部キーが関連付けられたテーブルの、主キーでないユニークキーを参照しているレガシーデータをマップするためにだけ使うべきです。これは醜いリレーショナルモデルです。例えばProductクラスが、主キーでないユニークなシリアルナンバーを持っていると仮定してみてください。（unique属性はSchemaExportツールを使ったHibernateのDDL生成を制御します。）

Then the mapping for OrderItem might use:

以下のようにOrderItemに対してマッピングを使えます：

<many-to-one name="product" property-ref="serialNumber" column="PRODUCT_SERIAL_NUMBER"/>

This is certainly not encouraged, however.

しかし、これは決して推奨できません。

If the referenced unique key comprises multiple properties of the associated entity, you should map the referenced properties inside a named <properties> element.

参照したユニークキーが、関連するエンティティの多数のプロパティから構成される場合、指定したproperties要素内で、参照するプロパティをマッピングするべきです。

If the referenced unique key is the property of a component, you may specify a property path:

もし参照したユニークキーがコンポーネントのプロパティである場合は、プロパティのパスを指定できます。

<many-to-one name="owner" property-ref="identity.ssn" column="OWNER_SSN"/>

5.1.11. one-to-one

A one-to-one association to another persistent class is declared using a one-to-oneelement.

他の永続クラスへの一対一関連は、one-to-one要素で定義します。

<one-to-one

name="propertyName" (1)

class="ClassName" (2)

cascade="cascade_style" (3)

constrained="true|false" (4)

fetch="join|select" (5)

property-ref="propertyNameFromAssociatedClass" (6)

access="field|property|ClassName" (7)

formula="any SQL expression" (8)

lazy="proxy|no-proxy|false" (9)

entity-name="EntityName" (10)

node="element-name|@attribute-name|element/@attribute|."

embed-xml="true|false"

foreign-key="foreign_key_name"

(1)	name: The name of the property. (プロパティ名)
(2)	class (optional - defaults to the property type determined by reflection)(オプション- デフォルトはリフレクションにより決定されるプロパティの型): The name of the associated class. (関連クラス名)
(3)	cascade (optional)(オプション) specifies which operations should be cascaded from the parent object to the associated object. (親オブジェクトから関連オブジェクトへ、どの操作をカスケードするかを指定します。)
(4)	constrained (optional) (オプション) specifies that a foreign key constraint on the primary key of the mapped table references the table of the associated class. This option affects the order in which save() and delete() are cascaded, and determines whether the association may be proxied (it is also used by the schema export tool). (マッピングされたテーブルの主キーに対する外部キー制約が、関連クラスのテーブルを参照することを指定します。このオプションはsave()とdelete()がカスケードされる順序に影響し、そして関連がプロキシされるかどうかにも影響します（そしてスキーマエクスポートツールにも使われます）。)
(5)	fetch (optional - defaults to select) (オプション - デフォルトはselect): Chooses between outer-join fetching or sequential select fetching. (外部結合フェッチと順次選択フェッチ（sequential select fetch）のどちらかを選択します。)
(6)	property-ref: (optional) (オプション)The name of a property of the associated class that is joined to the primary key of this class. If not specified, the primary key of the associated class is used. (このクラスの主キーに結合された関連クラスのプロパティ名。指定されなければ、関連クラスの主キーが使われます。)
(7)	access (optional - defaults to property) (オプション - デフォルトはproperty): The strategy Hibernate should use for accessing the property value. (プロパティの値へのアクセスにHibernateが使う戦略。)
(8)	formula (optional) (オプション): Almost all one to one associations map to the primary key of the owning entity. In the rare case that this is not the case, you may specify a some other column, columns or expression to join on using an SQL formula. (See org.hibernate.test.onetooneformula for an example.) (ほとんどすべての一対一関連はオーナーのエンティティの主キーへとマッピングされます。これ以外の稀な場合は、他のカラムや、複数のカラム、SQL構文を使った結合するための式を指定できます。（例はorg.hibernate.test.onetooneformulaを参照してください。）)
(9)	lazy (optional - defaults to proxy) (オプション - デフォルトはproxy): By default, single point associations are proxied. lazy="no-proxy" specifies that the property should be fetched lazily when the instance variable is first accessed (requires build-time bytecode instrumentation). lazy="false" specifies that the association will always be eagerly fetched. Note that if constrained="false", proxying is impossible and Hibernate will eager fetch the association! (デフォルトでは、多重度１の関連がプロキシとなります。lazy="no-proxy"は、インスタンス変数に最初にアクセスしたときに、プロパティを遅延フェッチするよう指定します(ビルド時にバイトコード実装が必要になります)。lazy="false"は関連を常に即時にフェッチするよう指定します。もしconstrained="false"ならば、プロキシは使用不可能となり、関連を即時にフェッチすることに注意してください！)
(10)	entity-name (optional) (オプション): The entity name of the associated class. (関連クラスのエンティティ名)

There are two varieties of one-to-one association:

一対一関連には2種類あります：

? primary key associations (主キー)関連

? unique foreign key associations (ユニーク)外部キー関連)

Primary key associations don't need an extra table column; if two rows are related by the association then the two table rows share the same primary key value. So if you want two objects to be related by a primary key association, you must make sure that they are assigned the same identifier value!

主キー関連には、特別なテーブルカラムは必要ありません。もし2つの行が関連により関係していれば、2つのテーブルは同じ主キーの値を共有します。そのため2つのオブジェクトを主キー関連によって関連付けたいのであれば、確実に同じ識別子の値を代入しなければなりません。

For a primary key association, add the following mappings to Employee and Person, respectively.

主キー関連を行うためには、以下のマッピングをEmployeeとPersonのそれぞれに追加してください。

<one-to-one name="person" class="Person"/>

<one-to-one name="employee" class="Employee" constrained="true"/>

Now we must ensure that the primary keys of related rows in the PERSON and EMPLOYEE tables are equal. We use a special Hibernate identifier generation strategy calledforeign:

ここで、PERSONとEMPLOYEEテーブルの関係する行の主キーが同じであることを確実にしなければいけません。ここでは、foreignという特殊なHibernate識別子生成戦略を使います：

<param name="property">employee</param>

</generator>

</id>

...

<one-to-one name="employee"

class="Employee"

constrained="true"/>

</class>

A newly saved instance of Person is then assigned the same primary key value as theEmployee instance refered with the employee property of that Person.

Employeeインスタンスが、Personのemployeeプロパティで参照されるように、新しくセーブされたPersonのインスタンスには同じ主キーの値が代入されます。新しくセーブするPersonインスタンスは、そのPersonのemployeeプロパティが参照するEmployeeインスタンスとして同じ主キーが割り当てられます。

Alternatively, a foreign key with a unique constraint, from Employee to Person, may be expressed as:

もう1つの方法として、EmployeeからPersonへのユニーク制約を使った外部キー関連は以下のように表現されます：

<many-to-one name="person" class="Person" column="PERSON_ID" unique="true"/>

And this association may be made bidirectional by adding the following to the Personmapping:

そしてこの関連は、以下の記述をPersonのマッピングに追加することで双方向にすることができます：

<one-to-one name"employee" class="Employee" property-ref="person"/>

5.1.12. natural-id

<natural-id mutable="true|false"/>

<many-to-one ... />

......

</natural-id>

Even though we recommend the use of surrogate keys as primary keys, you should still try to identify natural keys for all entities. A natural key is a property or combination of properties that is unique and non-null. If it is also immutable, even better. Map the properties of the natural key inside the <natural-id> element. Hibernate will generate the necessary unique key and nullability constraints, and your mapping will be more self-documenting.

主キーとして代理キーの使用を推奨しますが、すべてのエンティティに対して自然キーを識別するようにすべきです。自然キーはユニークかつ非nullな一つのプロパティ、またはプロパティの連結です。不変であればさらに良いです。natural-id要素内で自然キーのプロパティをマッピングします。Hibernateは必然的にユニークかつnull値を許可する制約を生成し、こうしてマッピングはより自己記述的になります。

We strongly recommend that you implement equals() and hashCode() to compare the natural key properties of the entity.

エンティティの自然キープロパティの比較には、equals()とhashCode()の実装を強くお勧めします。

This mapping is not intended for use with entities with natural primary keys.

このマッピングは自然主キーを使ったエンティティでの使用を意図していません。

? mutable (optional, defaults to false): By default, natural identifier properties as assumed to be immutable (constant).

mutable(オプション, デフォルトはfalse): デフォルトでは、自然識別子プロパティは不変(定数)と想定されています。

5.1.13. component, dynamic-component

The <component> element maps properties of a child object to columns of the table of a parent class. Components may, in turn, declare their own properties, components or collections. See "Components" below.

<component>要素は、子オブジェクトのプロパティを親クラスのテーブルのカラムへマッピングします。コンポーネントは自分のプロパティ、コンポーネント、コレクションの順に定義できます。以下の「コンポーネント」を見てください。

<component

name="propertyName" (1)

class="className" (2)

insert="true|false" (3)

update="true|false" (4)

access="field|property|ClassName" (5)

lazy="true|false" (6)

optimistic-lock="true|false" (7)

unique="true|false" (8)

node="element-name|."

<many-to-one .... />

........

</component>

(1)	name: The name of the property. (プロパティ名)
(2)	class (optional - defaults to the property type determined by reflection)(オプション -デフォルトはリフレクションにより決定されるプロパティの型): The name of the component (child) class. (コンポーネント（子）クラスの名前。)
(3)	insert: Do the mapped columns appear in SQL INSERTs? (マッピングされたカラムがSQLの INSERTに現れるようにするどうかを指定します。)
(4)	update: Do the mapped columns appear in SQL UPDATEs? (マッピングされたカラムがSQL の UPDATEに現れるようにするかどうかを指定します。)
(5)	access (optional - defaults to property) (オプション - デフォルトproperty): The strategy Hibernate should use for accessing the property value. (プロパティの値へのアクセスにHibernateが使う戦略。)
(6)	lazy (optional - defaults to false) (オプション - デフォルトfalse): Specifies that this component should be fetched lazily when the instance variable is first accessed (requires build-time bytecode instrumentation). (インスタンス変数に最初にアクセスしたときに、コンポーネントを遅延してフェッチするよう指定します。(バイトコード実装を作成する時間が必要になります))
(7)	optimistic-lock (optional - defaults to true) (オプション - デフォルトはtrue): Specifies that updates to this component do or do not require acquisition of the optimistic lock. In other words, determines if a version increment should occur when this property is dirty. (このプロパティの更新に、楽観ロックの取得を要求するかどうかを指定します。言い換えれば、このプロパティがダーティであるときにバージョンを増やすべきかを決定します。)
(8)	unique (optional - defaults to false) (オプション - デフォルトはfalse): Specifies that a unique constraint exists upon all mapped columns of the component. (コンポーネントのすべてのマッピングするカラムに、ユニーク制約が存在するかを指定します。)

The child <property> tags map properties of the child class to table columns.

子の<property>タグで、子のクラスのプロパティをテーブルカラムにマッピングします。

The <component> element allows a <parent> subelement that maps a property of the component class as a reference back to the containing entity.

<component>要素は、親エンティティへ戻る参照として、コンポーネントのクラスのプロパティをマッピングする<parent>サブ要素を許可します。

The <dynamic-component> element allows a Map to be mapped as a component, where the property names refer to keys of the map, see Section 8.5, "Dynamic components".

<dynamic-component>要素は、Mapがコンポーネントとしてマッピングされることを可能にします。プロパティ名はmapのキーを参照します。Section 8.5, "Dynamic components"を参照してください。

5.1.14. properties

The <properties> element allows the definition of a named, logical grouping of properties of a class. The most important use of the construct is that it allows a combination of properties to be the target of a property-ref. It is also a convenient way to define a multi-column unique constraint.

properties要素はクラスのプロパティの指定された、論理的なグルーピングを可能にします。この構造の最も重要な使用方法は、property-refのターゲットになるプロパティの結合を許可することです。それはまた、複数カラムのユニーク制約を定義する簡単な方法でもあります。

<properties

name="logicalName" (1)

insert="true|false" (2)

update="true|false" (3)

optimistic-lock="true|false" (4)

unique="true|false" (5)

<many-to-one .... />

........

</properties>

(1)	name: The logical name of the grouping - not an actual property name. (グルーピングの論理名。実際のプロパティ名ではありません。)
(2)	insert: Do the mapped columns appear in SQL INSERTs? (マッピングされたカラムがSQLのINSERTに現れるようにするかどうかを指定します。)
(3)	update: Do the mapped columns appear in SQL UPDATEs? (マッピングされたカラムがSQLのUPDATEに現れるようにするかどうかを指定します。)
(4)	optimistic-lock (optional - defaults to true)(オプション - デフォルトはtrue): Specifies that updates to these properties do or do not require acquisition of the optimistic lock. In other words, determines if a version increment should occur when these properties are dirty. (これらのプロパティの更新に楽観的ロックの取得を要求するかどうかを指定します。言い換えれば、このプロパティがダーティであるときにバージョンを増やすべきかを決定します。)
(5)	unique (optional - defaults to false) (オプション - デフォルトはfalse): Specifies that a unique constraint exists upon all mapped columns of the component. (コンポーネントのすべてのマッピングするカラムに、ユニーク制約が存在するかを指定します。)

For example, if we have the following <properties> mapping:

例えば、もし以下のようなpropertiesマッピングがあった場合は：

...

<properties name="name"

unique="true" update="false">

</properties>

</class>

Then we might have some legacy data association which refers to this unique key of thePerson table, instead of to the primary key:

主キーの代わりにPersonテーブルのユニークキーへの参照を持つ、レガシーデータの関連を持つかもしれません：

<many-to-one name="person"

class="Person" property-ref="name">

</many-to-one>

We don't recommend the use of this kind of thing outside the context of mapping legacy data.

しかし、このようなレガシーデータマッピングのコンテキスト外への使用は推奨しません。

5.1.15. subclass

Finally, polymorphic persistence requires the declaration of each subclass of the root persistent class. For the table-per-class-hierarchy mapping strategy, the <subclass>declaration is used.

最後にポリモーフィックな永続化には、ルートの永続クラスの各サブクラスの定義が必要です。table-per-class-hierarchyマッピング戦略では、subclass定義が使われます。

<subclass

name="ClassName" (1)

discriminator-value="discriminator_value" (2)

proxy="ProxyInterface" (3)

lazy="true|false" (4)

dynamic-update="true|false"

dynamic-insert="true|false"

entity-name="EntityName"

node="element-name"

extends="SuperclassName">

.....

</subclass>

(1)	name: The fully qualified class name of the subclass. (サブクラスの完全修飾されたクラス名。)
(2)	discriminator-value (optional - defaults to the class name)(オプション - デフォルトはクラス名): A value that distiguishes individual subclasses.( 個々のサブクラスを区別するための値。)
(3)	proxy (optional)(オプション): Specifies a class or interface to use for lazy initializing proxies. (遅延初期化プロキシに使うクラスやインターフェイスを指定します。)
(4)	lazy (optional, defaults to true): (オプション - デフォルトはtrue)Setting lazy="false"disables the use of lazy fetching. (azy="false"と設定すると、遅延フェッチが使用できません。)

Each subclass should declare its own persistent properties and subclasses. <version> and<id> properties are assumed to be inherited from the root class. Each subclass in a heirarchy must define a unique discriminator-value. If none is specified, the fully qualified Java class name is used.

各サブクラスでは、永続プロパティとサブクラスを定義します。versionとidプロパティは、ルートクラスから継承されると仮定されます。階層構造におけるサブクラスは、ユニークなdiscriminator-valueを定義しなければなりません。noneが指定されると、完全修飾されたJavaクラス名が使われます。

For information about inheritance mappings, see Chapter 9, Inheritance Mapping.

継承のマッピングに関する情報はChapter 9, Inheritance Mappingを見てください。

5.1.16. joined-subclass

Alternatively, each subclass may be mapped to its own table (table-per-subclass mapping strategy). Inherited state is retrieved by joining with the table of the superclass. We use the <joined-subclass> element.

もう1つの方法として、各サブクラスを自身のテーブルへマッピングすることができます(table-per-subclass mapping strategy)。継承した状態はスーパークラスのテーブルを使った結合で検索します。<joined-subclass>要素を使用します。

<joined-subclass

name="ClassName" (1)

table="tablename" (2)

proxy="ProxyInterface" (3)

lazy="true|false" (4)

dynamic-update="true|false"

dynamic-insert="true|false"

schema="schema"

catalog="catalog"

extends="SuperclassName"

persister="ClassName"

subselect="SQL expression"

entity-name="EntityName"

node="element-name">

.....

</joined-subclass>

(1)	name: The fully qualified class name of the subclass. (サブクラスの完全修飾されたクラス名。)
(2)	table: The name of the subclass table. (サブクラステーブル名)
(3)	proxy (optional)(オプション): Specifies a class or interface to use for lazy initializing proxies. (遅延初期化プロキシに使用するクラスやインターフェイスを指定します。)
(4)	lazy (optional, defaults to true)(オプション - デフォルトはtrue): Setting lazy="false"disables the use of lazy fetching. (lazy="false"とすると、遅延フェッチが使用できません。)

No discriminator column is required for this mapping strategy. Each subclass must, however, declare a table column holding the object identifier using the <key> element. The mapping at the start of the chapter would be re-written as:

このマッピング戦略には、識別カラムは必要ありません。しかし各サブクラスは<key>要素を使い、オブジェクト識別子を保持するテーブルカラムを定義しなければなりません。この章の初めのマッピングは以下のように書き直せます：

<?xml version="1.0"?>

<!DOCTYPE hibernate-mapping PUBLIC

"-//Hibernate/Hibernate Mapping DTD//EN"

"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping package="eg">

</id>

<many-to-one name="mate"/>

<one-to-many class="Cat"/>

</set>

<joined-subclass name="DomesticCat" table="DOMESTIC_CATS">

</joined-subclass>

</class>

</class>

</hibernate-mapping>

For information about inheritance mappings, see Chapter 9, Inheritance Mapping.

継承のマッピングに関する情報はChapter 9, Inheritance Mappingを見てください。

5.1.17. union-subclass

A third option is to map only the concrete classes of an inheritance hierarchy to tables, (the table-per-concrete-class strategy) where each table defines all persistent state of the class, including inherited state. In Hibernate, it is not absolutely necessary to explicitly map such inheritance hierarchies. You can simply map each class with a separate <class> declaration. However, if you wish use polymorphic associations (e.g. an association to the superclass of your hierarchy), you need to use the <union-subclass>mapping.

3つ目の選択肢は、継承階層の具象クラスのみをテーブルにマッピングすることです(the table-per-concrete-class戦略)。それぞれのテーブルは継承の状態を含めすべてのクラスの永続状態を定義します。Hibernateではその様な継承階層が必ずしも必要ではありません。単純にそれぞれのクラスを、別々の<class>宣言を使ってマッピングすることができます。しかしポリモーフィックな関連(例えば階層のスーパークラスへの関連)を使いたいなら、union-subclassマッピングを使う必要があります。

<union-subclass

name="ClassName" (1)

table="tablename" (2)

proxy="ProxyInterface" (3)

lazy="true|false" (4)

dynamic-update="true|false"

dynamic-insert="true|false"

schema="schema"

catalog="catalog"

extends="SuperclassName"

abstract="true|false"

persister="ClassName"

subselect="SQL expression"

entity-name="EntityName"

node="element-name">

.....

</union-subclass>

(1)	name: The fully qualified class name of the subclass. (サブクラスの完全修飾されたクラス名。)
(2)	table: The name of the subclass table. (サブクラステーブル名)
(3)	proxy (optional)(オプション): Specifies a class or interface to use for lazy initializing proxies. (遅延初期化プロキシに使用するクラスやインターフェイスを指定します。)
(4)	lazy (optional, defaults to true)(オプション - デフォルトはtrue): Setting lazy="false"disables the use of lazy fetching.( lazy="false"とすると、遅延フェッチが使用できません。)

No discriminator column or key column is required for this mapping strategy.

このマッピング戦略では識別カラムやキーカラムは必要ありません。

For information about inheritance mappings, see Chapter 9, Inheritance Mapping.

継承のマッピングに関する情報はChapter 9, Inheritance Mappingを見てください。

5.1.18. join

Using the <join> element, it is possible to map properties of one class to several tables.

<join>要素を使うことで、１つのクラスのプロパティをいくつものテーブルにマッピングすることができます。

<join

table="tablename" (1)

schema="owner" (2)

catalog="catalog" (3)

fetch="join|select" (4)

inverse="true|false" (5)

optional="true|false"> (6)

...

</join>

(1)	table: The name of the joined table. (結合したテーブルの名前)
(2)	schema (optional)(オプション): Override the schema name specified by the root<hibernate-mapping> element. (ルートの<hibernate-mapping>要素で指定したスキーマ名をオーバーライドします。)
(3)	catalog (optional)(オプション): Override the catalog name specified by the root<hibernate-mapping> element. (ルートの<hibernate-mapping>要素で指定したカタログ名をオーバーライドします。)
(4)	fetch (optional - defaults to join)(オプション - デフォルトはjoin): If set to join, the default, Hibernate will use an inner join to retrieve a <join> defined by a class or its superclasses and an outer join for a <join> defined by a subclass. If set to select then Hibernate will use a sequential select for a <join> defined on a subclass, which will be issued only if a row turns out to represent an instance of the subclass. Inner joins will still be used to retrieve a <join> defined by the class and its superclasses. (joinを設定した場合、Hibernateはデフォルトで、クラスやスーパークラスで定義された<join>を検索するのに内部結合を使い、サブクラスで定義された<join>を検索するのに外部結合を使います。selectを設定した場合には、Hibernateはサブクラスで定義された<join>の選択に順次選択を使います。この場合、行がサブクラスのインスタンスを代表することがわかった場合にのみ発行されます。内部結合はクラスやそのスーパークラスで定義された<join>を検索するために使用します。)
(5)	inverse (optional - defaults to false)(オプション - デフォルトはfalse): If enabled, Hibernate will not try to insert or update the properties defined by this join. (もし可能であれば、Hibernateはこの結合で定義されているプロパティに対し挿入や更新を行いません。)
(6)	optional (optional - defaults to false) (オプション - デフォルトはfalse): If enabled, Hibernate will insert a row only if the properties defined by this join are non-null and will always use an outer join to retrieve the properties. (もし可能であれば、Hibernateはこの結合で定義されたプロパティがnullでない場合にのみ行を挿入し、そのプロパティの検索には常に外部結合を使用します。)

For example, the address information for a person can be mapped to a separate table (while preserving value type semantics for all properties):

例えば人のアドレスの情報を分離したテーブルにマッピングすることが可能です(すべてのプロパティに対して値型のセマンティクスを保持します)。

<class name="Person"

table="PERSON">

</join>

...

This feature is often only useful for legacy data models, we recommend fewer tables than classes and a fine-grained domain model. However, it is useful for switching between inheritance mapping strategies in a single hierarchy, as explained later.

この特徴はしばしばレガシーデータモデルに対してのみ有用ですが、クラスよりも少ないテーブルと、きめの細かいドメインモデルを推奨します。しかし後で説明するように、１つのクラス階層で継承のマッピング戦略を切り替える時には有用です。

5.1.19. key

We've seen the <key> element crop up a few times now. It appears anywhere the parent mapping element defines a join to a new table, and defines the foreign key in the joined table, that references the primary key of the original table.

今まで何度か<key>要素が出てきました。この要素は新しいテーブルへの結合を定義したり、結合テーブルで外部キーを定義したりする親要素のどこにでも現れ、オリジナルテーブルの主キーを参照します。

<key

column="columnname" (1)

on-delete="noaction|cascade" (2)

property-ref="propertyName" (3)

not-null="true|false" (4)

update="true|false" (5)

unique="true|false" (6)

(1)	column (optional)(オプション): The name of the foreign key column. This may also be specified by nested <column> element(s). (column(オプション):外部キーカラムの名前。ネストした<column>カラムによっても指定されます。)
(2)	on-delete (optional, defaults to noaction) (オプション - デフォルトはnoaction): Specifies whether the foreign key constraint has database-level cascade delete enabled.( 外部キー制約がデータベースレベルでカスケード削除が可能かどうかを指定します。)
(3)	property-ref (optional) (オプション): Specifies that the foreign key refers to columns that are not the primary key of the orginal table. (Provided for legacy data.) (オリジナルテーブルの主キーではないカラムを参照する外部キーを指定します(レガシーデータに対して提供されます)。)
(4)	not-null (optional) (オプション): Specifies that the foreign key columns are not nullable (this is implied whenever the foreign key is also part of the primary key). (外部キーカラムがnull値を許容しないことを指定します(このことは外部キーが主キーの一部であることを暗黙的に示します)。)
(5)	update (optional) (オプション): Specifies that the foreign key should never be updated (this is implied whenever the foreign key is also part of the primary key). (外部キーを決して更新してはならないことを指定します(このことは外部キーが主キーの一部であることを暗黙的に示します)。)
(6)	unique (optional) (オプション): Specifies that the foreign key should have a unique constraint (this is implied whenever the foreign key is also the primary key). (外部キーがユニーク制約を持つべきであることを指定します(このことは外部キーが主キーの一部であることを暗黙的に示します)。)

We recommend that for systems where delete performance is important, all keys should be defined on-delete="cascade", and Hibernate will use a database-level ON CASCADE DELETE constraint, instead of many individual DELETE statements. Be aware that this feature bypasses Hibernate's usual optimistic locking strategy for versioned data.

削除のパフォーマンスが重要であるシステムには、すべてのキーをon-delete="cascade"と定義することを推奨します。そうすることでHibernateは、DELETE文を毎回発行する代わりに、データベースレベルのON CASCADE DELETE制約を使用します。この特徴はバージョン付けられたデータに対するHibernateの通常の楽観的ロック戦略を無視するということに注意してください。

The not-null and update attributes are useful when mapping a unidirectional one to many association. If you map a unidirectional one to many to a non-nullable foreign key, you must declare the key column using <key not-null="true">.

not-nullとupdate属性は、単方向一対多関連の時には有用です。単方向一対多関連をnullを許容しない外部キーにマッピングするときは、<key not-null="true">を使ってキーカラムを宣言しなくてはなりません。

5.1.20. column and formula elements

Any mapping element which accepts a column attribute will alternatively accept a<column> subelement. Likewise, <formula> is an alternative to the formula attribute.

column属性を記述できる任意のマッピング要素はまた、<column>サブ要素も記述できます。同様に<formula>もformula属性の代替手段です。

<column

name="column_name"

length="N"

precision="N"

scale="N"

not-null="true|false"

unique="true|false"

unique-key="multicolumn_unique_key_name"

index="index_name"

sql-type="sql_type_name"

check="SQL expression"

default="SQL expression"/>

<formula>SQL expression</formula>

column and formula attributes may even be combined within the same property or association mapping to express, for example, exotic join conditions.

同じプロパティや関連のマッピングの中で、columnとformula属性を組み合わせることができます。例えば、特殊な結合条件などです。

<many-to-one name="homeAddress" class="Address"

insert="false" update="false">

<formula>'MAILING'</formula>

</many-to-one>

5.1.21. import

Suppose your application has two persistent classes with the same name, and you don't want to specify the fully qualified (package) name in Hibernate queries. Classes may be "imported" explicitly, rather than relying upon auto-import="true". You may even import classes and interfaces that are not explicitly mapped.

アプリケーションに同じ名前の2つの永続クラスがあり、Hibernateクエリで完全修飾された（パッケージの）名前を指定したくないと仮定します。そのような場合はauto-import="true"に頼らず、クラスが「インポート」されたものであると明示できます。明示的にマッピングされていないクラスやインターフェイスでさえもインポートできます。

<import

class="ClassName" (1)

rename="ShortName" (2)

(1)	class: The fully qualified class name of any Java class. (Javaクラスの完全修飾されたクラス名。)
(2)	rename (optional - defaults to the unqualified class name)(オプション - デフォルトは修飾されていないクラス名): A name that may be used in the query language.( クエリ言語で使われる名前。)

5.1.22. any

There is one further type of property mapping. The <any> mapping element defines a polymorphic association to classes from multiple tables. This type of mapping always requires more than one column. The first column holds the type of the associated entity. The remaining columns hold the identifier. It is impossible to specify a foreign key constraint for this kind of association, so this is most certainly not meant as the usual way of mapping (polymorphic) associations. You should use this only in very special cases (eg. audit logs, user session data, etc).

プロパティマッピングにはさらにもう1つの型があります。<any>マッピング要素は、複数のテーブルからクラスへのポリモーフィックな関連を定義します。この型のマッピングには必ず複数のカラムが必要です。1番目のカラムは関連エンティティの型を保持します。残りのカラムは識別子を保持します。この種類の関連には外部キー制約を指定することはできません。そのためこれは最も使われることのない（ポリモーフィックな）関連のマッピング方法です。非常に特別な場合（例えば、検査ログやユーザセッションデータなど)に限って、これを使うべきです。

The meta-type attribute lets the application specify a custom type that maps database column values to persistent classes which have identifier properties of the type specified by id-type. You must specify the mapping from values of the meta-type to class names.

meta-typeにより、アプリケーションはカスタム型を指定できます。このカスタム型はデータベースカラムの値を、id-typeで指定した型の識別子プロパティを持った永続クラスへマッピングします。meta-typeの値からクラス名へのマッピングを指定しなければなりません。

</any>

<any

name="propertyName" (1)

id-type="idtypename" (2)

meta-type="metatypename" (3)

cascade="cascade_style" (4)

access="field|property|ClassName" (5)

optimistic-lock="true|false" (6)

<meta-value ... />

.....

.....

</any>

(1)	name: the property name. (プロパティ名)
(2)	id-type: the identifier type. (識別子の型。)
(3)	meta-type (optional - defaults to string)(オプション - デフォルトはstring): Any type that is allowed for a discriminator mapping. (ディスクリミネータマッピングで許された型)
(4)	cascade (optional- defaults to none) (オプション - デフォルトはnone): the cascade style. (カスケードのスタイル。)
(5)	access (optional - defaults to property) (オプション - デフォルトはproperty): The strategy Hibernate should use for accessing the property value. (プロパティの値へのアクセスにHibernateが使う戦略。)
(6)	optimistic-lock (optional - defaults to true) (オプション - デフォルトはtrue): Specifies that updates to this property do or do not require acquisition of the optimistic lock. In other words, define if a version increment should occur if this property is dirty. (このプロパティの更新に楽観ロックの取得を要求するかどうかを指定します。言い換えれば、このプロパティがダーティであるときにバージョンを増やすべきかを定義します。)

5.2. Hibernate Types(Hibernateの型)

5.2.1. Entities and values(エンティティと値)

To understand the behaviour of various Java language-level objects with respect to the persistence service, we need to classify them into two groups:

永続サービスに関わる様々なJava言語レベルのオブジェクトの振る舞いを理解するためには、オブジェクトを2つのグループに分ける必要があります：

An entity exists independently of any other objects holding references to the entity. Contrast this with the usual Java model where an unreferenced object is garbage collected. Entities must be explicitly saved and deleted (except that saves and deletions may be cascaded from a parent entity to its children). This is different from the ODMG model of object persistence by reachablity - and corresponds more closely to how application objects are usually used in large systems. Entities support circular and shared references. They may also be versioned.

エンティティはエンティティへの参照を保持する、他のすべてのオブジェクトから独立して存在します。参照されないオブジェクトがガベージコレクトされてしまう性質を持つ通常のJavaモデルと、これを比べてみてください。（親エンティティから子へ、セーブと削除がカスケードされうることを除いて）エンティティは明示的にセーブまたは削除されなければなりません。これは到達可能性によるオブジェクト永続化のODMGモデルとは異なっています。大規模なシステムでアプリケーションオブジェクトが普通どのように使われるかにより密接に対応します。エンティティは循環と参照の共有をサポートします。またそれらはバージョン付けすることもできます。

An entity's persistent state consists of references to other entities and instances of valuetypes. Values are primitives, collections (not what's inside a collection), components and certain immutable objects. Unlike entities, values (in particular collections and components) are persisted and deleted by reachability. Since value objects (and primitives) are persisted and deleted along with their containing entity they may not be independently versioned. Values have no independent identity, so they cannot be shared by two entities or collections.

エンティティの永続状態は他のエンティティや値型のインスタンスへの参照から構成されます。値はプリミティブ、コレクション(コレクションの内部ではなく)、コンポーネント、不変オブジェクトです。エンティティとは違い、値は（特にコレクションとコンポーネントにおいて）、到達可能性による永続化や削除が行われます。値オブジェクト（とプリミティブ）は、包含するエンティティと一緒に永続化や削除が行われるので、それらを独立にバージョン付けすることはできません。値には独立したアイデンティティがないので、複数のエンティティやコレクションがこれを共有することはできません。

Up until now, we've been using the term "persistent class" to refer to entities. We will continue to do that. Strictly speaking, however, not all user-defined classes with persistent state are entities. A component is a user defined class with value semantics. A Java property of type java.lang.String also has value semantics. Given this definition, we can say that all types (classes) provided by the JDK have value type semantics in Java, while user-defined types may be mapped with entity or value type semantics. This decision is up to the application developer. A good hint for an entity class in a domain model are shared references to a single instance of that class, while composition or aggregation usually translates to a value type.

これまで「永続クラス」という言葉をエンティティの意味で使ってきました。これからもそうしていきます。厳密に言うと、永続状態を持つユーザ定義のクラスのすべてがエンティティというわけではありません。コンポーネントは値のセマンティクスを持つユーザ定義クラスです。java.lang.String型のプロパティもまた値のセマンティクスを持ちます。定義するなら、JDKで提供されているすべてのJavaの型(クラス)が値のセマンティクスを持つといえます。一方ユーザ定義型は、エンティティや値型のセマンティクスとともにマッピングできます。この決定はアプリケーション開発者次第です。そのクラスの１つのインスタンスへの共有参照は、ドメインモデル内のエンティティクラスに対する良いヒントになります。一方合成集約や集約は、通常値型へ変換されます。

We'll revisit both concepts throughout the documentation.

本ドキュメントを通して、何度もこの概念を取り上げます。

The challenge is to map the Java type system (and the developers' definition of entities and value types) to the SQL/database type system. The bridge between both systems is provided by Hibernate: for entities we use <class>, <subclass> and so on. For value types we use <property>, <component>, etc, usually with a type attribute. The value of this attribute is the name of a Hibernate mapping type. Hibernate provides many mappings (for standard JDK value types) out of the box. You can write your own mapping types and implement your custom conversion strategies as well, as you'll see later.

Java型のシステム(もしくは開発者が定義したエンティティと値型)をSQL/データベース型のシステムにマッピングすることは難しいです。Hibernateは２つのシステムの架け橋を提供します。エンティティに対しては <class>や<subclass>などを使用します。値型に対しては>property>や <component>などを、通常typeとともに使います。この属性の値はHibernateのマッピング型の名前です。Hibernateは(標準JDKの値型に対して)多くの自由なマッピングを提供します。後で見るように、自身のマッピング型を記述し、同様にカスタムの変換戦略を実装することができます。

All built-in Hibernate types except collections support null semantics.

コレクションを除く組み込みのHibernateの型はすべて、nullセマンティクスをサポートします。

5.2.2. Basic value types(基本的な型)

The built-in basic mapping types may be roughly categorized into

組み込みの基本的なマッピング型は大まかに以下のように分けられます。

integer, long, short, float, double, character, byte, boolean, yes_no, true_false

Type mappings from Java primitives or wrapper classes to appropriate (vendor-specific) SQL column types. boolean, yes_no and true_false are all alternative encodings for a Java boolean or java.lang.Boolean.

Javaのプリミティブやラッパークラスから適切な（ベンダー固有の）SQLカラム型への型マッピング。boolean, yes_noとtrue_falseは、すべてJavaのbooleanまたはjava.lang.Booleanの代替エンコードです。

string

A type mapping from java.lang.String to VARCHAR (or Oracle VARCHAR2).

java.lang.StringからVARCHAR（またはOracleのVARCHAR2）への型マッピング。

date, time, timestamp

Type mappings from java.util.Date and its subclasses to SQL types DATE, TIME andTIMESTAMP (or equivalent).

java.util.DateとそのサブクラスからSQL型のDATE, TIME,TIMESTAMP（またはそれらと等価なもの）への型マッピング。

calendar, calendar_date

Type mappings from java.util.Calendar to SQL types TIMESTAMP and DATE (or equivalent).

java.util.CalendarからSQL型の「TIMESTAMP, DATE(またはそれらと等価なもの）への型マッピング。

big_decimal, big_integer

Type mappings from java.math.BigDecimal and java.math.BigInteger to NUMERIC (or Oracle NUMBER).

java.math.BigDecimalとjava.math.BigIntegerからNUMERIC（またはOracleのNUMBER）への型マッピング。

locale, timezone, currency

Type mappings from java.util.Locale, java.util.TimeZone and java.util.Currency toVARCHAR (or Oracle VARCHAR2). Instances of Locale and Currency are mapped to their ISO codes. Instances of TimeZone are mapped to their ID.

java.util.Locale,java.util.TimeZone, java.util.CurrencyからVARCHAR（またはOracleのVARCHAR2）への型マッピング。LocaleとCurrencyのインスタンスは、それらのISOコードにマッピングされます。 TimeZoneのインスタンスは、それらのIDにマッピングされます。

class

A type mapping from java.lang.Class to VARCHAR (or Oracle VARCHAR2). A Class is mapped to its fully qualified name.

java.lang.ClassからVARCHAR（またはOracleのVARCHAR2）への型マッピング。Classはその完全修飾された名前にマッピングされます。

binary

Maps byte arrays to an appropriate SQL binary type.

バイト配列は、適切なSQLのバイナリ型にマッピングされます。

text

Maps long Java strings to a SQL CLOB or TEXT type.

長いJava文字列は、SQLのCLOBまたは TEXT型にマッピングされます。

serializable

Maps serializable Java types to an appropriate SQL binary type. You may also indicate the Hibernate type serializable with the name of a serializable Java class or interface that does not default to a basic type.

シリアライズ可能なJava型は、適切なSQLのバイナリ型にマッピングされます。デフォルトで基本型ではないシリアライズ可能なJavaクラスやインターフェイスの名前を指定することで、Hibernateの型をserializableとすることもできます。

clob, blob

Type mappings for the JDBC classes java.sql.Clob and java.sql.Blob. These types may be inconvenient for some applications, since the blob or clob object may not be reused outside of a transaction. (Furthermore, driver support is patchy and inconsistent.)

JDBCクラスjava.sql.Clobとjava.sql.Blobに対する型マッピング。blobやclobオブジェクトはトランザクションの外では再利用できないため、アプリケーションによっては不便かもしれません。（さらにはドライバサポートが一貫していません。）

imm_date, imm_time, imm_timestamp, imm_calendar, imm_calendar_date, imm_serializable, imm_binary

Type mappings for what are usually considered mutable Java types, where Hibernate makes certain optimizations appropriate only for immutable Java types, and the application treats the object as immutable. For example, you should not callDate.setTime() for an instance mapped as imm_timestamp. To change the value of the property, and have that change made persistent, the application must assign a new (nonidentical) object to the property.

ほとんどの場合に可変であるJavaの型に対する型マッピング。Hibernateは不変なJavaの型に対しては最適化を行い、アプリケーションはそれを不変オブジェクトとして扱います。例えばimm_timestampとしてマップしたインスタンスに対して、Date.setTime()を呼び出してはなりません。プロパティの値を変更しその変更を永続化するためには、アプリケーションはプロパティに対して新しい(同一でない)オブジェクトを割り当てなければなりません。

Unique identifiers of entities and collections may be of any basic type except binary,blob and clob. (Composite identifiers are also allowed, see below.)

エンティティとコレクションのユニークな識別子は、binary,blob, clobを除く、どんな基本型でも構いません。（複合識別子でも構いません。以下を見てください。）

The basic value types have corresponding Type constants defined onorg.hibernate.Hibernate. For example, Hibernate.STRING represents the string type.

基本的な値型には、org.hibernate.Hibernateで定義されたType定数がそれぞれあります。例えば、Hibernate.STRINGはstring型を表現しています。

5.2.3. Custom value types(カスタム型)

It is relatively easy for developers to create their own value types. For example, you might want to persist properties of type java.lang.BigInteger to VARCHAR columns. Hibernate does not provide a built-in type for this. But custom types are not limited to mapping a property (or collection element) to a single table column. So, for example, you might have a Java property getName()/setName() of type java.lang.String that is persisted to the columns FIRST_NAME, INITIAL, SURNAME.

開発者が独自の値型を作成することは、比較的簡単です。例えば、java.lang.BigInteger型のプロパティをVARCHARカラムに永続化したいかもしれません。Hibernateはこのための組み込み型を用意していませんしかしカスタム型は、プロパティ（またはコレクションの要素）を1つのテーブルカラムにマッピングするのに制限はありません。そのため例えば、java.lang.String型の getName()/setName()JavaプロパティをFIRST_NAME,INITIAL,SURNAMEカラムに永続化できます。

To implement a custom type, implement either org.hibernate.UserType ororg.hibernate.CompositeUserType and declare properties using the fully qualified classname of the type. Check out org.hibernate.test.DoubleStringType to see the kind of things that are possible.

カスタム型を実装するには、org.hibernate.UserTypeまたはorg.hibernate.CompositeUserTypeを実装し、型の完全修飾された名前を使ってプロパティを定義します。どのような種類のものが可能かを調べるには、org.hibernate.test.DoubleStringTypeを確認してください。

</property>

Notice the use of <column> tags to map a property to multiple columns.

タグで、プロパティを複数のカラムへマッピングできることに注目してください。

The CompositeUserType, EnhancedUserType, UserCollectionType, and UserVersionTypeinterfaces provide support for more specialized uses.

CompositeUserType,EnhancedUserType,UserCollectionType,UserVersionTypeインターフェイスは、より特殊な使用法に対してのサポートを提供します。

You may even supply parameters to a UserType in the mapping file. To do this, yourUserType must implement the org.hibernate.usertype.ParameterizedType interface. To supply parameters to your custom type, you can use the <type> element in your mapping files.

マッピングファイル内でUserTypeへパラメータを提供できます。このためには、UserTypeはorg.hibernate.usertype.ParameterizedTypeを実装しなくてはなりません。カスタム型パラメータを提供するために、マッピングファイル内で<type>要素を使用できます。

</type>

</property>

The UserType can now retrieve the value for the parameter named default from theProperties object passed to it.

UserTypeは、引数として渡されたPropertiesオブジェクトから、defaultで指定したパラメータに対する値を検索することができます。

If you use a certain UserType very often, it may be useful to define a shorter name for it. You can do this using the <typedef> element. Typedefs assign a name to a custom type, and may also contain a list of default parameter values if the type is parameterized.

特定のUserTypeを頻繁に使用するならば、短い名前を定義すると便利になるでしょう。<typedef>要素を使ってこのようなことが行えます。Typedefsはカスタム型に名前を割り当てます。その型がパラメータを持つならば、パラメータのデフォルト値のリストを含むこともできます。

</typedef>

It is also possible to override the parameters supplied in a typedef on a case-by-case basis by using type parameters on the property mapping.

プロパティのマッピングで型パラメータを使うことでtypedefで提供されたパラメータをその都度オーバーライドすることが可能です。

Even though Hibernate's rich range of built-in types and support for components means you will very rarely need to use a custom type, it is nevertheless considered good form to use custom types for (non-entity) classes that occur frequently in your application. For example, a MonetaryAmount class is a good candidate for a CompositeUserType, even though it could easily be mapped as a component. One motivation for this is abstraction. With a custom type, your mapping documents would be future-proofed against possible changes in your way of representing monetary values.

Hibernateの幅広い組み込み型とコンポーネントに対するサポートは、カスタム型をめったに使わないということを意味します。それでもなお、アプリケーションで頻出する(エンティティではない)クラスに対するカスタム型の使用は、よいやり方であるとみなされます。例えばMonetaryAmountクラスはコンポーネントとして簡単にマッピングできますが、CompositeUserTypeの良い候補です。カスタム型を使用する動機の1つは抽象化です。カスタム型を使うことで、通貨をどのように表現しようともマッピングドキュメントは起こりうる変化に対応できます。

5.3. Mapping a class more than once(1つのクラスに１つ以上のマッピング)

It is possible to provide more than one mapping for a particular persistent class. In this case you must specify an entity name do disambiguate between instances of the two mapped entities. (By default, the entity name is the same as the class name.) Hibernate lets you specify the entity name when working with persistent objects, when writing queries, or when mapping associations to the named entity.

ある永続クラスに、一つ以上のマッピングを提供することが出来ます。この場合、マッピングする２つのエンティティのインスタンスを明確にするために、エンティティ名を指定しなければなりません(デフォルトではエンティティ名はクラス名と同じです。)。永続オブジェクトを扱うとき、クエリを書き込むとき、指定されたエンティティへの関連をマッピングするときには、Hibernateではエンティティ名を指定しなければなりません。

<class name="Contract" table="Contracts"

entity-name="CurrentContract">

...

<set name="history" inverse="true"

order-by="effectiveEndDate desc">

<one-to-many entity-name="HistoricalContract"/>

</set>

</class>

<class name="Contract" table="ContractHistory"

entity-name="HistoricalContract">

...

<many-to-one name="currentContract"

column="currentContractId"

entity-name="CurrentContract"/>

</class>

Notice how associations are now specified using entity-name instead of class.

関連がclassの代わりにentity-nameを使って、どのように指定されるのかに注目してください。

5.4. SQL quoted identifiers

You may force Hibernate to quote an identifier in the generated SQL by enclosing the table or column name in backticks in the mapping document. Hibernate will use the correct quotation style for the SQL Dialect (usually double quotes, but brackets for SQL Server and backticks for MySQL).

マッピングドキュメントでテーブルやカラムの名前をバッククォートで囲むことで、Hibernateで生成されたSQL中の識別子を引用させることができます。HibernateはSQLのDialectに対応する、正しい引用スタイルを使います（普通はダブルクォートですが、SQL Serverではかぎ括弧、MySQLではバッククォートです）。

...

</class>

5.5. Metadata alternatives(メタデータの代替手段)

XML isn't for everyone, and so there are some alternative ways to define O/R mapping metadata in Hibernate.

XMLの記述以外に、HibernateではO/Rマッピングのメタデータを定義する代替方法があります。

5.5.1. Using XDoclet markup(XDoclet マークアップの使用)

Many Hibernate users prefer to embed mapping information directly in sourcecode using XDoclet @hibernate.tags. We will not cover this approach in this document, since strictly it is considered part of XDoclet. However, we include the following example of the Catclass with XDoclet mappings.

多くのHibernateユーザはXDocletの@hibernate.tagsを使って、ソースコード内に直接マッピング情報を埋め込むことを好みます。これは厳密に言えばXDocletの分野なので、本ドキュメントではこの方法を対象とはしません。しかしXDocletを使った以下のCatマッピングの例を示します。

package eg;

import java.util.Set;

import java.util.Date;

/**

* @hibernate.class

* table="CATS"

public class Cat {

private Long id; // identifier

private Date birthdate;

private Cat mother;

private Set kittens

private Color color;

private char sex;

private float weight;

* @hibernate.id

* generator-class="native"

* column="CAT_ID"

public Long getId() {

return id;

}

private void setId(Long id) {

this.id=id;

}

/**

* @hibernate.many-to-one

* column="PARENT_ID"

public Cat getMother() {

return mother;

}

void setMother(Cat mother) {

this.mother = mother;

}

/**

* @hibernate.property

* column="BIRTH_DATE"

public Date getBirthdate() {

return birthdate;

}

void setBirthdate(Date date) {

birthdate = date;

}

/**

* @hibernate.property

* column="WEIGHT"

public float getWeight() {

return weight;

}

void setWeight(float weight) {

this.weight = weight;

}

/**

* @hibernate.property

* column="COLOR"

* not-null="true"

public Color getColor() {

return color;

}

void setColor(Color color) {

this.color = color;

}

/**

* @hibernate.set

* inverse="true"

* order-by="BIRTH_DATE"

* @hibernate.collection-key

* column="PARENT_ID"

* @hibernate.collection-one-to-many

public Set getKittens() {

return kittens;

}

void setKittens(Set kittens) {

this.kittens = kittens;

}

// addKitten not needed by Hibernate

public void addKitten(Cat kitten) {

kittens.add(kitten);

}

/**

* @hibernate.property

* column="SEX"

* not-null="true"

* update="false"

public char getSex() {

return sex;

}

void setSex(char sex) {

this.sex=sex;

}

See the Hibernate web site for more examples of XDoclet and Hibernate.

Hibernateのウェブサイトには、XDocletとHibernateに関するサンプルが多数あります。

5.5.2. Using JDK 5.0 Annotations(JDK 5.0 アノテーションの使用)

JDK 5.0 introduced XDoclet-style annotations at the language level, type-safe and checked at compile time. This mechnism is more powerful than XDoclet annotations and better supported by tools and IDEs. IntelliJ IDEA, for example, supports auto-completion and syntax highlighting of JDK 5.0 annotations. The new revision of the EJB specification (JSR-220) uses JDK 5.0 annotations as the primary metadata mechanism for entity beans. Hibernate3 implements the EntityManager of JSR-220 (the persistence API), support for mapping metadata is available via the Hibernate Annotations package, as a separate download. Both EJB3 (JSR-220) and Hibernate3 metadata is supported.

JDK5.0ではタイプセーフかつコンパイル時にチェックできる、言語レベルのXDocletスタイルのアノテーションを導入しました。このメカニズムはXDocletのアノテーションよりも強力で、ツールやIDEも多くがサポートしています。例えばIntelliJ IDEAは、JDK5.0にアノテーションの自動補完と構文の強調表示をサポートしています。EJB仕様 (JSR-220)の新しいバージョンでは、エンティティビーンに対する主要なメタデータメカニズムとしてJDK5.0のアノテーションを使用しています。Hibernate3ではJSR-220 (永続化API)のEntityManagerを実装し、メタデータマッピングに対するサポートは、別ダウンロードの Hibernate Annotationsパッケージにより利用可能です。これはEJB3(JSR-220)とHibernate3のメタデータをどちらもサポートしています。

This is an example of a POJO class annotated as an EJB entity bean:

以下はEJBのエンティティビーンとして注釈されたPOJOクラスの例です。

@Entity(access = AccessType.FIELD)

public class Customer implements Serializable {

@Id;

Long id;

String firstName;

String lastName;

Date birthday;

@Transient

Integer age;

@Embedded

private Address homeAddress;

@OneToMany(cascade=CascadeType.ALL)

@JoinColumn(name="CUSTOMER_ID")

Set<Order> orders;

// Getter/setter and business methods(getter/setterとビジネスメソッド)

}

Note that support for JDK 5.0 Annotations (and JSR-220) is still work in progress and not completed. Please refer to the Hibernate Annotations module for more details.

JDK5.0のアノテーション(とJSR-220)のサポートは進行中の作業であり、完全ではないことに注意してください。さらに詳しい情報はHibernateのアノテーション・モジュールを参照してください。

5.6. Generated Properties(生成プロパティ)

Generated properties are properties which have their values generated by the database. Typically, Hibernate applications needed to refresh objects which contain any properties for which the database was generating values. Marking properties as generated, however, lets the application delegate this responsibility to Hibernate. Essentially, whenever Hibernate issues an SQL INSERT or UPDATE for an entity which has defined generated properties, it immediately issues a select afterwards to retrieve the generated values.

生成プロパティとは、データベースによって生成された値を持つプロパティです。通常、Hibernateアプリケーションは、データベースが値を生成したプロパティを含むオブジェクトをリフレッシュする必要がありました。しかし、プロパティが生成されたということをマークすることで、アプリケーションはリフレッシュの責任をHibernateに委譲します。基本的に、生成プロパティを持つと定義したエンティティに対してHibernateがINSERTやUPDATEのSQLを発行した後すぐに、生成された値を読み込むための SELECT SQL が発行されます。

Properties marked as generated must additionally be non-insertable and non-updateable. Only Section 5.1.7, "version (optional)", Section 5.1.8, "timestamp (optional)", and Section 5.1.9, "property" can be marked as generated.

生成プロパティは、挿入不可能かつ更新不可能でなければなりません。Section 5.1.7, "version (optional)"versions 、Section 5.1.8, "timestamp (optional)"timestamps、Section 5.1.9, "property"simple propertiesだけが生成されたとマークできます。

never (the default) - means that the given property value is not generated within the database.

never(デフォルト) - 与えられたプロパティの値は、データベースから生成されないことを意味します。

insert - states that the given property value is generated on insert, but is not regenerated on subsequent updates. Things like created-date would fall into this category. Note that even thought Section 5.1.7, "version (optional)" and Section 5.1.8, "timestamp (optional)" properties can be marked as generated, this option is not available there...

insert- 与えられたプロパティの値は挿入時に生成されるが、続いて起こる更新時には生成されないこと示します。作成された日付などは、このカテゴリに分類されます。Section 5.1.7, "version (optional)"versionやSection 5.1.8, "timestamp (optional)"timestampのプロパティは生成されたとマークできますが、このオプションは利用できないことに注意してください。

always - states that the property value is generated both on insert and on update.

always- 挿入時も更新時もプロパティの値が生成されることを示します。

5.7. Auxiliary Database Objects(補助的なデータベース・オブジェクト)

Allows CREATE and DROP of arbitrary database objects, in conjunction with Hibernate's schema evolution tools, to provide the ability to fully define a user schema within the Hibernate mapping files. Although designed specifically for creating and dropping things like triggers or stored procedures, really any SQL command that can be run via ajava.sql.Statement.execute() method is valid here (ALTERs, INSERTS, etc). There are essentially two modes for defining auxiliary database objects...

Hibernateのスキーマ・エボリューションツールと連動することで、任意のデータベース・オブジェクト（トリガーやストアドプロシージャなど）のCREATEとDROPにより、Hibernateのマッピングファイル内のユーザ・スキーマをすべて定義することが出来ます。主にトリガやストアドプロシージャのようなデータベース・オブジェクトを生成や削除することを意図していますが、実際にはjava.sql.Statement.execute()メソッドによって実行できる任意のSQLコマンド（ALTER、INSERTなど）が実行できます。補助的なデータベース・オブジェクトを定義するための、2つの基本的な方法があります。

The first mode is to explicitly list the CREATE and DROP commands out in the mapping file:

1つ目の方法は、CREATEとDROPコマンドをマッピングファイルの外に、明示的に記載することです。

<hibernate-mapping>

...

<database-object>

<create>CREATE TRIGGER my_trigger ...</create>

<drop>DROP TRIGGER my_trigger</drop>

</database-object>

</hibernate-mapping>

The second mode is to supply a custom class which knows how to construct the CREATE and DROP commands. This custom class must implement theorg.hibernate.mapping.AuxiliaryDatabaseObject interface.

2つ目の方法は、CREATEとDROPコマンドの組み立て方を知っているカスタムクラスを提供することです。このカスタムクラスはorg.hibernate.mapping.AuxiliaryDatabaseObjectインタフェースを実装しなければなりません。

<hibernate-mapping>

...

<database-object>

</database-object>

</hibernate-mapping>

Additionally, these database objects can be optionally scoped such that they only apply when certain dialects are used.

さらに、あるデータベース方言が使用される時にだけ適用するといったように、データベース・オブジェクトが使われるケースを限定できます。

<hibernate-mapping>

...

<database-object>

<dialect-scope name="org.hibernate.dialect.Oracle9Dialect"/>

<dialect-scope name="org.hibernate.dialect.OracleDialect"/>

</database-object>

</hibernate-mapping>

abblog

Sunday, May 11, 2008

HIBERNATE - Relational Persistence for Idiomatic Java - 5

No comments:

Post a Comment

About Me