[hibernate-commits] Hibernate SVN: r14768 - core/tags/v326/doc/reference/ko/modules.

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>&lt;hibernate-mapping&gt;</literal> 요소에 의해 지정된 - 스키마 이름을 오버라이드 시킨다. + 스키마 이름을 오버라이드 시킨다. </para> </callout> <callout arearefs="class6"> <para> <literal>catalog</literal> (옵션): 루트 <literal>&lt;hibernate-mapping&gt;</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>&lt;generator&gt;</literal> 요소를 지정하지 않을 경우에 이것이 디폴트 특징이다 + 당신은 <literal>assigned</literal> 생성기를 사용할 수 있다. 이 특별한 생성기는 객체의 identifier 프로퍼티에 이미 할당된 + 식별자 값을 사용할 것이다. 이 생성기(generator)는 프라이머리 키가 대용(surrogate ) 키 대신에 natural 키일 때 사용된다. + 당신이 <literal>&lt;generator&gt;</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>&lt;composite-id&gt;</literal> 요소는 자식 요소들로서 <literal>&lt;key-property&gt;</literal> - 프로퍼티 매핑과 <literal>&lt;key-many-to-one&gt;</literal> 매핑들을 허용한다. + 프로퍼티 매핑과 <literal>&lt;key-many-to-one&gt;</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>&lt;composite-id&gt;</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>을 - 구현해야 한다. 이 접근법의 단점은 아주 명백한&mdash;코드 중복이다. + 구현해야 한다. 이 접근법의 단점은 아주 명백한&mdash;코드 중복이다. </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>&lt;discriminator&gt;</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>&lt;version&gt;</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>&lt;timestamp&gt;</literal> 요소는 테이블이 타임스탬프화 된 데이터를 포함함을 나타낸다. 이것은 - 버전화에 대한 대체물로서 고안되었다. Timestamp은 고유하게 optimistic 잠금에 대한 다소 안전한 구현이다. 하지만 때때로 - 어플리케이션은 다른 방법들로 timestamp들을 사용할 수도 있다. + 옵션 <literal>&lt;timestamp&gt;</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>&lt;timestamp&gt;</literal>는 <literal>&lt;version type="timestamp"&gt;</literal>과 - 같음을 노트하라. 그리고 <literal>&lt;timestamp use-db="true"&gt;</literal>는 + 같음을 노트하라. 그리고 <literal>&lt;timestamp use-db="true"&gt;</literal>는 <literal>&lt;version type="dbtimestamp"&gt;</literal>과 같다 </para> </sect2> @@ -1280,8 +1440,8 @@ <callout arearefs="property2"> <para> <literal>column</literal> (옵션 - 디폴트는 프로퍼티 이름): - 매핑된 데이터베이스 테이블 컬럼의 이름. 이것은 또한 내부에 포함되는 <literal>&lt;column&gt;</literal> 요소(들)에 - 의해 지정될 수도 있다. + 매핑된 데이터베이스 테이블 컬럼의 이름. 이것은 또한 내부에 포함되는 <literal>&lt;column&gt;</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>&lt;filter-def/&gt;</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>&lt;any&gt;</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