[hibernate-commits] Hibernate SVN: r14768 - core/tags/v326/doc/reference/ko/modules.
hibernate-commits at lists.jboss.org
hibernate-commits at lists.jboss.org
Sun Jun 15 10:39:43 EDT 2008
Author: jdkim528
Date: 2008-06-15 10:39:42 -0400 (Sun, 15 Jun 2008)
New Revision: 14768
Modified:
core/tags/v326/doc/reference/ko/modules/basic_mapping.xml
core/tags/v326/doc/reference/ko/modules/batch.xml
core/tags/v326/doc/reference/ko/modules/filters.xml
core/tags/v326/doc/reference/ko/modules/persistent_classes.xml
core/tags/v326/doc/reference/ko/modules/query_hql.xml
core/tags/v326/doc/reference/ko/modules/query_sql.xml
core/tags/v326/doc/reference/ko/modules/tutorial.xml
Log:
updated!
Modified: core/tags/v326/doc/reference/ko/modules/basic_mapping.xml
===================================================================
--- core/tags/v326/doc/reference/ko/modules/basic_mapping.xml 2008-06-15 14:36:50 UTC (rev 14767)
+++ core/tags/v326/doc/reference/ko/modules/basic_mapping.xml 2008-06-15 14:39:42 UTC (rev 14768)
@@ -1,7 +1,7 @@
<chapter id="mapping">
<title>기본 O/R 매핑</title>
- <sect1 id="mapping-declaration" revision="1">
+ <sect1 id="mapping-declaration" revision="2">
<title>매핑 선언</title>
<para>
@@ -26,22 +26,22 @@
<hibernate-mapping package="eg">
- <class name="Cat"
+ <class name="Cat"
table="cats"
discriminator-value="C">
-
+
<id name="id">
<generator class="native"/>
</id>
- <discriminator column="subclass"
+ <discriminator column="subclass"
type="character"/>
<property name="weight"/>
<property name="birthdate"
- type="date"
- not-null="true"
+ type="date"
+ not-null="true"
update="false"/>
<property name="color"
@@ -50,7 +50,7 @@
update="false"/>
<property name="sex"
- not-null="true"
+ not-null="true"
update="false"/>
<property name="litterId"
@@ -71,7 +71,7 @@
<subclass name="DomesticCat"
discriminator-value="D">
- <property name="name"
+ <property name="name"
type="string"/>
</subclass>
@@ -85,9 +85,9 @@
</hibernate-mapping>]]></programlisting>
<para>
- 우리는 이제 매핑 문서의 내용을 논의할 것이다. 우리는 Hibernate에 의해 실행 시에 사용되는 문서 요소들과
- 속성들 만을 설명할 것이다. 매핑 문서는 또한 스키마 내보내기 도구에 의해 내보내진 데이터베이스 스키마에
- 영향을 주는 어떤 특별한 옵션 속성들과 요소들을 포함한다. (예를 들어 <literal>not-null</literal> 속성.)
+ 우리는 이제 매핑 문서의 내용을 논의할 것이다. 우리는 Hibernate에 의해 실행 시에 사용되는 문서 요소들과
+ 속성들 만을 설명할 것이다. 매핑 문서는 또한 스키마 내보내기 도구에 의해 내보내진 데이터베이스 스키마에
+ 영향을 주는 어떤 특별한 옵션 속성들과 요소들을 포함한다. (예를 들어 <literal>not-null</literal> 속성.)
</para>
@@ -148,8 +148,8 @@
&types;
</hibernate-mapping>]]></programlisting>
<para>
- 여기서 <literal>types.xml</literal>은 <literal>your.domain</literal> 패키지 내에 있는 리소스이고
- 맞춤형 <xref linkend="mapping-types-custom">typedef</xref>를 포함한다.
+ 여기서 <literal>types.xml</literal>은 <literal>your.domain</literal> 패키지 내에 있는 리소스이고
+ 맞춤형 <xref linkend="mapping-types-custom">typedef</xref>를 포함한다.
</para>
</sect3>
</sect2>
@@ -158,11 +158,11 @@
<title>hibernate-mapping</title>
<para>
- 이 요소는 몇 개의 선택적인 속성들을 갖는다. <literal>schema</literal> 속성과 <literal>catalog</literal>
- 속성은 이 매핑 내에서 참조된 테이블들이 명명된 schema 와/또는 catalog에 속한다는 점을 지정한다. 만일 지정될 경우,
- 테이블 이름들은 주어진 schema 이름과 catalog 이름에 의해 한정(수식)될 것이다. 누락될 경우, 테이블 이름들은
- 한정되지((수식어가 붙지) 않을 것이다. <literal>default-cascade</literal> 속성은 <literal>cascade</literal>
- 속성을 지정하지 않은 프로퍼티들과 콜렉션들에 대해 전제될 <literal>cascade</literal> 스타일이 무엇인지를 지정한다.
+ 이 요소는 몇 개의 선택적인 속성들을 갖는다. <literal>schema</literal> 속성과 <literal>catalog</literal>
+ 속성은 이 매핑 내에서 참조된 테이블들이 명명된 schema 와/또는 catalog에 속한다는 점을 지정한다. 만일 지정될 경우,
+ 테이블 이름들은 주어진 schema 이름과 catalog 이름에 의해 한정(수식)될 것이다. 누락될 경우, 테이블 이름들은
+ 한정되지((수식어가 붙지) 않을 것이다. <literal>default-cascade</literal> 속성은 <literal>cascade</literal>
+ 속성을 지정하지 않은 프로퍼티들과 콜렉션들에 대해 전제될 <literal>cascade</literal> 스타일이 무엇인지를 지정한다.
<literal>auto-import</literal> 속성은 디폴트로 우리가 질의 언어 속에서 수식어가 붙지 않은(unqualified)
클래스 이름들을 사용하게 할 것이다.
</para>
@@ -250,9 +250,9 @@
<title>class</title>
<para>
- 당신은 <literal>class</literal> 요소를 사용하여 영속 클래스를 선언할 수도 있다:
+ 당신은 <literal>class</literal> 요소를 사용하여 영속 클래스를 선언할 수도 있다:
</para>
-
+
<programlistingco>
<areaspec>
<area id="class1" coords="2 55"/>
@@ -305,7 +305,7 @@
<callout arearefs="class1">
<para>
<literal>name</literal> (옵션): 영속 클래스(또는 인터페이스)의 전체 수식어가 붙은 Java 클래스 이름.
- 만일 이 속성이 누락될 경우, 매핑이 non-POJO 엔티티라고 가정된다.
+ 만일 이 속성이 누락될 경우, 매핑이 non-POJO 엔티티라고 가정된다.
</para>
</callout>
<callout arearefs="class2">
@@ -316,7 +316,7 @@
<callout arearefs="class3">
<para>
<literal>discriminator-value</literal> (옵션 - 디폴트는 클래스 이름): 다형성(polymorphic) 특징에 사용되는,
- 개별 서브 클래스들를 구별짓는 값. 허용가능한 값들은<literal>null</literal>과 <literal>not null</literal>을 포함한다.
+ 개별 서브 클래스들를 구별짓는 값. 허용가능한 값들은<literal>null</literal>과 <literal>not null</literal>을 포함한다.
</para>
</callout>
<callout arearefs="class4">
@@ -328,43 +328,43 @@
<callout arearefs="class5">
<para>
<literal>schema</literal> (옵션): 루트 <literal><hibernate-mapping></literal> 요소에 의해 지정된
- 스키마 이름을 오버라이드 시킨다.
+ 스키마 이름을 오버라이드 시킨다.
</para>
</callout>
<callout arearefs="class6">
<para>
<literal>catalog</literal> (옵션): 루트 <literal><hibernate-mapping></literal> 요소에 의해 지정된
- 카다록 이름을 오버라이드 시킨다.
+ 카다록 이름을 오버라이드 시킨다.
</para>
</callout>
<callout arearefs="class7">
<para>
<literal>proxy</literal> (옵션): lazy initializing proxy들에 사용할 인터페이스를 지정한다. 당신은 클래스
- 그 자체의 이름을 지정할 수 도 있다.
+ 그 자체의 이름을 지정할 수 도 있다.
</para>
</callout>
<callout arearefs="class8">
<para>
<literal>dynamic-update</literal> (옵션 - 디폴트는 <literal>false</literal>):
<literal>UPDATE</literal> SQL이 실행 시에 생성되고 그들 컬럼들의 값들이 변경된 그들 컬럼들 만을
- 포함할 것인지를 지정한다.
+ 포함할 것인지를 지정한다.
</para>
</callout>
<callout arearefs="class9">
<para>
<literal>dynamic-insert</literal> (옵션 - 디폴트는 <literal>false</literal>):
- 생성될 <literal>INSERT</literal>이 실행 시에 생성되고 그들 컬럼들의 값이 null이 아닌 컬럼들 만을
- 포함할 것인지를 지정한다.
+ 생성될 <literal>INSERT</literal>이 실행 시에 생성되고 그들 컬럼들의 값이 null이 아닌 컬럼들 만을
+ 포함할 것인지를 지정한다.
</para>
</callout>
<callout arearefs="class10">
<para>
<literal>select-before-update</literal> (옵션 - 디폴트는 <literal>false</literal>):
- 객체가 실제로 변경되는 것이 확실하지 않는 한, Hibernate가 SQL <literal>UPDATE</literal>를
+ 객체가 실제로 변경되는 것이 확실하지 않는 한, Hibernate가 SQL <literal>UPDATE</literal>를
<emphasis>결코</emphasis> 실행하지 않을 것임을 지정한다. 어떤 경우들에서(실제로 transient
- 객체가 <literal>update()</literal>를 사용하여 새로운 session에 연관되었을 때에만), 이것은
- 하나의 <literal>UPDATE</literal>가 실제로 필요한 경우인지 여부를 결정하기 위해 Hibernate는
- 특별한 SQL <literal>SELECT</literal>를 실행할 것임을 의미한다.
+ 객체가 <literal>update()</literal>를 사용하여 새로운 session에 연관되었을 때에만), 이것은
+ 하나의 <literal>UPDATE</literal>가 실제로 필요한 경우인지 여부를 결정하기 위해 Hibernate는
+ 특별한 SQL <literal>SELECT</literal>를 실행할 것임을 의미한다.
</para>
</callout>
<callout arearefs="class11">
@@ -387,7 +387,7 @@
<callout arearefs="class14">
<para>
<literal>batch-size</literal> (옵션 - 디폴트는 <literal>1</literal>) 식별자에 의해 이 클래스의
- 인스턴스들을 페치시키는 "배치 사이즈"를 지정한다.
+ 인스턴스들을 페치시키는 "배치 사이즈"를 지정한다.
</para>
</callout>
<callout arearefs="class15">
@@ -406,10 +406,10 @@
<para>
<literal>entity-name</literal>(옵션, 디폴트는 클래스 이름): Hibernate3는 하나의 클래스가
(잠정적으로 다른 테이블들로) 여러번 매핑되는 것을 허용해주고, Java 레벨에서 Map 또는 XML에 의해 표현
- 되는 엔티티 매핑들을 허용한다. 이들 경우들에서, 당신은 그 엔티티에 대한 명시적인 임의의 이름을 제공해야 한다.
+ 되는 엔티티 매핑들을 허용한다. 이들 경우들에서, 당신은 그 엔티티에 대한 명시적인 임의의 이름을 제공해야 한다.
<literal>entity-name</literal> (옵션): Hibernate3는 하나의 클래스가 (잠정적으로 다른 테이블들로)
- 여러 번 매핑되는 것을 허용하며, 자바 레벨에서 Map들 또는 XML에 의해 표현되는 엔티티 매핑들을 허용한다.
- 이들 경우들에서, 당신은 그 엔티티들에 대한 명시적인 임의의 이름을 제공해야 한다. 추가 정보는
+ 여러 번 매핑되는 것을 허용하며, 자바 레벨에서 Map들 또는 XML에 의해 표현되는 엔티티 매핑들을 허용한다.
+ 이들 경우들에서, 당신은 그 엔티티들에 대한 명시적인 임의의 이름을 제공해야 한다. 추가 정보는
<xref linkend="persistent-classes-dynamicmodels"/>과 <xref linkend="xml"/>을 보라.
</para>
</callout>
@@ -423,14 +423,14 @@
<para>
<literal>rowid</literal> (옵션): Hibernate는 지원되는 데이터베이스들, 예를 들어 Oracle 상에서 이른바
ROWID들을 사용할 수 있고, Hibernate는 당신이 이 옵션을 <literal>rowid</literal>로 설정하는 경우에 빠른
- 업데이트를 위한 특별한 <literal>rowid</literal> 컬럼을 사용할 수 있다. ROWID는 구현 상세이고 저장된
- 튜플(tuple)의 물리적이니 위치를 표현한다.
+ 업데이트를 위한 특별한 <literal>rowid</literal> 컬럼을 사용할 수 있다. ROWID는 구현 상세이고 저장된
+ 튜플(tuple)의 물리적이니 위치를 표현한다.
</para>
</callout>
<callout arearefs="class20">
<para>
<literal>subselect</literal> (옵션): 불변의 읽기 전용 엔티티를 데이터베이스 subselect로 매핑시킨다.
- 당신이 기본 테이블 대신에 뷰를 갖고자 원할 경우에 유용하지만, 사용을 자제하라. 추가 정보는 아래를 보라.
+ 당신이 기본 테이블 대신에 뷰를 갖고자 원할 경우에 유용하지만, 사용을 자제하라. 추가 정보는 아래를 보라.
</para>
</callout>
<callout arearefs="class21">
@@ -746,10 +746,10 @@
<term><literal>sequence-identity</literal></term>
<listitem>
<para>
- 실제 값 생성을 위해 데이터베이스 시퀀스를 활용하지만, 생성된 식별자 값을 insert 문장 실행의 부분으로서
- 실제로 반환시키기 위해 이것을 JDBC3 getGeneratedKeys와 결합시킨 특화된 시퀀스 생성 방도. 이 방도는
- JDK 1.4에 대상화된 Oracle 10g 드라이버들 상에서만 지원되는 거승로 알려져 있다. 이들 insert 문장들에
- 대한 주석들은 Oracle 드라이버들 내에 있는 버그 때문에 사용불가능하게 되어 있음을 노트하라.
+ 실제 값 생성을 위해 데이터베이스 시퀀스를 활용하지만, 생성된 식별자 값을 insert 문장 실행의 부분으로서
+ 실제로 반환시키기 위해 이것을 JDBC3 getGeneratedKeys와 결합시킨 특화된 시퀀스 생성 방도. 이 방도는
+ JDK 1.4에 대상화된 Oracle 10g 드라이버들 상에서만 지원되는 거승로 알려져 있다. 이들 insert 문장들에
+ 대한 주석들은 Oracle 드라이버들 내에 있는 버그 때문에 사용불가능하게 되어 있음을 노트하라.
</para>
</listitem>
</varlistentry>
@@ -763,7 +763,7 @@
<para>
<literal>hilo</literal>와 <literal>seqhilo</literal> 생성기들은 식별자 생성에 대한 마음에 드는 접근법인,
hi/lo 알고리즘에 대한 두 개의 대체 구현들은 제공한다. 첫 번째 구현은 다음에 이용 가능한 "hi" 값을 수용하기 위한 "특별한"
- 데이터베이스 테이블을 필요로 한다. 두 번째는 (지원되는) Oracle 스타일의 시퀀스를 사용한다.
+ 데이터베이스 테이블을 필요로 한다. 두 번째는 (지원되는) Oracle 스타일의 시퀀스를 사용한다.
</para>
<programlisting><![CDATA[<id name="id" type="long" column="cat_id">
@@ -782,8 +782,8 @@
</id>]]></programlisting>
<para>
- 불행히도 당신은 Hibernate에 당신 자신의 <literal>Connection</literal>을 제공할 때 <literal>hilo</literal>를
- 사용할 수 없다. Hibernate가 JTA의 도움을 받는 커넥션들을 얻기 위해 어플리케이션 서버 데이터소스를 사용할 때 당신은
+ 불행히도 당신은 Hibernate에 당신 자신의 <literal>Connection</literal>을 제공할 때 <literal>hilo</literal>를
+ 사용할 수 없다. Hibernate가 JTA의 도움을 받는 커넥션들을 얻기 위해 어플리케이션 서버 데이터소스를 사용할 때 당신은
<literal>hibernate.transaction.manager_lookup_class</literal>를 적절하게 구성해야 한다.
</para>
</sect3>
@@ -793,17 +793,17 @@
<para>
UUID 는 다음을 포함한다: IP 주소, JVM의 시작 시간(정확히 1/4 초), 시스템 시간과 (JVM 내에서 유일한) counter 값.
Java 코드로부터 MAC 주소 또는 메모리 주소를 얻는 것은 불가능하여서, 이것은 우리가 JNI를 사용하지 않고서 행할 수 있는
- 최상의 것이다.
+ 최상의 것이다.
</para>
</sect3>
<sect3 id="mapping-declaration-id-sequences">
<title>식별 컬럼들과 시퀀스들</title>
<para>
- 식별 컬럼들을 지원하는 데이터베이스들(DB2, MySQL, Sybase, MS SQL)의 경우, 당신은 <literal>identity</literal> 키
- 생성을 사용할 수 있다. 시퀀스들을 지원하는 데이터베이스들(DB2, Oracle, PostgreSQL, Interbase, McKoi, SAP DB)의
- 경우, 당신은 <literal>sequence</literal> 스타일 키 생성을 사용할 수도 있다. 이들 방도들 모두 새로운 객체를 insert하기
- 위해 두 개의 SQL 질의들을 필요로 한다.
+ 식별 컬럼들을 지원하는 데이터베이스들(DB2, MySQL, Sybase, MS SQL)의 경우, 당신은 <literal>identity</literal> 키
+ 생성을 사용할 수 있다. 시퀀스들을 지원하는 데이터베이스들(DB2, Oracle, PostgreSQL, Interbase, McKoi, SAP DB)의
+ 경우, 당신은 <literal>sequence</literal> 스타일 키 생성을 사용할 수도 있다. 이들 방도들 모두 새로운 객체를 insert하기
+ 위해 두 개의 SQL 질의들을 필요로 한다.
</para>
<programlisting><![CDATA[<id name="id" type="long" column="person_id">
@@ -817,7 +817,7 @@
</id>]]></programlisting>
<para>
- 크로스 플랫폼 개발을 위해서, <literal>native</literal> 방도가 기준 데이터베이스들의 가용성들에 따라 <literal>identity</literal>,
+ 크로스 플랫폼 개발을 위해서, <literal>native</literal> 방도가 기준 데이터베이스들의 가용성들에 따라 <literal>identity</literal>,
<literal>sequence</literal>, <literal>hilo</literal> 방도 중에서 선택될 것이다.
</para>
</sect3>
@@ -826,15 +826,15 @@
<title>할당된 식별자들</title>
<para>
(Hibernate로 하여금 식별자들을 생성시키도록 하는 것과는 반대로) 당신이 어플리케이션으로 하여금 식별자들을 할당하도록 원할 경우,
- 당신은 <literal>assigned</literal> 생성기를 사용할 수 있다. 이 특별한 생성기는 객체의 identifier 프로퍼티에 이미 할당된
- 식별자 값을 사용할 것이다. 이 생성기(generator)는 프라이머리 키가 대용(surrogate ) 키 대신에 natural 키일 때 사용된다.
- 당신이 <literal><generator></literal> 요소를 지정하지 않을 경우에 이것이 디폴트 특징이다
+ 당신은 <literal>assigned</literal> 생성기를 사용할 수 있다. 이 특별한 생성기는 객체의 identifier 프로퍼티에 이미 할당된
+ 식별자 값을 사용할 것이다. 이 생성기(generator)는 프라이머리 키가 대용(surrogate ) 키 대신에 natural 키일 때 사용된다.
+ 당신이 <literal><generator></literal> 요소를 지정하지 않을 경우에 이것이 디폴트 특징이다
</para>
<para>
<literal>assigned</literal> 생성기(generator)를 선택하는 것은 , version 또는 timestamp 프로퍼티가 존재하지 않는 한
- 또는 당신이 <literal>Interceptor.isUnsaved()</literal>를 정의하지 않는 한, 하나의 인스턴스가 transient 또는 detached인지를
- 결정하기 위해 Hibernae로 하여금 데이터베이스에 접촉하도록 강제하는, <literal>unsaved-value="undefined"</literal>를
+ 또는 당신이 <literal>Interceptor.isUnsaved()</literal>를 정의하지 않는 한, 하나의 인스턴스가 transient 또는 detached인지를
+ 결정하기 위해 Hibernae로 하여금 데이터베이스에 접촉하도록 강제하는, <literal>unsaved-value="undefined"</literal>를
Hibernate에게 사용하도록 한다.
</para>
</sect3>
@@ -842,7 +842,7 @@
<sect3 id="mapping-declaration-id-select">
<title>트리거들에 의해 할당된 프라이머리 키들</title>
<para>
- 리거시 스키마에 대해서만(Hibernate는 트리거들을 가진 DDL을 생성시키지 않는다).
+ 리거시 스키마에 대해서만(Hibernate는 트리거들을 가진 DDL을 생성시키지 않는다).
</para>
<programlisting><![CDATA[<id name="id" type="long" column="person_id">
@@ -852,14 +852,174 @@
</id>]]></programlisting>
<para>
- 위의 예제에서, natural 키로서 클래스에 의해 <literal>socialSecurityNumber</literal>로 명명된 유일 값을 가진 프로퍼티가 존재하고,
- 트리거에 의해 그 값이 생성되는 <literal>person_id</literal>로 명명된 대용키가 존재한다.
+ 위의 예제에서, natural 키로서 클래스에 의해 <literal>socialSecurityNumber</literal>로 명명된 유일 값을 가진 프로퍼티가 존재하고,
+ 트리거에 의해 그 값이 생성되는 <literal>person_id</literal>로 명명된 대용키가 존재한다.
</para>
</sect3>
</sect2>
+ <sect2 id="mapping-declaration-id-enhanced">
+ <title>개선된 식별자 생성기들</title>
+
+ <para>
+ 릴리즈 3.2.3로 시작하면, 식별자 생성기의 두 가지 다른 측면들에 대한 재고를 설명하는 2개의 새로운 생성기들이
+ 존재한다. 첫 번째 측면은 데이터베이스 이식가능성이다; 두번째 측면은 (새로운 식별자 값에 대한 모든 요청들을
+ 데이터베이스로 질의하지 않는) 최적화이다. 이들 두 개의 새로운 생성자들은 (3.3.x 릴리즈 시작 시점에서는) 위에
+ 설명된 명명된 생성자들 중 몇몇을 대체할 예정이다. 하지만 그것들은 현재의 릴리즈 내에 포함되어 있으며 FQN에
+ 의해 참조될 수 있다.
+ </para>
+
+ <para>
+ 이들 새로운 생성기들 중 첫 번째 것은 먼저 <literal>sequence</literal> 생성기를 대체물로서 만들어지고
+ 두번째로는 (<literal>native</literal>가 (일반적으로) 어플리케이션에서 모든 이식성에 관한 난해한 이슈들을 불러일으킬 수 있는
+ 크게 다른 의미를 지닌 <literal>identity</literal>과 <literal>sequence</literal> 사이에서 선택하기 때문에)
+ <literal>native</literal> 보다 더 나은 이식성으로 만들어진 <literal>org.hibernate.id.enhanced.SequenceStyleGenerator</literal>
+ 이다. 하지만 <literal>org.hibernate.id.enhanced.SequenceStyleGenerator</literal>는 다른 방법으로 이식성을
+ 성취한다. 그것은 사용중인 dialect의 가용성에 의존하여 그것의 증가 값들을 저장하기 위해 데이터베이스 내의
+ 테이블이나 시퀀스를 사용하여 선택한다. 이것과 <literal>native</literal> 사이의 차이점은 (시퀀스들이
+ Hibernate가 그것의 테이블 기반의 생성기들로 에뮬레이트 하고자 시도하는 바와 정확하게 일치한다는 사실에서)
+ 테이블 기반의 스토리지와 시퀀스 기반의 스토리지가 정확히 같은 의미를 갖는다는 점이다. 이 생성기는 많은
+ 구성 파라미터들을 갖는다:
+ <itemizedlist spacing="compact">
+ <listitem>
+ <para>
+ <literal>sequence_name</literal> (옵션이고, 디폴트는 <literal>hibernate_sequence</literal>):
+ 사용될 시퀀스(또는 테이블)의 이름.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>initial_value</literal> (옵션이고, 디폴트는 <literal>1</literal>): 시퀀스/테이블로부터 검색되는 초기 값.
+ 시퀀스 생성 용어로, 이것은 일반적으로 명명되는 "STARTS WITH" 절과 유사하다.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>increment_size</literal> (옵션이고, 디폴트는 <literal>1</literal>): 시퀀스/테이블에 대한 차후의
+ 호출에 의해 차이가 나게 될 값. 시퀀스 생성 용어로, 이것은 일반적으로 명명되는 "INCREMENT BY"와
+ 유사하다.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>force_table_use</literal> (옵션이고, 디폴트는 <literal>false</literal>): dialect가 시퀀스를
+ 지원할 수 있다고 할수 있는 경우조차도 역행 구조로서 테이블 사용을 강제할 수 있는가?
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>value_column</literal> (옵션이고, 디폴트는 <literal>next_val</literal>): 테이블 구조들에만
+ 적절하다! 값을 보유하는데 사용되는 테이블 상의 컬럼명
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>optimizer</literal> (옵션이고, 디폴트는 <literal>none</literal>):
+ <xref linkend="mapping-declaration-id-enhanced-optimizers"/>를 보라
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ <para>
+ 이들 새로운 생성기들 중 두 번째 것은 먼저 (비록 <literal>table</literal> 생성기가 실제로
+ <literal>org.hibernate.id.MultipleHiLoPerTableGenerator</literal>와 같이 훨씬 더 많이 기능할지라도)
+ <literal>table</literal> 생성기에 대한 대체물로서 그리고 두번째로 플러그 가능한 옵티마이저들의 개념을 활용하는
+ <literal>org.hibernate.id.MultipleHiLoPerTableGenerator</literal>의 재구현으로서 만들어지는
+ <literal>org.hibernate.id.enhanced.TableGenerator</literal>이다. 본질적으로 이 생성기는 여러 개의 유일하게
+ 키가 매겨진 행들을 사용하여 동시에 많은 다른 증가 값들을 보유하는 것이 가능한 테이블을 정의한다.
+ 이 생성기는 많은 구성 파라미터들을 갖는다:
+ <itemizedlist spacing="compact">
+ <listitem>
+ <para>
+ <literal>table_name</literal> (옵션이고, 디폴트는 <literal>hibernate_sequences</literal>):
+ 사용될 테이블 이름.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>value_column_name</literal> (옵션이고, 디폴트는 <literal>next_val</literal>):
+ 시퀀스 값을 보관하는데 사용되는 테이블 상의 컬럼 이름.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>segment_column_name</literal> (옵션이고, 디폴트는 <literal>sequence_name</literal>):
+ "세그먼트 키"를 보관하는데 사용되는 테이블 상의 컬럼 이름. 이것은 어느 증가 값을 사용할 것인지를
+ 유일하게 식별하는 값이다.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>segment_value</literal> (옵션이고, 디폴트는 <literal>default</literal>):
+ 우리가 이 생성자에 대한 증가 값들을 획득하고자 원하는 세그먼트에 대한 "세그먼트 키" 값.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>segment_value_length</literal> (옵션이고, 디폴트는 <literal>255</literal>):
+ 스키마 생성에 사용된다; 이 세그먼트 키 컬럼을 생성시킬 컬럼 사이즈.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>initial_value</literal> (옵션이고, 디폴트는 <literal>1</literal>):
+ 테이블로부터 검색될 초기 값.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>increment_size</literal> (옵션이고, 디폴트는 <literal>1</literal>):
+ 테이블에 대한 차후의 호출에서 차이가 날 값.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>optimizer</literal> (옵션이고, 디폴트는 <literal></literal>):
+ <xref linkend="mapping-declaration-id-enhanced-optimizers"/>를 보라.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </sect2>
+
+ <sect2 id="mapping-declaration-id-enhanced-optimizers">
+ <title>식별자 생성기 최적화</title>
+ <para>
+ 데이터베이스에 값들을 저장하는 식별자 생성기들로 하여금 새로운 식별자 값을 생성시키기 위해
+ 매번의 호출마다 데이터베이스에 접속하도록 하는 것은 비효율적이다. 대신에 당신은 메모리 내에
+ 한 다발의 값들을 그룹지우고 당신이 당신의 메모리 내 값 그룹을 고갈시켰을 때에만 데이터베이스로
+ 접속하고자 개념적으로 원할 것이다. 이것은 플러그 가능한 옵티마이저들의 역할이다. 현시점에서는 오직
+ 두 개의 개선된 생성기들(<xref linkend="mapping-declaration-id-enhanced"/>) 만이 이 개념을 지원한다.
+ <itemizedlist spacing="compact">
+ <listitem>
+ <para>
+ <literal>none</literal> (일반적으로 이것은 옵티마이저가 지정되지 않았을 경우에 디폴트이다).
+ 이것은 임의의 최적화를 수행하지 말고, 각각의 모든 요청 시에 데이터베이스를 접속할 것을
+ 말한다.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>hilo</literal>: 데이터베이스 검색 값들에 hi/lo 알고리즘을 적용시킨다. 이 옵티마이저의
+ 경우 데이터베이스로부터 검색된 값들은 순차적이게 될리라 예상된다. 이 옵티마이저에 대해
+ 데이터베이스로부터 검색된 값들은 "그룹 번호"를 가리킨다; <literal>increment_size</literal>는
+ 그룹 "hi 값"을 정의하기 위해 메모리 내에서 "그룹 번호" 만큼 곱해진다.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>pooled</literal>: <literal>hilo</literal>에 관한 논의했듯이, 이 옵티마이저들은 데이터베이스에
+ 대한 접속 횟수를 최소화 시키려고 시도한다. 하지만 여기서 우리는 메모리 내 그룹핑 알고리즘과 협력된
+ 순차 값을 저장하기 보다는 "다음 그룹"의 시작 값을 데이터베이스 구조 내로 간단하게 저장한다.
+ 여기서 <literal>increment_size</literal>는 데이터베이스로부터 들어오는 값들을 조회한다.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </sect2>
+
<sect2 id="mapping-declaration-compositeid" revision="3">
<title>composite-id</title>
@@ -878,7 +1038,7 @@
<para>
composite 키를 가진 테이블의 경우, 당신은 클래스의 여러 프로퍼티들을 식별자 프로퍼티들로서 매핑할 수 있다.
<literal><composite-id></literal> 요소는 자식 요소들로서 <literal><key-property></literal>
- 프로퍼티 매핑과 <literal><key-many-to-one></literal> 매핑들을 허용한다.
+ 프로퍼티 매핑과 <literal><key-many-to-one></literal> 매핑들을 허용한다.
</para>
<programlisting><![CDATA[<composite-id>
@@ -893,16 +1053,16 @@
</para>
<para>
- 불행히도, composite 식별자들에 대한 이 접근법은 영속 객체가 그것 자신의 식별자라는 점을 의미한다. 객체
- 자신 외의 다른 "핸들"이 존재하지 않는다. 당신은 당신이 composite key로 연관된 영속 상태를 <literal>load()</literal>
- 할 수 있기 이전에 영속 클래스 그 자체의 인스턴스를 초기화 하고 그것의 식별자 프로퍼티들을 군집화 시켜야 한다. 우리는
- 이 접근법을 <emphasis>embedded</emphasis> composite 식별자로 부르고, 중대한 어플리케이션들에 대해 그것을 억제시킨다.
+ 불행히도, composite 식별자들에 대한 이 접근법은 영속 객체가 그것 자신의 식별자라는 점을 의미한다. 객체
+ 자신 외의 다른 "핸들"이 존재하지 않는다. 당신은 당신이 composite key로 연관된 영속 상태를 <literal>load()</literal>
+ 할 수 있기 이전에 영속 클래스 그 자체의 인스턴스를 초기화 하고 그것의 식별자 프로퍼티들을 군집화 시켜야 한다. 우리는
+ 이 접근법을 <emphasis>embedded</emphasis> composite 식별자로 부르고, 중대한 어플리케이션들에 대해 그것을 억제시킨다.
</para>
<para>
- 두 번째 접근법은 우리가 <emphasis>mapped</emphasis> composite 식별자라고 부르는 것인데, 여기서
+ 두 번째 접근법은 우리가 <emphasis>mapped</emphasis> composite 식별자라고 부르는 것인데, 여기서
<literal><composite-id></literal> 요소 내에 명명된 여기서 식별자 프로퍼티들은 영속 클래스와 별도의 식별자 클래스
- 양자 상에 중복된다.
+ 양자 상에 중복된다.
</para>
<programlisting><![CDATA[<composite-id class="MedicareId" mapped="true">
@@ -911,42 +1071,42 @@
</composite-id>]]></programlisting>
<para>
- 이 예제에서, composite 식별자 클래스인 <literal>MedicareId</literal>와 엔티티 크래스 그 자체 양자는
+ 이 예제에서, composite 식별자 클래스인 <literal>MedicareId</literal>와 엔티티 크래스 그 자체 양자는
<literal>medicareNumber</literal>와 <literal>dependent</literal>로 명명된 프로퍼티들을 갖는다. 식별자 클래스는
<literal>equals()</literal>와 <literal>hashCode()</literal>를 오버라이드 시켜고 <literal>Serializable</literal>을
- 구현해야 한다. 이 접근법의 단점은 아주 명백한—코드 중복이다.
+ 구현해야 한다. 이 접근법의 단점은 아주 명백한—코드 중복이다.
</para>
<para>
- 다음 속성들은 매핑된 composite 식별자를 지정하는데 사용된다:
+ 다음 속성들은 매핑된 composite 식별자를 지정하는데 사용된다:
</para>
<itemizedlist spacing="compact">
<listitem>
<para>
<literal>mapped</literal> (옵션, 디폴트는 <literal>false</literal>):
- 하나의 매핑된 composite 식별자가 사용됨을, 그리고 포함된 프로퍼티 매핑들이 엔티티 클래스와
+ 하나의 매핑된 composite 식별자가 사용됨을, 그리고 포함된 프로퍼티 매핑들이 엔티티 클래스와
composite 식별자 클래스 양자를 참조함을 나타낸다.
</para>
</listitem>
<listitem>
<para>
<literal>class</literal> (옵션, 하지만 하나의 매핑된 commposite 식별자에 대해서는 필수적임):
- 하나의 composite 식별자로서 사용되는 클래스.
+ 하나의 composite 식별자로서 사용되는 클래스.
</para>
</listitem>
</itemizedlist>
<para>
- 우리는 <xref linkend="components-compositeid"/>에서 composite 식별자가 하나의 component 클래스로서 구현되는
- 보다 편리한 접근법인 세번째 방도를 설명할 것이다. 아래에 설명되어 있는 속성들은 이 대체적인 접근법에만 적용된다:
+ 우리는 <xref linkend="components-compositeid"/>에서 composite 식별자가 하나의 component 클래스로서 구현되는
+ 보다 편리한 접근법인 세번째 방도를 설명할 것이다. 아래에 설명되어 있는 속성들은 이 대체적인 접근법에만 적용된다:
</para>
<itemizedlist spacing="compact">
<listitem>
<para>
<literal>name</literal> (옵션, 이 접근법의 경우에는 필수임): 하나의 component
- 식별자를 소유하는 컴포넌트 타입의 프로퍼티(9장을 보라).
+ 식별자를 소유하는 컴포넌트 타입의 프로퍼티(9장을 보라).
</para>
</listitem>
<listitem>
@@ -958,13 +1118,13 @@
<listitem>
<para>
<literal>class</literal> (옵션 - 디폴트는 reflection에 의해 결정된 프로퍼티 타입):
- 하나의 composite 식별자로서 사용되는 컴포넌트 클래스(다음 절을 보라).
+ 하나의 composite 식별자로서 사용되는 컴포넌트 클래스(다음 절을 보라).
</para>
</listitem>
</itemizedlist>
<para>
- 이 세번째 접근법, <emphasis>identifier component</emphasis>은 거의 모든 어플리케이션들에 대해 우리가 권장하는 것이다.
+ 이 세번째 접근법, <emphasis>identifier component</emphasis>은 거의 모든 어플리케이션들에 대해 우리가 권장하는 것이다.
</para>
</sect2>
@@ -973,9 +1133,9 @@
<para>
<literal><discriminator></literal> 요소는 table-per-class-hierarchy(테이블 당 클래스 계층구조)
- 매핑 방도를 사용하는 다형성 영속화에 필요하고 테이블의 discriminator(판별자) 컬럼을 선언한다. discriminator 컬럼은
- 특정 행에 대해 초기화 시킬 서브 클래스가 무엇인지를 영속 계층에 알려주는 표시자 값들을 포함한다. 타입들의 제한적인 집합이
- 사용될 수 있다: <literal>string</literal>, <literal>character</literal>, <literal>integer</literal>,
+ 매핑 방도를 사용하는 다형성 영속화에 필요하고 테이블의 discriminator(판별자) 컬럼을 선언한다. discriminator 컬럼은
+ 특정 행에 대해 초기화 시킬 서브 클래스가 무엇인지를 영속 계층에 알려주는 표시자 값들을 포함한다. 타입들의 제한적인 집합이
+ 사용될 수 있다: <literal>string</literal>, <literal>character</literal>, <literal>integer</literal>,
<literal>byte</literal>, <literal>short</literal>, <literal>boolean</literal>,
<literal>yes_no</literal>, <literal>true_false</literal>.
</para>
@@ -1011,21 +1171,21 @@
<callout arearefs="discriminator3">
<para>
<literal>force</literal> (옵션 - 디폴트는 <literal>false</literal>)
- 이것은 Hibernate로 하여금 루트 클래스의 모든 인스턴스들을 검색할 때조차도 허용된 discriminator
- 값들을 지정하도록 "강제한다".
+ 이것은 Hibernate로 하여금 루트 클래스의 모든 인스턴스들을 검색할 때조차도 허용된 discriminator
+ 값들을 지정하도록 "강제한다".
</para>
</callout>
<callout arearefs="discriminator4">
<para>
<literal>insert</literal> (옵션 - 디폴트는 <literal>true</literal>)
- 당신의 discriminator 컬럼이 또한 매핑된 composite 식별자의 부분일 경우에 이것을 <literal>false</literal>로 설정하라.
+ 당신의 discriminator 컬럼이 또한 매핑된 composite 식별자의 부분일 경우에 이것을 <literal>false</literal>로 설정하라.
(Hibernate에게 SQL <literal>INSERT</literal>들 속에 그 컬럼을 포함하지 않도록 통보한다.)
</para>
</callout>
<callout arearefs="discriminator5">
<para>
<literal>formula</literal> (옵션)
- 타입이 평가 되어야 할 때 실행되는 임의의 SQL 표현식. 컨텐츠 기반의 판별을 허용해준다.
+ 타입이 평가 되어야 할 때 실행되는 임의의 SQL 표현식. 컨텐츠 기반의 판별을 허용해준다.
</para>
</callout>
</calloutlist>
@@ -1038,7 +1198,7 @@
<para>
<literal>force</literal> 속성은 테이블이 영속 클래스로 매핑되지 않는 "특별한" discriminator 값들을 가진 행들을
- 포함할 경우에(만) 유용하다. 이것은 대개 그 경우가 아닐 것이다.
+ 포함할 경우에(만) 유용하다. 이것은 대개 그 경우가 아닐 것이다.
</para>
<para>
@@ -1056,7 +1216,7 @@
<para>
<literal><version></literal> 요소는 옵션이고 테이블이 버전화된 데이터를 포함한다는 것을 나타낸다.
- 이것은 당신이 <emphasis>긴 트랜잭션(long transaction)들</emphasis>을 사용할 계획이라면 특히 유용하다
+ 이것은 당신이 <emphasis>긴 트랜잭션(long transaction)들</emphasis>을 사용할 계획이라면 특히 유용하다
(아래를 보라).
</para>
@@ -1084,7 +1244,7 @@
<callout arearefs="version1">
<para>
<literal>column</literal> (옵션 - 디폴트는 프로퍼티 명):
- 버전 번호를 가진 컬럼의 이름.
+ 버전 번호를 가진 컬럼의 이름.
</para>
</callout>
<callout arearefs="version2">
@@ -1095,7 +1255,7 @@
<callout arearefs="version3">
<para>
<literal>type</literal> (옵션 - 디폴트는 <literal>integer</literal>):
- 버전 번호의 타입.
+ 버전 번호의 타입.
</para>
</callout>
<callout arearefs="version4">
@@ -1107,14 +1267,14 @@
<callout arearefs="version5">
<para>
<literal>unsaved-value</literal> (옵션 - 디폴트는 <literal>undefined</literal>):
- 이전 세션에서 저장되었거나 로드되었던 detached 인스턴스로부터 구별지어서, 인스턴스가 새로이 초기화됨(unsaved)을
- 나타내는 version 프로퍼티 값.(<literal>undefined</literal>는 식별자 프로퍼티 값이 사용될 것임을 지정한다.)
+ 이전 세션에서 저장되었거나 로드되었던 detached 인스턴스로부터 구별지어서, 인스턴스가 새로이 초기화됨(unsaved)을
+ 나타내는 version 프로퍼티 값.(<literal>undefined</literal>는 식별자 프로퍼티 값이 사용될 것임을 지정한다.)
</para>
</callout>
<callout arearefs="version6">
<para>
<literal>generated</literal> (옵션 - 디폴트는 <literal>never</literal>):
- 이 version 프로퍼티 값이 데이터베이스에 의해 실제로 산출되는지를 지정한다.
+ 이 version 프로퍼티 값이 데이터베이스에 의해 실제로 산출되는지를 지정한다.
<xref linkend="mapping-generated">산출되는 프로퍼티들</xref>에 관한 논의를 보라.
</para>
</callout>
@@ -1122,23 +1282,23 @@
<para>
<literal>insert</literal> (옵션 - 디폴트는 <literal>true</literal>):
version 컬럼이 SQL insert 문장들 속에 포함될 것인지 여부를 지정한다.
- 데이터베이스 컬럼이 디폴트 값 <literal>0</literal>으로 정의되는 경우에만 <literal>false</literal>로
- 설정될 수 있다.
+ 데이터베이스 컬럼이 디폴트 값 <literal>0</literal>으로 정의되는 경우에만 <literal>false</literal>로
+ 설정될 수 있다.
</para>
</callout>
</calloutlist>
</programlistingco>
<para>
- 버전 번호들은 <literal>long</literal>, <literal>integer</literal>, <literal>short</literal>,
+ 버전 번호들은 <literal>long</literal>, <literal>integer</literal>, <literal>short</literal>,
<literal>timestamp</literal> 또는 <literal>calendar</literal> 타입일 수 있다.
</para>
<para>
version 또는 timestamp 프로퍼티는 detached 인스턴스에 대해 결코 null일 수가 없어서, Hibernate는
- 다른 <literal>unsaved-value</literal> 방도들이 지정되는 것에 상관없이, null version이나 timestamp를
- 가진 임의의 인스턴스를 transient로서 검출할 것이다. <emphasis>null 허용되는 version 이나 property를
- 선언하는 것은 Hibernate에서 transitive reattachment에 대한 임의의 문제들을 피하는 쉬운 방법이고,
+ 다른 <literal>unsaved-value</literal> 방도들이 지정되는 것에 상관없이, null version이나 timestamp를
+ 가진 임의의 인스턴스를 transient로서 검출할 것이다. <emphasis>null 허용되는 version 이나 property를
+ 선언하는 것은 Hibernate에서 transitive reattachment에 대한 임의의 문제들을 피하는 쉬운 방법이고,
assigned 식별자들이나 composite key들을 사용하는 사람들에게 특히 유용하다!</emphasis>
</para>
</sect2>
@@ -1147,9 +1307,9 @@
<title>timestamp (옵션)</title>
<para>
- 옵션 <literal><timestamp></literal> 요소는 테이블이 타임스탬프화 된 데이터를 포함함을 나타낸다. 이것은
- 버전화에 대한 대체물로서 고안되었다. Timestamp은 고유하게 optimistic 잠금에 대한 다소 안전한 구현이다. 하지만 때때로
- 어플리케이션은 다른 방법들로 timestamp들을 사용할 수도 있다.
+ 옵션 <literal><timestamp></literal> 요소는 테이블이 타임스탬프화 된 데이터를 포함함을 나타낸다. 이것은
+ 버전화에 대한 대체물로서 고안되었다. Timestamp은 고유하게 optimistic 잠금에 대한 다소 안전한 구현이다. 하지만 때때로
+ 어플리케이션은 다른 방법들로 timestamp들을 사용할 수도 있다.
</para>
<programlistingco>
@@ -1174,14 +1334,14 @@
<callout arearefs="timestamp1">
<para>
<literal>column</literal> (옵션 - 디폴트는 프로퍼티 명):
- 타임스탬프를 포함하는 컬럼 명.
+ 타임스탬프를 포함하는 컬럼 명.
</para>
</callout>
<callout arearefs="timestamp2">
<para>
<literal>name</literal>:
- 영속 클래스에 대해 자바 <literal>Date</literal> 또는 <literal>Timestamp</literal> 타입을
- 가진 자바빈즈 스타일의 프로퍼티 이름.
+ 영속 클래스에 대해 자바 <literal>Date</literal> 또는 <literal>Timestamp</literal> 타입을
+ 가진 자바빈즈 스타일의 프로퍼티 이름.
</para>
</callout>
<callout arearefs="timestamp3">
@@ -1193,26 +1353,26 @@
<callout arearefs="timestamp4">
<para>
<literal>unsaved-value</literal> (옵션 - 디폴트는 <literal>null</literal>):
- 이전 세션에서 저장되었거나 로드되었던 detached 인스턴스로부터 인스턴스를 구별지우는, 인스턴스가 새로이
- 초기화됨(unsaved)을 나타내는 version 프로퍼티 값.(<literal>undefined</literal>는 식별자
- 프로퍼티 값이 사용될 것임을 지정한다.)
+ 이전 세션에서 저장되었거나 로드되었던 detached 인스턴스로부터 인스턴스를 구별지우는, 인스턴스가 새로이
+ 초기화됨(unsaved)을 나타내는 version 프로퍼티 값.(<literal>undefined</literal>는 식별자
+ 프로퍼티 값이 사용될 것임을 지정한다.)
</para>
</callout>
<callout arearefs="timestamp5">
<para>
<literal>source</literal> (옵션 - 디폴트는 <literal>vm</literal>):
Hibernate는 어디서 timestamp 값을 검색할 것인가? 데이터베이스로부터인가 현재의 JVM으로부터인가?
- 데이터베이스 기반의 timestamp들은 Hibernate가 "다음 값"을 결정하기 위해 데이터베이스에 접속해야
- 하기 때문에 오버헤드를 초래하지만, 클러스터링된 환경들에서의 용도로 보다 더 안전할 것이다. 또한 모든
+ 데이터베이스 기반의 timestamp들은 Hibernate가 "다음 값"을 결정하기 위해 데이터베이스에 접속해야
+ 하기 때문에 오버헤드를 초래하지만, 클러스터링된 환경들에서의 용도로 보다 더 안전할 것이다. 또한 모든
<literal>Dialect</literal>들이 데이터베이스의 현재의 timestamp에 대한 검색을 지원하는 것으로 알려져
- 있지 않지만, 다른 <literal>Dialect</literal>들은 정밀도 결핍 때문에 잠금에 있어 사용이 안전하지 않을
- 수 있음을 노트하라(예를 들면 오라클 8).
+ 있지 않지만, 다른 <literal>Dialect</literal>들은 정밀도 결핍 때문에 잠금에 있어 사용이 안전하지 않을
+ 수 있음을 노트하라(예를 들면 오라클 8).
</para>
</callout>
<callout arearefs="timestamp6">
<para>
<literal>generated</literal> (옵션 - 디폴트는 <literal>never</literal>):
- 이 timestamp 프로퍼티 값이 데이터베이스에 의해 실제로 생성됨을 지정한다.
+ 이 timestamp 프로퍼티 값이 데이터베이스에 의해 실제로 생성됨을 지정한다.
<xref linkend="mapping-generated">산출되는 프로퍼티들</xref>에 대한 논의들 보라.
</para>
</callout>
@@ -1221,7 +1381,7 @@
<para>
<literal><timestamp></literal>는 <literal><version type="timestamp"></literal>과
- 같음을 노트하라. 그리고 <literal><timestamp use-db="true"></literal>는
+ 같음을 노트하라. 그리고 <literal><timestamp use-db="true"></literal>는
<literal><version type="dbtimestamp"></literal>과 같다
</para>
</sect2>
@@ -1280,8 +1440,8 @@
<callout arearefs="property2">
<para>
<literal>column</literal> (옵션 - 디폴트는 프로퍼티 이름):
- 매핑된 데이터베이스 테이블 컬럼의 이름. 이것은 또한 내부에 포함되는 <literal><column></literal> 요소(들)에
- 의해 지정될 수도 있다.
+ 매핑된 데이터베이스 테이블 컬럼의 이름. 이것은 또한 내부에 포함되는 <literal><column></literal> 요소(들)에
+ 의해 지정될 수도 있다.
</para>
</callout>
<callout arearefs="property3">
Modified: core/tags/v326/doc/reference/ko/modules/batch.xml
===================================================================
--- core/tags/v326/doc/reference/ko/modules/batch.xml 2008-06-15 14:36:50 UTC (rev 14767)
+++ core/tags/v326/doc/reference/ko/modules/batch.xml 2008-06-15 14:39:42 UTC (rev 14768)
@@ -26,6 +26,11 @@
<programlisting><![CDATA[hibernate.jdbc.batch_size 20]]></programlisting>
+ <para id="disablebatching" revision="1">
+ 당신이 <literal>identiy</literal> 식별자 생성기를 사용할 경우에 Hibernate가 JDBC 레벨에서 투명하게 insert 배치처리하는 것을 불가능하게 만든다는
+ 사실을 주목하라.
+ </para>
+
<para>
당신은 또한 second-level 캐시를 가진 상호작용이 완전하게 불가능한 프로세스 내에서 이런 종류의 작업을 행하고 싶어할 수도 있다:
</para>
Modified: core/tags/v326/doc/reference/ko/modules/filters.xml
===================================================================
--- core/tags/v326/doc/reference/ko/modules/filters.xml 2008-06-15 14:36:50 UTC (rev 14767)
+++ core/tags/v326/doc/reference/ko/modules/filters.xml 2008-06-15 14:39:42 UTC (rev 14768)
@@ -6,7 +6,7 @@
필터</emphasis>는 특정 Hibernate 세션에 대해 이용 가능하게 되거나 이용 불가능하게 될 수도 있는 전역, 명명된 파라미터화 된 필터이다.
</para>
- <sect1 id="objectstate-filters">
+ <sect1 id="objectstate-filters" revision="1">
<title>Hibernate 필터들</title>
<para>
@@ -95,8 +95,8 @@
</class>]]></programlisting>
<para>
- 그때 당신이 현재 유효한 레코드들을 항상 얻는 것을 확실히 하기 위해, employee 데이터를 검색하기 전에 세션 상에 필터를
- 간단하게 이용 가능하게 하라:
+ 그때 당신이 현재 유효한 레코드들을 항상 얻는 것을 확실히 하기 위해, employee 데이터를 검색하기 전에 세션 상에 필터를
+ 간단하게 이용 가능하게 하라:
</para>
<programlisting><![CDATA[Session session = ...;
@@ -107,16 +107,31 @@
]]></programlisting>
<para>
- 위의 HQL 에서, 심지어 비록 우리가 결과들에 대한 봉급 컨스트레인트를 명시적으로 언급만 했을지라도, 이용 가능한 필터 때문에
- 그 질의는 봉급이 백만달러 이상인 현재 채용중인 직원들만을 반환할 것이다.
+ 위의 HQL 에서, 심지어 비록 우리가 결과들에 대한 봉급 컨스트레인트를 명시적으로 언급만 했을지라도, 이용 가능한 필터 때문에
+ 그 질의는 봉급이 백만달러 이상인 현재 채용중인 직원들만을 반환할 것이다.
</para>
<para>
- 노트: 만일 당신이 outer 조인에 대해 필터들을 사용할 계획이라면 (HQL이든 로드 페칭이든) 조건 표현식의 방향을 주의하라.
- 이것을 left outer join으로 설정하는 것이 가장 안전하다; 일반적으로 오퍼레이터 뒤에 있는 컬럼 이름(들)이 뒤따르는 첫번째에
- 파라미터를 위치지워라.
+ 노트: 만일 당신이 outer 조인에 대해 필터들을 사용할 계획이라면 (HQL이든 로드 페칭이든) 조건 표현식의 방향을 주의하라.
+ 이것을 left outer join으로 설정하는 것이 가장 안전하다; 일반적으로 오퍼레이터 뒤에 있는 컬럼 이름(들)이 뒤따르는 첫번째에
+ 파라미터를 위치지워라.
</para>
+ <para>
+ 정의된 후에 필터는 그것 자신의 조건을 가지고 여러 엔티티들 그리고/또는 콜렉션들 각각에 첨부될 수도 있다.
+ 조건들이 매번 같을 때 그것은 지루할수도 있다. 따라서 <literal><filter-def/></literal>는 속성으로든
+ CDATA로든 디폴트 조건을 정의하는 것을 허용해준다:
+ </para>
+
+ <programlisting><![CDATA[<filter-def name="myFilter" condition="abc > xyz">...</filter-def>
+<filter-def name="myOtherFilter">abc=xyz</filter-def>]]></programlisting>
+
+ <para>
+ 그때 이 디폴트 조건은 필터가 조건을 지정하지 않은 어떤 것에 첨부될 때마다 사용될 것이다.
+ 이것은 당신이 그 특정한 경우에서 디폴트 조건을 오버라이드 시키는 필터의 첨부 부분으로서
+ 특정한 조건을 부여할 수 있음을 의미함을 주목하라.
+ </para>
+
</sect1>
</chapter>
Modified: core/tags/v326/doc/reference/ko/modules/persistent_classes.xml
===================================================================
--- core/tags/v326/doc/reference/ko/modules/persistent_classes.xml 2008-06-15 14:36:50 UTC (rev 14767)
+++ core/tags/v326/doc/reference/ko/modules/persistent_classes.xml 2008-06-15 14:39:42 UTC (rev 14768)
@@ -178,7 +178,7 @@
<para>
당신은 또한 non-final 클래스들 상에 <literal>public final</literal> 메소드들을 선언하는 것을 피해야 한다.
만일 당신이 <literal>public final</literal> 메소드를 가진 클래스를 사용하고자 원할 경우, 당신은
- <literal>lazy="false"</literal>를 설정함으로써 명시적으로 프락싱을 사용 불가능하도록 해야 한다.
+ <literal>lazy="false"</literal>를 설정함으로써 프락싱을 명시적으로 사용 불가능하도록 해야 한다.
</para>
</sect2>
Modified: core/tags/v326/doc/reference/ko/modules/query_hql.xml
===================================================================
--- core/tags/v326/doc/reference/ko/modules/query_hql.xml 2008-06-15 14:36:50 UTC (rev 14767)
+++ core/tags/v326/doc/reference/ko/modules/query_hql.xml 2008-06-15 14:39:42 UTC (rev 14768)
@@ -1,4 +1,4 @@
-<chapter id="queryhql">
+<chapter id="queryhql" revision="1">
<title>HQL: 하이버네이트 질의 언어(Hibernate Query Language)</title>
<para>
@@ -191,6 +191,41 @@
<programlisting><![CDATA[from Cat as cat where cat.mate.name like '%s%']]></programlisting>
</sect1>
+ <sect1 id="queryhql-identifier-property">
+ <title>식별자 프로퍼티 참조하기</title>
+
+ <para>
+ 일반적으로 말하자면, 엔티티의 식별자 프로퍼티를 참조하는 2가지 방법들이 있다:
+ </para>
+ <itemizedlist spacing="compact">
+ <listitem>
+ <para>
+ 엔티티가 <emphasis>id로 명명된 비-식별자 프로퍼티를 정의하고있지 않다고 가정하면</emphasis>
+ 특별한 프로퍼티 (소문자) <literal>id</literal>가 엔티티의 식별자 프로퍼티를 참조하는데 사용될 수도 있다.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ 만일 엔티티가 명명된 식별자 프로퍼티를 정의할 경우, 당신은 그 프로퍼티 이름을 사용할수 있다.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ 합성 식별자 프로퍼티들에 대한 참조들은 다음 명명 규칙들을 따른다. 만일 엔티티가 id로 명명된
+ 비-식별자 프로퍼티를 갖고 있다면, 합성 식별자 프로퍼티는 그것의 정의된 명명된 프로퍼티에 의해서만
+ 참조될 수 있다; 그 밖의 경우 특별한 <literal>id</literal> 프로퍼티는 식별자 프로퍼티를 참조하는데
+ 사용될 수 있다.
+ </para>
+
+ <para>
+ 노트: 이것은 버전 3.2.2 시작 시점에서 현저하게 변경되었다. 이전 버전들에서
+ <literal>id</literal>는 그것의 실제 이름이 무엇이든 간에 상관없이 <emphasis>항상</emphasis>
+ 식별자 프로퍼티를 참조했다. 그 결정에 대한 분기점은 <literal>id</literal>로 명명된
+ 비-식별자 프로퍼티들이 Hibernate 질의들 내에서 결코 참조될 수 없다는 점이었다.
+ </para>
+ </sect1>
+
<sect1 id="queryhql-select">
<title>select 절</title>
@@ -366,7 +401,7 @@
</sect1>
- <sect1 id="queryhql-where">
+ <sect1 id="queryhql-where" revision="1">
<title>where 절</title>
<para>
@@ -420,8 +455,8 @@
where cat.mate = mate]]></programlisting>
<para>
- 특별한 프로퍼티(소문자) <literal>id</literal>는 객체의 유일 식별자를 참조하는데 사용될 수 있다.(당신은 또한 그것의 프로퍼티
- 이름을 사용할 수도 있다.)
+ 특별한 프로퍼티(소문자) <literal>id</literal>는 객체의 유일 식별자를 참조하는데 사용될 수 있다.
+ 추가정보는 <xref linkend="queryhql-identifier-property"/>를 보라.
</para>
<programlisting><![CDATA[from Cat as cat where cat.id = 123
@@ -435,7 +470,8 @@
<para>
composite identifier(합성 식별자)들의 프로퍼티들이 또한 사용될 수 있다. <literal>Person</literal>이
<literal>country</literal>와 <literal>medicareNumber</literal>로 구성된 composite identifier를 갖는다고
- 가정하자.
+ 가정하자. 다시, 식별자 프로퍼티들을 참조하는 것에 관한 추가 정보는
+ <xref linkend="queryhql-identifier-property"/>를 보라.
</para>
<programlisting><![CDATA[from bank.Person person
@@ -457,16 +493,12 @@
</para>
<programlisting><![CDATA[from Cat cat where cat.class = DomesticCat]]></programlisting>
-
+
<para>
- 당신은 또한 컴포넌트들 또는 composite 사용자 정의 타입들의 (그리고 컴포넌트들의 컴포넌트들, 기타의) 프로퍼티들을
- 지정할 수도 있다. (컴포넌트의 프로퍼티와은 반대로) 컴포넌트 타입의 프로퍼티로 끝나는 경로-표현식을 사용하려고 결코 시도하지 말라.
- 예를 들어, 만일 <literal>store.owner</literal>가 컴포넌트 <literal>address</literal>를 가진 엔티티일 경우
+ 당신은 또한 컴포넌트들 또는 합성 사용자 타입들, 또는 컴포넌트 타입들이라 일컬어지는 프로퍼티들을 사용할수도 있다.
+ 보다 상세한 것은 <xref linkend="queryhql-components"/>를 보라.
</para>
- <programlisting><![CDATA[store.owner.address.city // okay
-store.owner.address // error!]]></programlisting>
-
<para>
"임의의" 타입은 다음 방법으로 join을 표현하는 것을 우리에게 허용해주는, 특별한 프로퍼티들 <literal>id</literal>와
<literal>class</literal>를 갖는다(여기서 <literal>AuditLog.item</literal>은 <literal><any></literal>로
@@ -778,7 +810,7 @@
</para>
</sect1>
- <sect1 id="queryhql-grouping">
+ <sect1 id="queryhql-grouping" revision="1">
<title>group by 절</title>
<para>
@@ -810,23 +842,25 @@
<programlisting><![CDATA[select cat
from Cat cat
join cat.kittens kitten
-group by cat
+group by cat.id, cat.name, cat.other, cat.properties
having avg(kitten.weight) > 100
order by count(kitten) asc, sum(kitten.weight) desc]]></programlisting>
<para>
<literal>group by</literal> 절도 <literal>order by</literal> 절 어느 것도 산술 표현식들을 포함할 수 없다는 점을
- 노트하라.
+ 노트하라. 또한 Hibernate는 현재 그룹지워진 엔티티를 전개하지 않아서 만일 <literal>cat</literal>의 모든
+ 프로퍼티들이 집계되지 않을 경우에 당신은 <literal>group by cat</literal>을 작성할 수 없다는 점을 주목하라.
+ 당신은 모든 집계되지 않는 프로퍼티들을 명시적으로 리스트해야 한다.
</para>
</sect1>
- <sect1 id="queryhql-subqueries" revision="2">
+ <sect1 id="queryhql-subqueries" revision="3">
<title>서브질의들</title>
<para>
subselect들을 지원하는 데이터베이스들의 경우, Hibernate는 질의들 내에 서브질의들을 지원한다. 서브질의는 괄호로 묶여져야
- 한다(자주 SQL 집계함수 호출에 의해). 심지어 서로 상관된 서브질의들(외부 질의 내에서 alias를 참조하는 서브질의들)이 허용된다.
+ 한다(자주 SQL 집계함수 호출에 의해). 심지어 서로 상관된 서브질의들(외부 질의 내에서 alias를 참조하는 서브질의들)이 허용된다.
</para>
<programlisting><![CDATA[from Cat as fatcat
@@ -853,40 +887,14 @@
from Cat as cat]]></programlisting>
<para>
- select 리스트 내에 있는 하나 이상의 표현식을 가진 서브질의들의 경우에 당신은 tuple 생성자를 사용할 수 있다:
- </para>
-
- <para>
- select 목록 내에 하나 이상의 표현식을 가진 서브질의들의 경우, 당신은 튜플(tuple) 구조를 사용할 수 있다:
- </para>
-
- <programlisting><![CDATA[from Cat as cat
-where not ( cat.name, cat.color ) in (
- select cat.name, cat.color from DomesticCat cat
-)]]></programlisting>
-
- <para>
HQL 서브질의들이 select 절 또는 where 절 내에서만 일어날 수 있음을 노트하라.
</para>
-
- <para>
- (Oracle 또는 HSQL이 아닌) 몇몇 데이터베이스들 상에서, 당신은 다른 컨텍스트들 내에서, 예를 들면 component들이나 composite
- 사용자 타입들을 질의할 때 tuple 생성자들을 사용할 수 있음을 노트하라:
- </para>
-
- <programlisting><![CDATA[from Person where name = ('Gavin', 'A', 'King')]]></programlisting>
<para>
- 이것을 더 풀어쓰면 다음과 동일하다:
+ 서브질의들이 또한 <literal>row value constructor</literal> 구문을 활용할 수 있음을 주목하라.
+ 보다 상세한 것은 <xref linkend="queryhql-tuple"/>을 보라.
</para>
- <programlisting><![CDATA[from Person where name.first = 'Gavin' and name.initial = 'A' and name.last = 'King')]]></programlisting>
-
- <para>
- 당신이 이런 종류의 것을 행하는 것을 원하지 않을 수 있는 두 가지 좋은 이유들이 존재한다: 첫 번째로 데이터베이스 플랫폼들 사이에 완전하게
- 이식성이 없다; 두 번째로 그 질의는 이제 매핑 문서 속에 있는 프로퍼티들의 순서에 의존한다.
- </para>
-
</sect1>
<sect1 id="queryhql-examples">
@@ -1097,5 +1105,77 @@
</sect1>
+ <sect1 id="queryhql-components">
+ <title>컴포넌트</title>
+
+ <para>
+ 컴포넌트들은 단지 간단한 값 타입들이 HQL 질의들 내에 사용될 수 있는 모든 방식으로 사용될 수도 있다.
+ 그것들은 <literal>select</literal> 절 내에 나타날 수 있다:
+ </para>
+
+ <programlisting><![CDATA[select p.name from from Person p]]></programlisting>
+ <programlisting><![CDATA[select p.name.first from from Person p]]></programlisting>
+
+ <para>
+ 여기서 Person의 name 프로퍼티는 하나의 컴포넌트이다. 컴포넌트들은 또한 <literal>where</literal> 절
+ 내에 사용될 수 있다:
+ </para>
+
+ <programlisting><![CDATA[from from Person p where p.name = :name]]></programlisting>
+ <programlisting><![CDATA[from from Person p where p.name.first = :firstName]]></programlisting>
+
+ <para>
+ 컴포넌트들은 또한 <literal>order by</literal> 절 내에 사용될 수 있다:
+ </para>
+
+ <programlisting><![CDATA[from from Person p order by p.name]]></programlisting>
+ <programlisting><![CDATA[from from Person p order by p.name.first]]></programlisting>
+
+ <para>
+ 컴포넌트들에 대한 또 다른 공통된 사용은 <xref linkend="queryhql-tuple">행 값 생성자들</xref> 내에서이다.
+ </para>
+ </sect1>
+
+ <sect1 id="queryhql-tuple">
+ <title>행 값 생성자 구문</title>
+
+ <para>
+ 비록 기반 데이터베이스가 행 값 생성자 개념을 지원하지 않을 수도 있을지라도, HQL은
+ (때때로 <literal>tuple</literal> 구문이라 불리는) ANSI SQL <literal>행 값 생성자</literal> 구문 사용을
+ 지원한다. 여기서 우리는 일반적으로 전형저그올 컴포넌트들과 연관된, 다중 값 비교를 언급하고 있다:
+ </para>
+
+ <programlisting><![CDATA[from Person p where p.name.first='John' and p.name.last='Jingleheimer-Schmidt']]></programlisting>
+
+ <para>
+ 비록 약간 장황할지라도, 그것은 유효한 구문이다. 이것을 약간 더 간결하게 만들고
+ <literal>행 값 생성자</literal> 구문을 사용하는 것이 좋다:
+ </para>
+
+ <programlisting><![CDATA[from Person p where p.name=('John', 'Jingleheimer-Schmidt')]]></programlisting>
+
+ <para>
+ 또한 이것을 <literal>select</literal> 절 내에 지정하는 것이 유용할 수 있다:
+ </para>
+
+ <programlisting><![CDATA[select p.name from from Person p]]></programlisting>
+
+ <para>
+ <literal>행 값 생성자</literal> 구문 사용이 유익할 수 있는 또 다른 시점은 다중 값들에 대해
+ 비교될 필요가 있는 서브질의들을 사용할 때이다:
+ </para>
+
+ <programlisting><![CDATA[from Cat as cat
+where not ( cat.name, cat.color ) in (
+ select cat.name, cat.color from DomesticCat cat
+)]]></programlisting>
+
+ <para>
+ 만일 당신이 이 구문을 사용하고자 원할 경우인지를 결정할 때 고려할 한 가지는 그 질의가
+ 메타데이터 내에 있는 컴포넌트 서브-프로퍼티들의 순서에 의존하게 될 것이라는 점이다.
+ </para>
+
+ </sect1>
+
</chapter>
Modified: core/tags/v326/doc/reference/ko/modules/query_sql.xml
===================================================================
--- core/tags/v326/doc/reference/ko/modules/query_sql.xml 2008-06-15 14:36:50 UTC (rev 14767)
+++ core/tags/v326/doc/reference/ko/modules/query_sql.xml 2008-06-15 14:39:42 UTC (rev 14768)
@@ -143,10 +143,12 @@
.addJoin("cat.dogs");
]]></programlisting>
- <p>이 단계에서 우리는 Hibernate에서 native 질의들을 사용가능하도록 만들기 위해
- sql 질의들을 강화시키지는 것을 시작하지 않고서도 native 질의들로서 가능한 것의 한계에
+ <para>
+ 이 단계에서 우리는 Hibernate에서 native 질의들을 사용가능하도록 만들기 위해
+ sql 질의들을 강화시키지는 것을 시작하지 않고서도 native 질의들로서 가능한 것의 한계에
도달하고 있다; 문제점들은 동일한 타입의 여러 엔티티들을 반환할 때 또는 디폴트 alias/column
- 이름들이 충분하지 않을 때 발생하기 시작한다.</p>
+ 이름들이 충분하지 않을 때 발생하기 시작한다.
+ </para>
</sect2>
<sect2>
Modified: core/tags/v326/doc/reference/ko/modules/tutorial.xml
===================================================================
--- core/tags/v326/doc/reference/ko/modules/tutorial.xml 2008-06-15 14:36:50 UTC (rev 14767)
+++ core/tags/v326/doc/reference/ko/modules/tutorial.xml 2008-06-15 14:39:42 UTC (rev 14768)
@@ -562,7 +562,7 @@
</sect2>
- <sect2 id="tutorial-firstapp-workingpersistence" revision="4">
+ <sect2 id="tutorial-firstapp-workingpersistence" revision="5">
<title>객체 로딩과 객체 저장</title>
<para>
@@ -625,26 +625,45 @@
<literal>sessionFactory.getCurrentSession()</literal>은 무엇을 행하는가? 먼저
당신은 당신이 (<literal>HibernateUtil</literal> 덕분에 쉽게) <literal>SessionFactory</literal>을
당신이 소유하고 있다면, 원하는 만큼 어디서든 여러번 그것을 호출할 수 있다.
- <literal>getCurrentSession()</literal> 메소드는 항상 "현재의" 작업 단위를 반환한다. 우리가
- <literal>hibernate.cfg.xml</literal> 내에서 이 매커니즘에 대한 구성 옵션을 "thread"로 전환시켰음을 기억하는가?
- 그러므로 현재 작업 단위의 영역은 우리의 어플리케이션을 실행시키는 현재의 Java 쓰레드이다. 하지만 이것은
- 전부가 진실은 아니다. 그것이 처음으로 필요로 되고, <literal>getCurrentSession()</literal>을 첫번째로
- 호출할 때 <literal>Session</literal>이 시작된다. 그때 현째의 쓰레드에 대해 Hibernate에 의해 바인드 된다.
- 트랜잭션이 종료될 때 커밋 되거나 롤백되고, Hibernate는 또한 쓰레드로부터 <literal>Session</literal>을
- 바인드 해제시키고 당신을 위해 그것을 닫는다. 만일 당신이 <literal>getCurrentSession()</literal>을 다시
- 호출한다면, 당신은 새로운 <literal>Session</literal>을 얻고 새로운 작업단위를 시작할 수 있다. 이
- <emphasis>thread-bound</emphasis> 프로그래밍 모형은 Hibernate를 사용하는 가장 대중적인 방법이다.
+ <literal>getCurrentSession()</literal> 메소드는 항상 "현재의" 작업 단위를 반환한다.
+ <literal>hibernate.cfg.xml</literal>에서 우리가 이 메커니즘에 대한 구성 옵션을 "thread"로 전환시켰음을 기억하는가?
+ 그러므로 현재 작업 단위는 우리의 어플리케이션을 실행시키는 현재의 Java 쓰레드에 묶여 있다. 하지만
+ 이것은 전체 그림이 아니며, 작업 단위가 시작되고 그것이 끝낸 때 당신은 또한 영역(scope)을 고려해야 한다.
</para>
<para>
- 트랜잭션 핸들링과 경계구분에 대한 추가 정보는 <xref linkend="transactions"/>을 살펴보라.
- 우리는 또한 앞의 예제에서 임의의 오류 처리와 롤백을 생략했다.
+ 처름으로 필요할 때, <literal>getCurrentSession()</literal>에 대한 첫번째 호출이 이루어질 때,
+ <literal>Session</literal>이 시작된다. 그때 그것은 Hibernate에 의해 현재 쓰레드에 바인드 된다.
+ 트랜잭션이 끝날 때, 비록 커밋되든 또는 롤백되든 어느 경우든 Hibenate는 당신을 위해 쓰레드로부터
+ <literal>Session</literal>을 자동적으로 언바인드시키고 그것을 닫는다. 만일 당신이 다시
+ <literal>getCurrentSession()</literal>를 호출할 경우, 당신은 새로운 <literal>Session</literal>을 얻고
+ 새로운 작업 단위를 시작할 수 있다. 이 <emphasis>thread-bound</emphasis> 프로그래밍 모형은
+ Hibernate를 사용하는 가장 대중적인 방법이다. 왜냐하면 그것은 당신의 코드를 유연하게 배치하는 것을
+ 허용해주기 때문이다(트랜잭션 경계구분 코드는 데이터베이스 접근 코드와 분리될 수 있으며,
+ 우리는 이 튜토리얼의 뒷 부분에서 이것을 다룰 것이다).
</para>
<para>
- 이 첫 번째 루틴을 실행하기 위해서 우리는 호출 가능한 대상을 Ant 빌드 파일에 추가해야 한다:
+ 작업 영역의 단위와 관련하여, Hibernate <literal>Session</literal>은 한 개 내지 여러 개의
+ 데이터베이스 오퍼레이션들을 실행시키는데 사용될 수 있는가? 위의 예제는 한 개의 오퍼레이션에
+ 대해 한 개의 <literal>Session</literal>을 사용하고 있다. 이것은 단순한 일치이며, 예제는
+ 어떤 다른 오퍼레이션을 보여주기에는 충분히 복잡하지 않다. Hibernate <literal>Session</literal>의
+ 영역은 유연하지만 당신은 <emphasis>모든</emphasis> 데이터페이스 오퍼레이션에 대해
+ 새로운 Hibernate <literal>Session</literal>을 사용하도록 당신의 어플리케이션을 설계해서는
+ 결코 아니될 것이다. 따라서 만일 당신이 다음 (매우 사소한) 예제들에서 여러번 그것을 보게될지라도,
+ <emphasis>session-per-operation</emphasis> 안티-패턴(anti-pattern)을 고려하라.
+ 실제 (웹) 어플리케이션은 이 튜토리얼의 뒷 부분에 예시되어 있다.
</para>
+ <para>
+ 트랜잭션 핸들링과 경계구분에 대한 추가 정보는 <xref linkend="transactions"/>을 살펴보라.
+ 우리는 또한 앞의 예제에서 임의의 오류 처리와 롤백을 생략했다.
+ </para>
+
+ <para>
+ 이 첫 번째 루틴을 실행하기 위해서 우리는 호출 가능한 대상을 Ant 빌드 파일에 추가해야 한다:
+ </para>
+
<programlisting><![CDATA[<target name="run" depends="compile">
<java fork="true" classname="events.EventManager" classpathref="libraries">
<classpath path="${targetdir}"/>
@@ -1201,7 +1220,7 @@
그것은 새로운 이벤트들을 입력하기 위한 HTML form을 제공한다.
</para>
- <sect2 id="tutorial-webapp-servlet" revision="1">
+ <sect2 id="tutorial-webapp-servlet" revision="2">
<title>기본 서블릿 작성하기</title>
<para>
@@ -1249,24 +1268,30 @@
}]]></programlisting>
<para>
- 우리가 여기서 적용하는 패턴은 <emphasis>session-per-request</emphasis>이다. 하나의 요청이
- 서블릿에 도달할 때, 하나의 새로운 Hibernate <literal>Session</literal>이
+ 우리가 여기서 적용하는 패턴은 <emphasis>session-per-request</emphasis>이다. 하나의 요청이
+ 서블릿에 도달할 때, 하나의 새로운 Hibernate <literal>Session</literal>이
<literal>SessionFactory</literal> 상의 <literal>getCurrentSession()</literal>에 대한
- 첫번째 호출을 통해 열린다. 그때 하나의 데이터베이스 트랜잭션이 시작되고, 모든 데이터 접근이 하나의 트랜잭션
- 내에서 발생하는 한, 데이터가 읽혀지거나 기록되는데 문제가 없다(우리는 어플리케이션들 내에서 auto-commit 모드를
- 사용하지 않는다).
+ 첫번째 호출을 통해 열린다. 그때 하나의 데이터베이스 트랜잭션이 시작되고, 모든 데이터 접근이 하나의 트랜잭션
+ 내에서 발생하는 한, 데이터가 읽혀지거나 기록되는데 문제가 없다(우리는 어플리케이션들 내에서 auto-commit 모드를
+ 사용하지 않는다).
</para>
<para>
- 다음으로, 요청의 가능한 액션들이 처리되고 응답 HTML이 렌더링된다. 우리는 곧장 그부분으로 갈 것이다.
+ 모든 데이터베이스 오퍼레이션에 대해 새로운 Hibernate <literal>Session</literal>을 사용하지 <emphasis>말라</emphasis>.
+ 전체 요청에 대해 영역지워진 한 개의 Hibernate <literal>Session</literal>을 사용하라. <literal>getCurrentSession()</literal>을
+ 사용하라. 그것은 현재의 자바 쓰레드에 자동적으로 바인드된다.
</para>
<para>
- 마지막으로, 프로세싱과 렌더링이 완료될 때 작업 단위가 종료된다. 만일 어떤 문제가 프로세싱과 렌더링 동안에 발생될 경우,
- 하나의 예외상황이 던져질 것이고 데이터베이스 트랜잭션은 롤백될 것이다. 이것은 <literal>session-per-request</literal>을
- 완료시킨다. 모든 서블릿 내에 있는 트랜잭션 구획 코드 대신에 당신은 또한 서블릿 필터를 사용할 수 있다.
+ 다음으로, 요청의 가능한 액션들이 처리되고 응답 HTML이 렌더링된다. 우리는 곧장 그부분으로 갈 것이다.
+ </para>
+
+ <para>
+ 마지막으로, 프로세싱과 렌더링이 완료될 때 작업 단위가 종료된다. 만일 어떤 문제가 프로세싱과 렌더링 동안에 발생될 경우,
+ 하나의 예외상황이 던져질 것이고 데이터베이스 트랜잭션은 롤백될 것이다. 이것은 <literal>session-per-request</literal>을
+ 완료시킨다. 모든 서블릿 내에 있는 트랜잭션 구획 코드 대신에 당신은 또한 서블릿 필터를 사용할 수 있다.
<emphasis>Open Session in View</emphasis>로 명명되는 이 패턴에 대한 추가 정보는 Hibernate 웹 사이트와 위키를 보라.
- 당신은 서블릿 내에서가 아닌 JSP 내에 당신의 뷰를 렌더링하는 것을 고려할 때 그것을 필요로 할 것이다.
+ 당신은 서블릿 내에서가 아닌 JSP 내에 당신의 뷰를 렌더링하는 것을 고려할 때 그것을 필요로 할 것이다.
</para>
</sect2>
@@ -1275,7 +1300,7 @@
<title>프로세싱과 렌더링</title>
<para>
- 요청의 처리와 페이지의 렌더링을 구현하자.
+ 요청의 처리와 페이지의 렌더링을 구현하자.
</para>
<programlisting><![CDATA[// Write HTML header
More information about the hibernate-commits
mailing list