[hibernate-commits] Hibernate SVN: r14079 - in core/trunk/documentation/manual/ko-KR/src/main: docbook and 2 other directories.

Author: steve.ebersole(a)jboss.com Date: 2007-10-09 15:14:22 -0400 (Tue, 09 Oct 2007) New Revision: 14079 Added: core/trunk/documentation/manual/ko-KR/src/main/docbook/Hibernate_Reference.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/architecture.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/association_mapping.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/basic_mapping.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/batch.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/best_practices.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/collection_mapping.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/component_mapping.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/configuration.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/events.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/example_mappings.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/example_parentchild.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/example_weblog.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/filters.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/inheritance_mapping.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/performance.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/persistent_classes.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/preface.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/query_criteria.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/query_hql.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/query_sql.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/quickstart.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/session_api.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/toolset_guide.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/transactions.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/tutorial.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/content/xml.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/images/ core/trunk/documentation/manual/ko-KR/src/main/docbook/images/AuthorWork.png core/trunk/documentation/manual/ko-KR/src/main/docbook/images/AuthorWork.zargo core/trunk/documentation/manual/ko-KR/src/main/docbook/images/CustomerOrderProduct.png core/trunk/documentation/manual/ko-KR/src/main/docbook/images/CustomerOrderProduct.zargo core/trunk/documentation/manual/ko-KR/src/main/docbook/images/EmployerEmployee.png core/trunk/documentation/manual/ko-KR/src/main/docbook/images/EmployerEmployee.zargo core/trunk/documentation/manual/ko-KR/src/main/docbook/images/full_cream.png core/trunk/documentation/manual/ko-KR/src/main/docbook/images/full_cream.svg core/trunk/documentation/manual/ko-KR/src/main/docbook/images/hibernate_logo_a.png core/trunk/documentation/manual/ko-KR/src/main/docbook/images/lite.png core/trunk/documentation/manual/ko-KR/src/main/docbook/images/lite.svg core/trunk/documentation/manual/ko-KR/src/main/docbook/images/overview.png core/trunk/documentation/manual/ko-KR/src/main/docbook/images/overview.svg core/trunk/documentation/manual/ko-KR/src/main/docbook/legal_notice.xml Removed: core/trunk/documentation/manual/ko-KR/src/main/docbook/master.xml core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/ core/trunk/documentation/manual/ko-KR/src/main/resources/ Log: new docbook layout (prep for translations migration to PO) Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/Hibernate_Reference.xml (from rev 14073, core/trunk/documentation/manual/en-US/src/main/docbook/Hibernate_Reference.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/Hibernate_Reference.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/Hibernate_Reference.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,72 @@ +<?xml version='1.0' encoding="UTF-8"?> + +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ + <!ENTITY versionNumber "3.3.0.alpha1"> + <!ENTITY copyrightYear "2004"> + <!ENTITY copyrightHolder "Red Hat Middleware, LLC."> +]> + +<book> + + <bookinfo> + <title>HIBERNATE - 개성있는 자바를 위한 관계 영속</title> + <subtitle>하이버네이트 참조 문서</subtitle> + <releaseinfo>&versionNumber;</releaseinfo> + <productnumber>&versionNumber;</productnumber> + <issuenum>1</issuenum> + <mediaobject> + <imageobject role="fo"> + <imagedata fileref="images/hibernate_logo_a.png" align="center" /> + </imageobject> + <imageobject role="html"> + <imagedata fileref="images/hibernate_logo_a.png" depth="3cm" /> + </imageobject> + </mediaobject> + <copyright> + <year>&copyrightYear;</year> + <holder>&copyrightHolder;</holder> + </copyright> + <xi:include href="legal_notice.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + </bookinfo> + + <toc/> + + <xi:include href="content/preface.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + + <xi:include href="content/tutorial.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + + <xi:include href="content/architecture.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + + <xi:include href="content/configuration.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + + <xi:include href="content/persistent_classes.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + + <xi:include href="content/basic_mapping.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="content/collection_mapping.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="content/association_mapping.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="content/component_mapping.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="content/inheritance_mapping.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + + <xi:include href="content/session_api.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="content/transactions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="content/events.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="content/batch.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + + <xi:include href="content/query_hql.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="content/query_criteria.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="content/query_sql.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="content/filters.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="content/xml.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + + <xi:include href="content/performance.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + + <xi:include href="content/toolset_guide.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + + <xi:include href="content/example_parentchild.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="content/example_weblog.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="content/example_mappings.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + + <xi:include href="content/best_practices.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + +</book> + Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/architecture.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/architecture.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/architecture.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/architecture.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,323 @@ +<!-- + ~ Copyright (c) 2007, Red Hat Middleware, LLC. All rights reserved. + ~ + ~ This copyrighted material is made available to anyone wishing to use, modify, + ~ copy, or redistribute it subject to the terms and conditions of the GNU + ~ Lesser General Public License, v. 2.1. This program is distributed in the + ~ hope that it will be useful, but WITHOUT A WARRANTY; without even the implied + ~ warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + ~ Lesser General Public License for more details. You should have received a + ~ copy of the GNU Lesser General Public License, v.2.1 along with this + ~ distribution; if not, write to the Free Software Foundation, Inc., + ~ 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + ~ + ~ Red Hat Author(s): Steve Ebersole + --> +<chapter id="architecture"> + + <title>아키텍처</title> + + <sect1 id="architecture-overview" revision="1"> + <title>개요</title> + + <para> + Hibernate 아키텍처에 대한 (매우) 높은 수준의 개요:: + </para> + + <mediaobject> + <imageobject role="fo"> + <imagedata fileref="../images/overview.svg" format="SVG" align="center"/> + </imageobject> + <imageobject role="html"> + <imagedata fileref="../images/overview.png" format="PNG" align="center"/> + </imageobject> + </mediaobject> + + <para> + 이 다이어그램은 어플리케이션에 영속화 서비스들(과 영속 객체들)을 제공하기 위해 데이터베이스와 + 컨피그레이션을 사용하는 Hibernate를 보여준다. + </para> + + <para> + 우리는 런타임 아키텍처에 대한 보다 상세한 뷰를 보여주고 싶다. 불행하게도, Hibernate는 유연하며 + 몇 가지 접근법들을 제공한다. 우리는 두 가지 극단을 보여줄 것이다. "경량급" 아키텍처는 그것 자신의 + JDBC 커넥션들을 제공하고 그것 자신의 트랜잭션들을 관리하는 어플리케이션을 갖는다. 이 접근법은 + Hibernate의 API의 최소 부분집합을 사용한다: + </para> + + <mediaobject> + <imageobject role="fo"> + <imagedata fileref="../images/lite.svg" format="SVG" align="center"/> + </imageobject> + <imageobject role="html"> + <imagedata fileref="../images/lite.png" format="PNG" align="center"/> + </imageobject> + </mediaobject> + + <para> + "전체 정수" 아키텍처는 기본 JDBC/JTA로부터 어플리케이션을 추상화 시키고 Hibernate로 하여금 + 상세한 것을 처리하게 한다. + </para> + + <mediaobject> + <imageobject role="fo"> + <imagedata fileref="../images/full_cream.svg" format="SVG" align="center"/> + </imageobject> + <imageobject role="html"> + <imagedata fileref="../images/full_cream.png" format="PNG" align="center"/> + </imageobject> + </mediaobject> + + <para> + 다음은 다이어그램들 내에 있는 객체들에 대한 몇가지 정의들이다: + + <variablelist spacing="compact"> + <varlistentry> + <term>SessionFactory (<literal>org.hibernate.SessionFactory</literal>)</term> + <listitem> + <para> + 단일 데이터베이스에 대한 컴파일된 매핑들의 threadsafe (불변의) 캐시. Session과 ConnectionProvider의 + 클라이언트를 위한 팩토리. 프로세스 레벨 또는 클러스터 레벨에서 트랜잭션들 사이에 재사용 가능한 데이터의 선택적인 + (second-level) 캐시를 보관할 수도 있다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>Session (<literal>org.hibernate.Session</literal>)</term> + <listitem> + <para> + 어플리케이션과 영속 저장소 사이의 대화를 표현하는 단일 쓰레드이고, 수명이 짧은 객체. JDBC 커넥션을 포장한다. + <literal>Transaction</literal> 용 팩토리. 객체 그래프를 네비게이트 하거나 식별자로 객체들을 룩업할 때 + 사용되는 영속 객체들에 대한 필수적인(첫 번째 레벨의) 캐시를 보관한다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>영속 객체들과 콜렉션들</term> + <listitem> + <para> + persistent 상태와 비지니스 기능을 포함하는 수명이 짧고, 단일 쓰레드인 객체들. 이것들은 통상의 JavaBeans/POJO들일 + 수 있고, 오직 그것들에 대한 오직 특별한 것은 그것들이 현재 (정확하게 한 개의) <literal>Session</literal>과 연관되어 + 있다는 점이다. <literal>Session</literal>이 닫히자마자, 그것들은 분리될(detached 상태가 될) 것이고 어플리케이션 + 레이어에서 사용하는 것이 자유로와진다(예를 들면. 직접적으로 프리젠테이션 계층으로 + 데이터 전송 객체들로서 그리고 직접적으로 프리젠테이션 계층으로부터 데이터 전송 객체들로서). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>전이(Transient, 필자 주-과도) 객체들과 콜렉션들</term> + <listitem> + <para> + <literal>Session</literal>과 현재 연관되어 있지 않은 영속 클래스들의 인스턴스들. 그것들은 어플리케이션에 의해 초기화 + 되었고 (아직) 영속화 되지 않았거나 그것들은 닫혀진<literal>Session</literal>에 의해 초기화 되었을 수도 있다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>Transaction (<literal>org.hibernate.Transaction</literal>)</term> + <listitem> + <para> + (옵션) 작업의 원자 단위를 지정하기 위해 어플리케이션에 의해 사용되는 단일 쓰레드이고, 수명이 짧은 객체. 기본 JDBC, JTA + 또는 CORBA 트랜잭션으로부터 어플리케이션을 추상화 시킨다. 몇몇 경우들에서 하나의 <literal>Session</literal>은 + 여러 개의 <literal>Transaction</literal>들에 걸칠 수 있다. 하지만 기본 API 또는 <literal>Transaction</literal>을 + 사용하는 트랜잭션 경계 설정은 결코 옵션이 아니다! + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>ConnectionProvider (<literal>org.hibernate.connection.ConnectionProvider</literal>)</term> + <listitem> + <para> + (옵션) JDBC 커넥션들에 대한 팩토리(그리고 그것들의 pool). 기본 <literal>Datasource</literal> 또는 + <literal>DriverManager</literal>로부터 어플리케이션을 추상화 시킨다. 어플리케이션에 노출되지는 않지만 + 개발자에 의해 확장/구현 된다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>TransactionFactory (<literal>org.hibernate.TransactionFactory</literal>)</term> + <listitem> + <para> + (옵션) <literal>Transaction</literal> 인스턴스들에 대한 팩토리. 어플리케이션에 노출되지는 않지만 개발자에 의해 + 확장/구현 된다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><emphasis>Extension Interfaces</emphasis></term> + <listitem> + <para> + Hibernate는 당신의 영속 계층의 특성을 맞춤화 시키기 위해 당신이 구현할 수 있는 선택적인 확장 인터페이스들을 제공한다. + 상세한 것은 API 문서를 보라. + </para> + </listitem> + </varlistentry> + </variablelist> + </para> + + <para> + 주어진 "경량급" 아키텍처의 경우, 어플리케이션은 JTA 또는 JDBC와 직접 대화하기 위해서 <literal>Transaction</literal>/<literal>TransactionFactory</literal> + 그리고/또는 <literal>ConnectionProvider</literal> API들을 무시한다. + </para> + </sect1> + + <sect1 id="architecture-states" revision="1"> + <title>인스턴스 상태들</title> + <para> + 영속 클래스들의 인스턴스는 세개의 상태들 중 하나 일 수 있다. 그것들(상태들)은 영속 컨텍스트(<emphasis>persistence context</emphasis>)에 + 대해 정의된다. Hibernate <literal>Session</literal> 객체는 영속 컨텍스트이다: + </para> + + <variablelist spacing="compact"> + <varlistentry> + <term>transient</term> + <listitem> + <para> + 인스턴스는 임의의 컨텍스트와 연관되어 있지 않고, 결코 연관된 적이 없었다. 그것은 영속 식별자(프라이머리 키 값)을 갖지 않는다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>persistent</term> + <listitem> + <para> + 인스턴스는 현재 영속 컨텍스트와 연관되어 있다. 그것은 영속 식별자(프라이머리 키 값) 그리고 아마 데이터베이스 내에 있는 대응하는 + 행을 갖는다. 특별한 영속 컨텍스트의 경우, Hibernate는 영속 identity가 Java identity(객체의 메모리 내 위치)와 같다는 점을 + <emphasis>보증한다</emphasis>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>detached</term> + <listitem> + <para> + 인스턴스는 영속 컨텍스트와 한번 연관되었지만, 그 컨텍스트가 닫혔거나, 그 인스턴스가 또 다른 프로세스로 직렬화 되었다. 그것은 영속 + identity 그리고, 아마 데이터베이스 내에 대응하는 행을 갖는다. detached 인스턴스들의 경우, Hibernate는 영속 identity과 + Java identity 사이의 관계를 보증하지 않는다. + </para> + </listitem> + </varlistentry> + </variablelist> + </sect1> + + <sect1 id="architecture-jmx" revision="1"> + <title>JMX 통합</title> + + <para> + JMX는 자바 컴포넌트 관리를 위한 J2EE 표준이다. Hibernate는 JMX 표준 서비스를 통해 관리될 수도 있다. 우리는 배포본 내에 MBean 구현, + <literal>org.hibernate.jmx.HibernateService</literal>를 제공한다. + </para> + + <para> + JBoss 어플리케이션 서버 상에 Hibernae를 JMX 서비스로서 배치하는 방법에 대한 예제는 JBoss 사용자 가이드를 보길 바란다. JBoss + 어플리케이션 서버 상에서, 만일 당신이 JMX를 사용하여 배치할 경우 당신은 또한 다음 이점들을 얻는다: + </para> + + <itemizedlist> + <listitem> + <para> + <emphasis>Session 관리:</emphasis> Hibernate <literal>Session</literal>의 생명주기가 JTA 트랜잭션의 + 영역 내에 자동적으로 바인드 될 수 있다. 이것은 당신이 더이상 <literal>Session</literal>을 수작업으로 열고 닫지 않아도 + 됨을 의미하고, 이것은 JBoss EJB 인터셉터의 업무가 된다. 당신은 또한 더 이상 당신의 코드 어느 곳에서든 트랜잭션 경계설정에 + 대해 걱정하지 않아도 된다(당신이 물론 이식성 있는 영속 계층을 작성하고자 원하지 않는한, 이를 위해 옵션 Hibernate <literal>Transaction</literal> + API를 사용하라). 당신은 <literal>Session</literal>에 접근하기 위해 <literal>HibernateContext</literal>를 호출한다. + </para> + </listitem> + <listitem> + <para> + <emphasis>HAR 배치:</emphasis> 대개 당신은 JBoss 서비스 배치 디스크립터를 사용하여 Hibernate JMX 서비스를 + (EAR 과/또는 SAR 파일로) 배치하고, 그것은 Hibernate <literal>SessionFactory</literal>의 통상적인 구성 + 옵션들 모두를 지원한다. 하지만 당신은 여전히 모든 당신의 매핑 파일들을 배치 디스크립터 속에 명명해야 한다. 만일 당신이 + 옵션 HAR 배치를 사용하고자 결정하는 경우, JBoss는 당신의 HAR 파일 내에 있는 모든 매핑 파일들을 자동적으로 검출해낼 것이다. + </para> + </listitem> + </itemizedlist> + + <para> + 이들 옵션들에 대한 추가 정보는 JBoss 어플리케이션 서버 사용자 가이드를 참조하라. + </para> + + <para> + JMX 서비스로서 이용 가능한 또다른 특징은 런타임 Hibernate 통계이다. + <xref linkend="configuration-optional-statistics"/>를 보라. + </para> + </sect1> + + <sect1 id="architecture-jca" revision="1"> + <title>JCA 지원</title> + <para> + Hibernate는 JCA 커넥터로서 구성될 수도 있다. 상세한 것은 웹 사이트를 보길 바란다. Hibernate JCA 지원은 여전히 실험적으로 + 검토 중에 있음을 노트하길 바란다. + </para> + </sect1> + + <sect1 id="architecture-current-session" revision="2"> + <title>컨텍스트 상의 세션들</title> + <para> + Hibernate를 사용하는 대부분의 어플리케이션들은 어떤 양식의 "컨텍스트상의(contextual)" 세션들을 필요로 한다. 여기서 + 주어진 세션은 주어진 컨텍스트의 영역에 걸쳐 활동을 한다. 하지만 어플리케이션들을 가로질러 컨텍스트를 구성하는 것에 대한 정의는 + 일반적으로 다르다; 그리고 다른 컨텍스트들은 현재라고 하는 개념에 대해 다른 영역들을 정의한다. 버전 3.0 전의 Hibernate를 + 사용하는 어플리케이션들은 자가생산된 <literal>ThreadLocal</literal>-기반의 컨텍스상의 세션들, + <literal>HibernateUtil</literal>과 같은 helper 클래스들을 활용했거나 + 프락시/인터셉션 기반의 컨텍스트상의 세션들을 제공해주었던 (Spring 또는 Pico와 같은 )제 3의 프레임웍들을 활용하는 경향이 있었다. + </para> + <para> + 버전 3.0.1에서부터 시작하여, Hibernate는 <literal>SessionFactory.getCurrentSession()</literal> 메소드를 + 추가했다. 초기에 이것은 <literal>JTA</literal> 트랜잭션들을 사용하는 것을 전제했다. 여기서 <literal>JTA</literal> + 트랜잭션은 현재 세션의 영역과 컨텍스트를 정의했다. Hibernate 팀은 성숙된 다수의 스탠드얼론 <literal>JTA TransactionManager</literal> + 구현들이 발표되면, (전부는 아니겠지만) 대부분의 어플리케이션들이 그것들이 <literal>J2EE</literal> 컨테이너 내로 배치되든 + 그렇지 않든 간에 <literal>JTA</literal> 트랜잭션 관리를 사용하게 될 것이라고 주장한다. 그것에 기초하여, <literal>JTA</literal>에 기반한 + 컨텍스트상의 세션들은 언젠가 당신이 사용을 필요로 하게 될 전부다. + </para> + <para> + 하지만 버전 3.1 이후로 <literal>SessionFactory.getCurrentSession()</literal> 이면의 처리과정은 + 이제 플러그 가능하다. 그것을 끝내기 위해, 하나의 새로운 확장 인터페이스 + (<literal>org.hibernate.context.CurrentSessionContext</literal>)와 + 하나의 새로운 구성 파라미터(<literal>hibernate.current_session_context_class</literal>)가 현재 세션들을 + 정의하는 영역과 컨텍스트의 플러그 가능성을 허용하기 위해 추가되었다. + </para> + <para> + 그것의 계약에 대한 상세한 논의는 <literal>org.hibernate.context.CurrentSessionContext</literal> 인터페이스에 + 관한 javadocs를 보라. 그것은 하나의 메소드, <literal>currentSession()</literal>를 정의하며, 그 구현은 + 현재의 컨텍스트 상의 세션을 추적할 책임이 있다. 비공식적으로, Hibernate는 이 인터페이스에 대한 세 개의 구현들을 부수적으로 + 포함하고 있다. + </para> + + <itemizedlist> + <listitem> + <para> + <literal>org.hibernate.context.JTASessionContext</literal> - 현재의 세션들은 하나의 + <literal>JTA</literal>에 의해 추적되고 영역화 된다. 여기서 처리과정은 이전의 JTA-전용 접근과 정확하게 + 동일하다. 상세한 것은 javadocs를 보라. + </para> + </listitem> + <listitem> + <para> + <literal>org.hibernate.context.ThreadLocalSessionContext</literal> - 현재의 세션들은 + 실행 쓰레드에 의해 추적된다. 상세한 것은 다시 javadocs를 보라. + </para> + </listitem> + </itemizedlist> + <para> + 처음의 두 구현들은 <emphasis>session-per-request</emphasis>로 알려지고 사용되고 있는 + "하나의 세션 - 하나의 데이터베이스 트랜잭션" 프로그래밍 모형을 제공한다. 하나의 Hibernate 세션의 시작과 끝은 + 데이터베이스 트랜잭션의 존속 기간에 의해 정의된다. 만일 (예를 들면 순수 J2SE에서 또는 JTA/UserTransaction/BMT의 경우에) + 당신이 프로그램 상의 트랜잭션 경계구분을 사용할 경우, 당신은 당신의 코드로부터 기본 트랜잭션 시스템을 은폐시키는데 + Hibernate <literal>Transaction</literal> API를 사용하는 것이 권장된다. 만일 당신이 CMT를 지원하는 + 하나의 EJB 컨테이너에서 실행할 경우, 트랜잭션 경계들이 선언적으로 정의되고 당신은 당신의 코드 내에 어떤 트랜잭션도 + 세션 경계구분 오퍼레이션들을 필요로 하지 않는다. 추가 정보와 코드 예제들은 <xref linkend="transactions"/>를 참조하라. + </para> + + <para> + <literal>hibernate.current_session_context_class</literal> 구성 파라미터는 + <literal>org.hibernate.context.CurrentSessionContext</literal> 구현이 사용될 것임을 정의한다. 역호환을 위해. + 만일 이 구성 파라미터가 설정되지 않았지만 하나의 <literal>org.hibernate.transaction.TransactionManagerLookup</literal>이 + 구성되어 있을 경우, Hibernate는 <literal>org.hibernate.context.JTASessionContext</literal>를 사용할 것임을 + 노트하라. 일반적으로, 이 파라미터의 값은 단지 사용할 구현 클래스를 명명할 것이다; 하지만 두 가지 비공식적인 구현들로서 두 개의 + 대응하는 짧은 이름들 "jta"와 "thread"이 존재한다. + </para> + + </sect1> + +</chapter> + Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/association_mapping.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/association_mapping.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/association_mapping.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/association_mapping.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,603 @@ +<chapter id="associations"> + + <title>연관 매핑들</title> + + <sect1 id="assoc-intro" revision="1"> + <title>개요</title> + + <para> + 연관 매핑들은 올바른 것을 얻기가 종종 가장 어려운 것이다. 이 절에서 우리는 단방향 매핑들에서 시작하고, 그런 다음 양방향 경우들을 + 검토함으로써, 하나씩 표준적인 경우들을 상세히 논의할 것이다. 우리는 모든 예제들에서 <literal>Person</literal>과 + <literal>Address</literal>를 사용할 것이다. + </para> + + <para> + 우리는 연관들을 중재하는 join 테이블로 매핑시킬 것인지 여부에 따라, 그리고 multiplicity(다중성)에 따라 연관들을 분류할 것이다. + </para> + + <para> + null 허용 가능한 foreign 키들은 전통적인 데이터 모델링에서 좋은 실례로 간주되지 않아서, 모든 우리의 예제들은 not null + foreign 키들을 사용한다. 이것은 Hibernate에서 필수가 아니고, 당신이 null 허용 가능 컨스트레인트들을 드롭시킬 경우 매핑들은 + 모두 동작할 것이다. + </para> + + </sect1> + + <sect1 id="assoc-unidirectional" revision="1"> + <title>단방향 연관들</title> + + <sect2 id="assoc-unidirectional-m21"> + <title>many to one</title> + + <para> + <emphasis>단방향 many-to-one 연관</emphasis>은 가장 공통적인 종류의 단방향 연관이다. + </para> + + <programlisting><![CDATA[<class name="Person"> + <id name="id" column="personId"> + <generator class="native"/> + </id> + <many-to-one name="address" + column="addressId" + not-null="true"/> +</class> + +<class name="Address"> + <id name="id" column="addressId"> + <generator class="native"/> + </id> +</class>]]></programlisting> + <programlisting><![CDATA[ +create table Person ( personId bigint not null primary key, addressId bigint not null ) +create table Address ( addressId bigint not null primary key ) + ]]></programlisting> + + </sect2> + + <sect2 id="assoc-unidirectional-121"> + <title>one to one</title> + + <para> + <emphasis>foreign 키에 대한 단방향 one-to-one 연관은 대개 아주 동일하다.</emphasis> 유일한 차이점은 + 컬럼 유일(unique) 컨스트레인트이다. + </para> + + <programlisting><![CDATA[<class name="Person"> + <id name="id" column="personId"> + <generator class="native"/> + </id> + <many-to-one name="address" + column="addressId" + unique="true" + not-null="true"/> +</class> + +<class name="Address"> + <id name="id" column="addressId"> + <generator class="native"/> + </id> +</class>]]></programlisting> + <programlisting><![CDATA[ +create table Person ( personId bigint not null primary key, addressId bigint not null unique ) +create table Address ( addressId bigint not null primary key ) + ]]></programlisting> + + <para> + <emphasis>하나의 프라이머리 키에 대한 단방향 one-to-one 연관</emphasis>은 대개 특별한 id 생성기를 사용한다. + (이 예제에서 연관의 방향이 역전되었음을 주목하라.) + </para> + + <programlisting><![CDATA[<class name="Person"> + <id name="id" column="personId"> + <generator class="native"/> + </id> +</class> + +<class name="Address"> + <id name="id" column="personId"> + <generator class="foreign"> + <param name="property">person</param> + </generator> + </id> + <one-to-one name="person" constrained="true"/> +</class>]]></programlisting> + <programlisting><![CDATA[ +create table Person ( personId bigint not null primary key ) +create table Address ( personId bigint not null primary key ) + ]]></programlisting> + + </sect2> + + <sect2 id="assoc-unidirectional-12m"> + <title>one to many</title> + + <para> + <emphasis>하나의 foreign 키에 대한 단방향 one-to-many 연관</emphasis>은 매우 색다른 경우이고, 실제로 권장되지 않는다. + </para> + + <programlisting><![CDATA[<class name="Person"> + <id name="id" column="personId"> + <generator class="native"/> + </id> + <set name="addresses"> + <key column="personId" + not-null="true"/> + <one-to-many class="Address"/> + </set> +</class> + +<class name="Address"> + <id name="id" column="addressId"> + <generator class="native"/> + </id> +</class>]]></programlisting> + <programlisting><![CDATA[ +create table Person ( personId bigint not null primary key ) +create table Address ( addressId bigint not null primary key, personId bigint not null ) + ]]></programlisting> + + <para> + 우리는 이런 종류의 연관에 대해 하나의 join 테이블을 사용하는 것이 더 좋다고 생각한다. + </para> + + </sect2> + + </sect1> + + <sect1 id="assoc-unidirectional-join" revision="1"> + <title>join 테이블들에 대한 단방향 연관들</title> + + <sect2 id="assoc-unidirectional-join-12m"> + <title>one to many</title> + + <para> + <emphasis>하나의 join 테이블에 대한 단방향 one-to-many 연관</emphasis>이 보다 더 선호된다. <literal>unique="true"</literal>를 + 지정함으로써 우리는 many-to-many에서 one-to-many로 아중성(multiplicity)를 변경시켰음을 주목하라. + </para> + + <programlisting><![CDATA[<class name="Person"> + <id name="id" column="personId"> + <generator class="native"/> + </id> + <set name="addresses" table="PersonAddress"> + <key column="personId"/> + <many-to-many column="addressId" + unique="true" + class="Address"/> + </set> +</class> + +<class name="Address"> + <id name="id" column="addressId"> + <generator class="native"/> + </id> +</class>]]></programlisting> + <programlisting><![CDATA[ +create table Person ( personId bigint not null primary key ) +create table PersonAddress ( personId not null, addressId bigint not null primary key ) +create table Address ( addressId bigint not null primary key ) + ]]></programlisting> + + </sect2> + + <sect2 id="assoc-unidirectional-join-m21"> + <title>many to one</title> + + <para> + <emphasis>하나의 join 테이블에 대한 단방향 many-to-one 연관</emphasis>은 그 연관이 선택적일 때 매우 공통적이다. + </para> + + <programlisting><![CDATA[<class name="Person"> + <id name="id" column="personId"> + <generator class="native"/> + </id> + <join table="PersonAddress" + optional="true"> + <key column="personId" unique="true"/> + <many-to-one name="address" + column="addressId" + not-null="true"/> + </join> +</class> + +<class name="Address"> + <id name="id" column="addressId"> + <generator class="native"/> + </id> +</class>]]></programlisting> + <programlisting><![CDATA[ +create table Person ( personId bigint not null primary key ) +create table PersonAddress ( personId bigint not null primary key, addressId bigint not null ) +create table Address ( addressId bigint not null primary key ) + ]]></programlisting> + + </sect2> + + <sect2 id="assoc-unidirectional-join-121"> + <title>one to one</title> + + <para> + <emphasis>하나의 join 테이블에 대한 단방향 one-to-one 연관</emphasis>은 극히 통상적이지 않지만 가능하다. + </para> + + <programlisting><![CDATA[<class name="Person"> + <id name="id" column="personId"> + <generator class="native"/> + </id> + <join table="PersonAddress" + optional="true"> + <key column="personId" + unique="true"/> + <many-to-one name="address" + column="addressId" + not-null="true" + unique="true"/> + </join> +</class> + +<class name="Address"> + <id name="id" column="addressId"> + <generator class="native"/> + </id> +</class>]]></programlisting> + <programlisting><![CDATA[ +create table Person ( personId bigint not null primary key ) +create table PersonAddress ( personId bigint not null primary key, addressId bigint not null unique ) +create table Address ( addressId bigint not null primary key ) + ]]></programlisting> + + </sect2> + + <sect2 id="assoc-unidirectional-join-m2m"> + <title>many to many</title> + + <para> + 마지막으로, 우리는 <emphasis>단방향 many-to-many 연관</emphasis>을 갖는다. + </para> + + <programlisting><![CDATA[<class name="Person"> + <id name="id" column="personId"> + <generator class="native"/> + </id> + <set name="addresses" table="PersonAddress"> + <key column="personId"/> + <many-to-many column="addressId" + class="Address"/> + </set> +</class> + +<class name="Address"> + <id name="id" column="addressId"> + <generator class="native"/> + </id> +</class>]]></programlisting> + <programlisting><![CDATA[ +create table Person ( personId bigint not null primary key ) +create table PersonAddress ( personId bigint not null, addressId bigint not null, primary key (personId, addressId) ) +create table Address ( addressId bigint not null primary key ) + ]]></programlisting> + + </sect2> + + </sect1> + + <sect1 id="assoc-bidirectional" revision="1"> + <title>양방향 연관들</title> + + <sect2 id="assoc-bidirectional-m21" revision="2"> + <title>one to many / many to one</title> + + <para> + <emphasis>양방향 many-to-one 연관</emphasis>은 가장 공통된 종류의 연관이다.(이것은 표준 부모/자식 관계이다. ) + </para> + + <programlisting><![CDATA[<class name="Person"> + <id name="id" column="personId"> + <generator class="native"/> + </id> + <many-to-one name="address" + column="addressId" + not-null="true"/> +</class> + +<class name="Address"> + <id name="id" column="addressId"> + <generator class="native"/> + </id> + <set name="people" inverse="true"> + <key column="addressId"/> + <one-to-many class="Person"/> + </set> +</class>]]></programlisting> + + <programlisting><![CDATA[ +create table Person ( personId bigint not null primary key, addressId bigint not null ) +create table Address ( addressId bigint not null primary key ) + ]]></programlisting> + + <para> + 만일 당신이 <literal>List</literal>(또는 다른 인덱싱 된 콜렉션)을 사용할 경우 당신은 foreign key의 + <literal>key</literal> 컬럼을 <literal>not null</literal>로 설정하고, Hibernate로 하여금 + 각각의 요소의 인덱스를 유지관리하기 위해 (<literal>update="false"</literal>와 + <literal>insert="false"</literal>를 설정함으로써 다른 측을 가상적으로 inverse로 만들어) + 그 콜렉션들 측으로부터 연관을 관리하도록 할 필요가 있다: + </para> + + <programlisting><![CDATA[<class name="Person"> + <id name="id"/> + ... + <many-to-one name="address" + column="addressId" + not-null="true" + insert="false" + update="false"/> +</class> + +<class name="Address"> + <id name="id"/> + ... + <list name="people"> + <key column="addressId" not-null="true"/> + <list-index column="peopleIdx"/> + <one-to-many class="Person"/> + </list> +</class>]]></programlisting> + + <para> + 만일 기본 외래 키 컬럼이 <literal>NOT NULL</literal>일 경우 콜렉션 매핑의 <literal>&lt;key&gt;</literal> + 요소 상에 <literal>not-null="true"</literal>를 정의하는 것이 중요하다. 내포된 + <literal>&lt;column&gt;</literal> 요소 상에 <literal>not-null="true"</literal>를 + 선언하지 말고, <literal>&lt;key&gt;</literal> 요소 상에 선언하라. + </para> + + </sect2> + + <sect2 id="assoc-bidirectional-121"> + <title>one to one</title> + + <para> + <emphasis>foreign에 대한 양방향 one-to-one 연관</emphasis>은 꽤 공통적이다. + </para> + + <programlisting><![CDATA[<class name="Person"> + <id name="id" column="personId"> + <generator class="native"/> + </id> + <many-to-one name="address" + column="addressId" + unique="true" + not-null="true"/> +</class> + +<class name="Address"> + <id name="id" column="addressId"> + <generator class="native"/> + </id> + <one-to-one name="person" + property-ref="address"/> +</class>]]></programlisting> + <programlisting><![CDATA[ +create table Person ( personId bigint not null primary key, addressId bigint not null unique ) +create table Address ( addressId bigint not null primary key ) + ]]></programlisting> + + <para> + <emphasis>하나의 프라이머리 키에 대한 양방향 one-to-one 연관</emphasis>은 특별한 id 생성기를 사용한다. + </para> + + <programlisting><![CDATA[<class name="Person"> + <id name="id" column="personId"> + <generator class="native"/> + </id> + <one-to-one name="address"/> +</class> + +<class name="Address"> + <id name="id" column="personId"> + <generator class="foreign"> + <param name="property">person</param> + </generator> + </id> + <one-to-one name="person" + constrained="true"/> +</class>]]></programlisting> + <programlisting><![CDATA[ +create table Person ( personId bigint not null primary key ) +create table Address ( personId bigint not null primary key ) + ]]></programlisting> + + </sect2> + + </sect1> + + <sect1 id="assoc-bidirectional-join" revision="1"> + <title>join 테이블들에 대한 양방향 연관들</title> + + <sect2 id="assoc-bidirectional-join-12m"> + <title>one to many / many to one</title> + + <para> + <emphasis>하나의 join 테이블에 대한 양방향 one-to-many 연관</emphasis>. <literal>inverse="true"</literal>는 + 연관의 어느 쪽 끝이든 콜렉션 측으로 또는 join 측으로 갈 수 있다. + </para> + + <programlisting><![CDATA[<class name="Person"> + <id name="id" column="personId"> + <generator class="native"/> + </id> + <set name="addresses" + table="PersonAddress"> + <key column="personId"/> + <many-to-many column="addressId" + unique="true" + class="Address"/> + </set> +</class> + +<class name="Address"> + <id name="id" column="addressId"> + <generator class="native"/> + </id> + <join table="PersonAddress" + inverse="true" + optional="true"> + <key column="addressId"/> + <many-to-one name="person" + column="personId" + not-null="true"/> + </join> +</class>]]></programlisting> + <programlisting><![CDATA[ +create table Person ( personId bigint not null primary key ) +create table PersonAddress ( personId bigint not null, addressId bigint not null primary key ) +create table Address ( addressId bigint not null primary key ) + ]]></programlisting> + + </sect2> + + <sect2 id="assoc-bidirectional-join-121"> + <title>one to one</title> + + <para> + <emphasis>하나의 join 테이블에 대한 양방향 one-to-one 연관</emphasis>은 극히 통상적이지 않지만, 가능하다. + </para> + + <programlisting><![CDATA[<class name="Person"> + <id name="id" column="personId"> + <generator class="native"/> + </id> + <join table="PersonAddress" + optional="true"> + <key column="personId" + unique="true"/> + <many-to-one name="address" + column="addressId" + not-null="true" + unique="true"/> + </join> +</class> + +<class name="Address"> + <id name="id" column="addressId"> + <generator class="native"/> + </id> + <join table="PersonAddress" + optional="true" + inverse="true"> + <key column="addressId" + unique="true"/> + <many-to-one name="person" + column="personId" + not-null="true" + unique="true"/> + </join> +</class>]]></programlisting> + <programlisting><![CDATA[ +create table Person ( personId bigint not null primary key ) +create table PersonAddress ( personId bigint not null primary key, addressId bigint not null unique ) +create table Address ( addressId bigint not null primary key ) + ]]></programlisting> + + </sect2> + + <sect2 id="assoc-bidirectional-join-m2m" revision="1"> + <title>many to many</title> + + <para> + 마지막으로, 우리는 하나의 <emphasis>양방향 many-to-many 연관</emphasis>을 갖는다. + </para> + + <programlisting><![CDATA[<class name="Person"> + <id name="id" column="personId"> + <generator class="native"/> + </id> + <set name="addresses" table="PersonAddress"> + <key column="personId"/> + <many-to-many column="addressId" + class="Address"/> + </set> +</class> + +<class name="Address"> + <id name="id" column="addressId"> + <generator class="native"/> + </id> + <set name="people" inverse="true" table="PersonAddress"> + <key column="addressId"/> + <many-to-many column="personId" + class="Person"/> + </set> +</class>]]></programlisting> + + <programlisting><![CDATA[ +create table Person ( personId bigint not null primary key ) +create table PersonAddress ( personId bigint not null, addressId bigint not null, primary key (personId, addressId) ) +create table Address ( addressId bigint not null primary key ) + ]]></programlisting> + + </sect2> + + </sect1> + + <sect1 id="assoc-complex"> + <title>보다 복잡한 연관 매핑들</title> + + <para> + 보다 복잡한 연관 조인들은 <emphasis>극기</emphasis> 드물다. + Hibernate는 매핑 문서들 내에 삽입된 SQL 조각들을 사용하여 보다 복잡한 상황을 처리하는 것을 + 가능하도록 해준다. 예를 들어, 만일 계좌 내역 정보 데이터를 가진 하나이 테이블이 + <literal>accountNumber</literal>, <literal>effectiveEndDate</literal> + 그리고 <literal>effectiveStartDate</literal> 컬럼들을 정의할 경우, 다음과 같이 매핑된다: + </para> + + <programlisting><![CDATA[<properties name="currentAccountKey"> + <property name="accountNumber" type="string" not-null="true"/> + <property name="currentAccount" type="boolean"> + <formula>case when effectiveEndDate is null then 1 else 0 end</formula> + </property> +</properties> +<property name="effectiveEndDate" type="date"/> +<property name="effectiveStateDate" type="date" not-null="true"/>]]></programlisting> + + <para> + 그때 우리는 다음을 사용하여 하나의 연관을 <emphasis>현재</emphasis> 인스턴스 + (null <literal>effectiveEndDate</literal>을 가진 인스턴스)로 매핑시킬 수 있다: + </para> + + <programlisting><![CDATA[<many-to-one name="currentAccountInfo" + property-ref="currentAccountKey" + class="AccountInfo"> + <column name="accountNumber"/> + <formula>'1'</formula> +</many-to-one>]]></programlisting> + + <para> + 보다 복잡한 예제에서, <literal>Employee</literal>와 <literal>Organization</literal> 사이의 + 연관이 전체 고용 내역 데이터를 가진 <literal>Employment</literal> 테이블 내에 유지된다고 가정하자. + 그때 종업원의 <emphasis>가장 최근의</emphasis> 고용주에 대한 하나의 연관(가장 최근의 + <literal>startDate</literal>를 갖고 있는 것)이 다음 방법으로 매핑될 수 있다: + </para> + + <programlisting><![CDATA[<join> + <key column="employeeId"/> + <subselect> + select employeeId, orgId + from Employments + group by orgId + having startDate = max(startDate) + </subselect> + <many-to-one name="mostRecentEmployer" + class="Organization" + column="orgId"/> +</join>]]></programlisting> + + <para> + 당신은 이 기능으로 아주 생산성을 얻을 수 있지만, 그것은 대개 HQL 또는 criteria 질의를 사용하여 이들 종류의 경우들을 + 처리하는 것이 보다 실용적이다. + </para> + + </sect1> + + +</chapter> + Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/basic_mapping.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/basic_mapping.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/basic_mapping.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/basic_mapping.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,3202 @@ +<chapter id="mapping"> + <title>기본 O/R 매핑</title> + + <sect1 id="mapping-declaration" revision="1"> + <title>매핑 선언</title> + + <para> + 객체/관계형 매핑들은 대개 XML 문서 내에 정의된다. 매핑 문서는 가독성이 있고 수작업 편집이 가능하도록 + 설계되어 있다. 매핑 언어는 매핑들이 테이블 선언들이 아닌, 영속 클래스 선언들로 생성된다는 의미에서 + 자바 중심적이다. + </para> + + <para> + 심지어 많은 Hibernate 사용자들이 수작업으로 XML을 작성하고자 선택할지라도, XDoclet, Middlegen, + 그리고 AndroMDA를 포함하는, 매핑 문서를 생성시키는 많은 도구들이 존재한다는 점을 노트하라. + </para> + + <para> + 예제 매핑으로 시작하자: + </para> + + <programlisting id="mapping-declaration-ex1" revision="1"><![CDATA[<?xml version="1.0"?> +<!DOCTYPE hibernate-mapping PUBLIC + "-//Hibernate/Hibernate Mapping DTD 3.0//EN" + "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> + +<hibernate-mapping package="eg"> + + <class name="Cat" + table="cats" + discriminator-value="C"> + + <id name="id"> + <generator class="native"/> + </id> + + <discriminator column="subclass" + type="character"/> + + <property name="weight"/> + + <property name="birthdate" + type="date" + not-null="true" + update="false"/> + + <property name="color" + type="eg.types.ColorUserType" + not-null="true" + update="false"/> + + <property name="sex" + not-null="true" + update="false"/> + + <property name="litterId" + column="litterId" + update="false"/> + + <many-to-one name="mother" + column="mother_id" + update="false"/> + + <set name="kittens" + inverse="true" + order-by="litter_id"> + <key column="mother_id"/> + <one-to-many class="Cat"/> + </set> + + <subclass name="DomesticCat" + discriminator-value="D"> + + <property name="name" + type="string"/> + + </subclass> + + </class> + + <class name="Dog"> + <!-- mapping for Dog could go here --> + </class> + +</hibernate-mapping>]]></programlisting> + + <para> + 우리는 이제 매핑 문서의 내용을 논의할 것이다. 우리는 Hibernate에 의해 실행 시에 사용되는 문서 요소들과 + 속성들 만을 설명할 것이다. 매핑 문서는 또한 스키마 내보내기 도구에 의해 내보내진 데이터베이스 스키마에 + 영향을 주는 어떤 특별한 옵션 속성들과 요소들을 포함한다. (예를 들어 <literal>not-null</literal> 속성.) + </para> + + + + <sect2 id="mapping-declaration-doctype" revision="3"> + <title>Doctype</title> + + <para> + 모든 XML 매핑들은 doctype이 보이게 선언해야 한다. 실제 DTD는 위의 URL에서, + <literal>hibernate-x.x.x/src/org/hibernate</literal> 디렉토리 내에서 또는 <literal>hibernate3.jar</literal> + 내에서 찾을 수 있다. Hibernate는 항상 첫 번째로 그것의 classpath 속에서 DTD를 찾게 될 것이다. 만일 + 당신이 인터넷 연결을 사용하는 DTD에 대한 룩업들을 겪게 될 경우, 당신의 classpath의 컨텐츠에 대해 당신의 DTD 선언을 + 체크하라. + </para> + + <sect3 id="mapping-declaration-entity-resolution"> + <title>EntityResolver</title> + <para> + 앞서 언급했듯이, Hibernate는 먼저 그것의 classpath에서 DTD들을 해석하려고 시도할 것이다. + Hibernate가 이것을 행하는 방법은 그것이 xml 파일들을 읽어들이는데 사용하는 SAXReader에 맞춤형 + <literal>org.xml.sax.EntityResolver</literal> 구현을 등록하는 것이다. 이 맞춤형 + <literal>EntityResolver</literal>는 두 개의 다른 systemId namespace들을 인지해낸다. + </para> + <itemizedlist> + <listitem> + <para> + <literal>hibernate namespace</literal>는 resolver가 + <literal>http://hibernate.sourceforge.net/</literal>로 시작하는 하나의 + systemId와 만날때마다 인지된다; resolver는 Hibernate 클래스들을 로드시켰던 클래스로더를 통해 + 이들 엔티티들을 해석하려고 시도한다. + </para> + </listitem> + <listitem> + <para> + <literal>user namespace</literal>는 resolver가 <literal>classpath://</literal> + URL 프로토콜을 사용하는 systemId를 만날때마다 인지된다; resolver는 (1)현재 쓰레드 컨텍스트 + 클래스로더와 (2)Hibernate 클래스들을 로드시켰던 클래스로더를 통해 이들 엔티티들을 해석하려고 + 시도할 것이다. + </para> + </listitem> + </itemizedlist> + <para> + user namespacing을 활용하는 예제: + </para> + <programlisting><![CDATA[<?xml version="1.0"?> +<!DOCTYPE hibernate-mapping PUBLIC + "-//Hibernate/Hibernate Mapping DTD 3.0//EN" + "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd" [ + <!ENTITY types SYSTEM "classpath://your/domain/types.xml"> +]> + +<hibernate-mapping package="your.domain"> + <class name="MyEntity"> + <id name="id" type="my-custom-id-type"> + ... + </id> + <class> + &types; +</hibernate-mapping>]]></programlisting> + <para> + 여기서 <literal>types.xml</literal>은 <literal>your.domain</literal> 패키지 내에 있는 리소스이고 + 맞춤형 <xref linkend="mapping-types-custom">typedef</xref>를 포함한다. + </para> + </sect3> + </sect2> + + <sect2 id="mapping-declaration-mapping" revision="3"> + <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>auto-import</literal> 속성은 디폴트로 우리가 질의 언어 속에서 수식어가 붙지 않은(unqualified) + 클래스 이름들을 사용하게 할 것이다. + </para> + + <programlistingco> + <areaspec> + <area id="hm1" coords="2 55"/> + <area id="hm2" coords="3 55"/> + <area id="hm3" coords="4 55"/> + <area id="hm4" coords="5 55"/> + <area id="hm5" coords="6 55"/> + <area id="hm6" coords="7 55"/> + <area id="hm7" coords="8 55"/> + </areaspec> + <programlisting><![CDATA[<hibernate-mapping + schema="schemaName" + catalog="catalogName" + default-cascade="cascade_style" + default-access="field|property|ClassName" + default-lazy="true|false" + auto-import="true|false" + package="package.name" + />]]></programlisting> + <calloutlist> + <callout arearefs="hm1"> + <para> + <literal>schema</literal> (옵션): 데이터베이스 스키마의 이름. + </para> + </callout> + <callout arearefs="hm2"> + <para> + <literal>catalog</literal> (옵션): 데이터베이스 카다록의 이름. + </para> + </callout> + <callout arearefs="hm3"> + <para> + <literal>default-cascade</literal> (옵션 - 디폴트는 <literal>none</literal>): + 디폴트 cascade 스타일. + </para> + </callout> + <callout arearefs="hm4"> + <para> + <literal>default-access</literal> (옵션 - 디폴트는 <literal>property</literal>): + Hibernate가 모든 프로퍼티들에 액세스하는데 사용하게 될 방도. <literal>PropertyAccessor</literal>에 + 대한 맞춤형 구현일 수 있다. + </para> + </callout> + <callout arearefs="hm5"> + <para> + <literal>default-lazy</literal> (옵션 - 디폴트는 <literal>true</literal>): + class 및 collection 매핑들의 지정되지 않은 <literal>lazy</literal> 속성들에 대한 디폴트 값. + </para> + </callout> + <callout arearefs="hm6"> + <para> + <literal>auto-import</literal> (옵션 - 디폴트는 <literal>true</literal>): + 우리가 질의 언어 내에 (이 매핑에서 클래스들에 대해) 수식어가 붙지 않은 클래스 이름들을 사용할 수 있는지를 + 지정한다. + </para> + </callout> + <callout arearefs="hm7"> + <para> + <literal>package</literal> (옵션): 매핑 문서 내에서 수식어가 붙지 않은 클래스 이름들에 대해 + 가정할 패키지 접두어를 지정한다. + </para> + </callout> + </calloutlist> + </programlistingco> + + <para> + 만일 당신이 동일한 (수식어가 붙지 않은) 이름을 가진 두 개의 영속 클래스들을 갖고 있다면, 당신은 <literal>auto-import="false"</literal>를 + 설정해야 한다. 만일 당신이 두 개의 클래스들에 동일한 "imported" 이름을 할당하려고 시도할 경우에 Hibernate는 예외상황을 던질 것이다. + </para> + + <para> + 위에 보여진 것처럼 <literal>hibernate-mapping</literal> 요소는 몇몇 영속 <literal>&lt;class&gt;</literal> 매핑들을 내부에 포함하는 + 것을 허용해준다는 점을 노트하라. 하지만 한 개의 매핑 파일 속에 한 개의 영속 클래스(또는 한 개의 클래스 계층구조) 만을 매핑하고 영속 서브 클래스 뒤에 + 그것을 명명하는 것이 좋은 연습이다 (그리고 몇몇 도구들에 의해 기대된다). 예를 들면 <literal>Cat.hbm.xml</literal>, + <literal>Dog.hbm.xml</literal> 또는 상속을 사용할 경우에는 <literal>Animal.hbm.xml</literal>. + </para> + + </sect2> + + <sect2 id="mapping-declaration-class" revision="3"> + <title>class</title> + + <para> + 당신은 <literal>class</literal> 요소를 사용하여 영속 클래스를 선언할 수도 있다: + </para> + + <programlistingco> + <areaspec> + <area id="class1" coords="2 55"/> + <area id="class2" coords="3 55" /> + <area id="class3" coords="4 55"/> + <area id="class4" coords="5 55" /> + <area id="class5" coords="6 55"/> + <area id="class6" coords="7 55" /> + <area id="class7" coords="8 55"/> + <area id="class8" coords="9 55" /> + <area id="class9" coords="10 55" /> + <area id="class10" coords="11 55"/> + <area id="class11" coords="12 55"/> + <area id="class12" coords="13 55"/> + <area id="class13" coords="14 55"/> + <area id="class14" coords="15 55"/> + <area id="class15" coords="16 55"/> + <area id="class16" coords="17 55"/> + <area id="class17" coords="18 55"/> + <area id="class18" coords="19 55"/> + <area id="class19" coords="20 55"/> + <area id="class20" coords="21 55"/> + <area id="class21" coords="22 55"/> + </areaspec> + <programlisting><![CDATA[<class + name="ClassName" + table="tableName" + discriminator-value="discriminator_value" + mutable="true|false" + schema="owner" + catalog="catalog" + proxy="ProxyInterface" + dynamic-update="true|false" + dynamic-insert="true|false" + select-before-update="true|false" + polymorphism="implicit|explicit" + where="arbitrary sql where condition" + persister="PersisterClass" + batch-size="N" + optimistic-lock="none|version|dirty|all" + lazy="true|false" + entity-name="EntityName" + check="arbitrary sql check condition" + rowid="rowid" + subselect="SQL expression" + abstract="true|false" + node="element-name" +/>]]></programlisting> + <calloutlist> + <callout arearefs="class1"> + <para> + <literal>name</literal> (옵션): 영속 클래스(또는 인터페이스)의 전체 수식어가 붙은 Java 클래스 이름. + 만일 이 속성이 누락될 경우, 매핑이 non-POJO 엔티티라고 가정된다. + </para> + </callout> + <callout arearefs="class2"> + <para> + <literal>table</literal> (옵션 - 디폴트는 수식어가 붙지 않은 클래스명): 그것의 데이터베이스 테이블의 이름. + </para> + </callout> + <callout arearefs="class3"> + <para> + <literal>discriminator-value</literal> (옵션 - 디폴트는 클래스 이름): 다형성(polymorphic) 특징에 사용되는, + 개별 서브 클래스들를 구별짓는 값. 허용가능한 값들은<literal>null</literal>과 <literal>not null</literal>을 포함한다. + </para> + </callout> + <callout arearefs="class4"> + <para> + <literal>mutable</literal> (옵션 - 디폴트는 <literal>true</literal>): 클래스들의 인스턴스들이 가변적인지를 + (가변적이지 않은지를) 지정한다. + </para> + </callout> + <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이 아닌 컬럼들 만을 + 포함할 것인지를 지정한다. + </para> + </callout> + <callout arearefs="class10"> + <para> + <literal>select-before-update</literal> (옵션 - 디폴트는 <literal>false</literal>): + 객체가 실제로 변경되는 것이 확실하지 않는 한, Hibernate가 SQL <literal>UPDATE</literal>를 + <emphasis>결코</emphasis> 실행하지 않을 것임을 지정한다. 어떤 경우들에서(실제로 transient + 객체가 <literal>update()</literal>를 사용하여 새로운 session에 연관되었을 때에만), 이것은 + 하나의 <literal>UPDATE</literal>가 실제로 필요한 경우인지 여부를 결정하기 위해 Hibernate는 + 특별한 SQL <literal>SELECT</literal>를 실행할 것임을 의미한다. + </para> + </callout> + <callout arearefs="class11"> + <para> + <literal>polymorphism</literal> (옵션 - 디폴트는 <literal>implicit</literal>): + implicit 질의 다형성이나 explicit 질의 다형성 중 어느 것이 사용될 것인지를 결정한다. + </para> + </callout> + <callout arearefs="class12"> + <para> + <literal>where</literal> (옵션) 이 클래스의 객체들을 검색할 때 사용될 임의적인 SQL + <literal>WHERE</literal> 조건을 지정한다 + </para> + </callout> + <callout arearefs="class13"> + <para> + <literal>persister</literal> (옵션): 맞춤형 <literal>ClassPersister</literal>를 지정한다. + </para> + </callout> + <callout arearefs="class14"> + <para> + <literal>batch-size</literal> (옵션 - 디폴트는 <literal>1</literal>) 식별자에 의해 이 클래스의 + 인스턴스들을 페치시키는 "배치 사이즈"를 지정한다. + </para> + </callout> + <callout arearefs="class15"> + <para> + <literal>optimistic-lock</literal> (옵션 - 디폴트는 <literal>version</literal>): + optimistic 잠금 방도를 결정한다. + </para> + </callout> + <callout arearefs="class16"> + <para> + <literal>lazy</literal> (옵션): <literal>lazy="false"</literal>를 설정함으로써 + Lazy fetching이 전체적으로 사용불가능하게 될 수 있다. + </para> + </callout> + <callout arearefs="class17"> + <para> + <literal>entity-name</literal>(옵션, 디폴트는 클래스 이름): Hibernate3는 하나의 클래스가 + (잠정적으로 다른 테이블들로) 여러번 매핑되는 것을 허용해주고, Java 레벨에서 Map 또는 XML에 의해 표현 + 되는 엔티티 매핑들을 허용한다. 이들 경우들에서, 당신은 그 엔티티에 대한 명시적인 임의의 이름을 제공해야 한다. + <literal>entity-name</literal> (옵션): Hibernate3는 하나의 클래스가 (잠정적으로 다른 테이블들로) + 여러 번 매핑되는 것을 허용하며, 자바 레벨에서 Map들 또는 XML에 의해 표현되는 엔티티 매핑들을 허용한다. + 이들 경우들에서, 당신은 그 엔티티들에 대한 명시적인 임의의 이름을 제공해야 한다. 추가 정보는 + <xref linkend="persistent-classes-dynamicmodels"/>과 <xref linkend="xml"/>을 보라. + </para> + </callout> + <callout arearefs="class18"> + <para> + <literal>check</literal> (옵션): 자동적인 스키마 생성을 위한 다중-행 <emphasis>check</emphasis> + constraint를 생성시키는데 사용되는 SQL 표현식. + </para> + </callout> + <callout arearefs="class19"> + <para> + <literal>rowid</literal> (옵션): Hibernate는 지원되는 데이터베이스들, 예를 들어 Oracle 상에서 이른바 + ROWID들을 사용할 수 있고, Hibernate는 당신이 이 옵션을 <literal>rowid</literal>로 설정하는 경우에 빠른 + 업데이트를 위한 특별한 <literal>rowid</literal> 컬럼을 사용할 수 있다. ROWID는 구현 상세이고 저장된 + 튜플(tuple)의 물리적이니 위치를 표현한다. + </para> + </callout> + <callout arearefs="class20"> + <para> + <literal>subselect</literal> (옵션): 불변의 읽기 전용 엔티티를 데이터베이스 subselect로 매핑시킨다. + 당신이 기본 테이블 대신에 뷰를 갖고자 원할 경우에 유용하지만, 사용을 자제하라. 추가 정보는 아래를 보라. + </para> + </callout> + <callout arearefs="class21"> + <para> + <literal>abstract</literal> (옵션): <literal>&lt;union-subclass&gt;</literal> 계층 구조들 내에서 + abstract 슈퍼클래스들을 마크하는데 사용된다. + </para> + </callout> + </calloutlist> + </programlistingco> + + <para> + 명명된 영속 클래스가 인터페이스가 되는 것은 완전히 수용가능하다. 그런 다음 당신은 <literal>&lt;subclass&gt;</literal> + 요소를 사용하여 그 인터페이스에 대한 구현 클래스들을 선언할 것이다. 당신은 임의의 <emphasis>static</emphasis> inner + 클래스를 영속화 시킬 수 있다. 당신은 표준 형식, 예를 들어 <literal>eg.Foo$Bar</literal>를 사용하여 클래스 이름을 + 지정해야 한다. + </para> + + <para> + 불변의 클래스, <literal>mutable="false"</literal>는 어플리케이션에 의해 업데이트되지 않을 것이거나 삭제되지 않을 것이다. + 이것은 Hibernate로 하여금 어떤 마이너 퍼포먼스 최적화를 행하게끔 허용해준다. + </para> + + <para> + 선택적인 <literal>proxy</literal> 속성은 그 클래스의 영속 인스턴스들에 대한 lazy 초기화를 가능하게 해준다. Hibernate는 + 명명된 인터페이스를 구현하는 CGLIB 프락시들을 초기에 반환할 것이다. 실제 영속 객체는 프락시의 메소드가 호출될 때 로드될 것이다. + 아래 "Lazy 초기화를 위한 프락시들"을 보라. + </para> + + <para><emphasis>Implicit</emphasis> 다형성은 클래스의 인스턴스들이 어떤 서브클래스나 구현된 인터페이스 또는 클래스를 명명하는 + 질의에 의해 반환될 것임을 의미하고 그 클래스의 어떤 서브클래스에 대한 인스턴스들이 그 클래스 자체를 명명하는 질의에 의해 반환될 것임을 + 의미한다. <emphasis>Explicit</emphasis> 다형성은 클래스 인스턴스들이 그 클래스를 명시적으로 명명하는 질의들에 의해서만 + 반환될 것임을 의미고 그 클래스를 명명하는 질의들이 이 <literal>&lt;class&gt;</literal> 선언 내부에서 <literal>&lt;subclass&gt;</literal> + 또는 <literal>&lt;joined-subclass&gt;</literal>로 매핑된 서브 클래스들의 인스턴스들 만을 반환하게 될 것임을 의미한다. + 대부분의 용도로, 디폴트인 <literal>polymorphism="implicit"</literal>가 적절하다.두 개의 다른 클래스들이 동일한 테이블로 + 매핑될 때 Explicit 다형성이 유용하다(이것은 테이블 컬럼들의 서브셋을 포함하는 "경량급" 클래스를 허용한다). + </para> + + <para> + <literal>persister</literal> 속성은 클래스에 사용되는 영속화 방도를 당신이 커스트마이징 할 수 있도록 해준다. 예를 들어 + 당신은 <literal>org.hibernate.persister.EntityPersister</literal>에 대한 당신 자신의 서브클래스를 지정할 수도 + 있거나 당신은 심지어 예를 들어 플랫 파일들이나 LDAP로의 직렬화,내장 프로시저 호출들을 통해 영속화를 구현하는 인터페이스 + <literal>org.hibernate.persister.ClassPersister</literal>에 대한 완전히 새로운 구현을 제공할 수도 있다. + (<literal>Hashtable</literal>로의 "영속성"에 관한) 간단한 예제는 + <literal>org.hibernate.test.CustomPersister</literal>를 보라. + </para> + + <para> + <literal>dynamic-update</literal> 설정과 <literal>dynamic-insert</literal> 설정은 서브클래스들에 의해 + 상속되지 않고 따라서 또한 <literal>&lt;subclass&gt;</literal> 또는 <literal>&lt;joined-subclass&gt;</literal> + 요소들 상에 지정될 수도 있음을 노트하라. 이들 설정들은 몇몇 경우들에서 퍼포먼스를 증가시키지만 다른 경우들에서는 퍼포먼스를 + 실제로 감소시킬 수도 있다. 적절하게 사용하라. + </para> + + <para> + <literal>select-before-update</literal> 사용은 대개 퍼포먼스를 감소시킬 것이다. 당신이 detached 인스턴스들의 + 그래프를 <literal>Session</literal>에 다시 첨부할 경우에 그것은 데이터베이스 업데이트 트리거가 불필요하게 호출되는 + 것을 방지하는데 매우 유용하다. + </para> + + <para> + <literal>dynamic-update</literal>를 사용가능하게 할 경우, 당신은 다음 optimistic 잠금 전략들을 선택하게 될 것이다: + </para> + <itemizedlist> + <listitem> + <para> + <literal>version</literal>은 version/timestamp 컬럼들을 체크한다 + </para> + </listitem> + <listitem> + <para> + <literal>all</literal>은 모든 컬럼들을 체크한다 + </para> + </listitem> + <listitem> + <para> + <literal>dirty</literal>는 몇몇 동시성 업데이트들을 허용하여, 변경된 컬럼들을 체크한다 + </para> + </listitem> + <listitem> + <para> + <literal>none</literal>은 optimistic 잠금을 사용하지 않는다 + </para> + </listitem> + </itemizedlist> + <para> + 우리는 당신이 Hibernate에서 optimistic 잠금을 위해 version/timestamp 컬럼들을 사용할 것을 <emphasis>매우</emphasis> 강력하게 + 권장한다. 이것은 퍼포먼스에 대해 최적의 방도이고 detached 인스턴스들에 대해 행해진 변경들을 정확하게 핸들링하는 유일한 방도이다(예를 들어 + <literal>Session.merge()</literal>가 사용될 때). + </para> + + <para> + Hibernate 매핑의 경우에 베이스 테이블과 뷰 사이에 차이점이 존재하지 않는다. 왜냐하면 이것이 데이터베이스 레벨에서는 투명하다고 기대되기 + 때문이다(몇몇 DBMS는 뷰를 고유하게 지원하지 않고 특히 뷰 업데이트를 지원하지 않음을 노트하라). 때때로 당신이 뷰를 사용하고자 원하지만, + (예를 들어 리거시 스키마로) 데이터베이스 속에 뷰를 생성시킬 수 없다. 이 경우에, 당신은 불변의 읽기 전용 엔티티를 주어진 SQL subselect + 표현식으로 매핑시킬 수 있다: + </para> + + <programlisting><![CDATA[<class name="Summary"> + <subselect> + select item.name, max(bid.amount), count(*) + from item + join bid on bid.item_id = item.id + group by item.name + </subselect> + <synchronize table="item"/> + <synchronize table="bid"/> + <id name="name"/> + ... +</class>]]></programlisting> + + <para> + auto-flush가 정확하게 발생하도록 하고, 그리고 파생된 엔티티에 대한 질의들이 쓸효성 없는 데이터를 반환하지 않도록 함으로써, 이 엔티티와 동기화 될 + 테이블을 선언하라. <literal>&lt;subselect&gt;</literal>는 속성과 내포된 매핑 요소 양자로서 이용 가능하다. + </para> + + </sect2> + + <sect2 id="mapping-declaration-id" revision="4"> + <title>id</title> + + <para> + 매핑된 클래스들은 데이터베이스 테이블의 프라이머리 키 컬럼을 선언<emphasis>해야 한다</emphasis>. 대부분의 클래스들은 또한 인스턴스의 유일 식별자를 소유하는 + 자바빈즈-스타일 프로퍼티를 가질 것이다. <literal>&lt;id&gt;</literal> 요소는 그 프로퍼티로부터 프라이머리 키 컬럼으로의 매핑을 정의한다. + </para> + + <programlistingco> + <areaspec> + <area id="id1" coords="2 70"/> + <area id="id2" coords="3 70" /> + <area id="id3" coords="4 70"/> + <area id="id4" coords="5 70" /> + <area id="id5" coords="6 70" /> + </areaspec> + <programlisting><![CDATA[<id + name="propertyName" + type="typename" + column="column_name" + unsaved-value="null|any|none|undefined|id_value" + access="field|property|ClassName"> + node=&quot;element-name|@attribute-name|element/(a)attribute|.&quot; + + <generator class="generatorClass"/> +</id>]]></programlisting> + <calloutlist> + <callout arearefs="id1"> + <para> + <literal>name</literal> (옵션): 식별자 프로퍼티의 이름. + </para> + </callout> + <callout arearefs="id2"> + <para> + <literal>type</literal> (옵션): Hibernate 타입을 나타내는 이름. + </para> + </callout> + <callout arearefs="id3"> + <para> + <literal>column</literal> (옵션 - 디폴트는 프로퍼티 이름): 프라이머리 키 컬럼의 이름. + </para> + </callout> + <callout arearefs="id4"> + <para> + <literal>unsaved-value</literal> (옵션 - 디폴트는 "sensible" 값): + 이전 세션에서 저장되었거나 로드되었던 detached(분리된) 인스턴스들로부터 그것을 구분지우도록, 인스턴스가 새로이 초기화되어 있음(저장되어 + 있지 않음)을 나타내는 식별자 프로퍼티 값. + </para> + </callout> + <callout arearefs="id5"> + <para> + <literal>access</literal> (옵션 - 디폴트는 <literal>property</literal>): + Hibernate가 프로퍼티 값에 액세스하는데 사용할 방도. + </para> + </callout> + </calloutlist> + </programlistingco> + + <para> + <literal>name</literal> 속성이 누락되면, 클래스는 식별자 프로퍼티를 갖지 않는다고 가정된다. + </para> + + <para> + <literal>unsaved-value</literal> 속성은 Hibernate3에서는 거의 필요하지 않다. + </para> + + <para> + composite 키들로서 리거시 데이터에 액세스하는 것을 허용해주는 대체적인 <literal>&lt;composite-id&gt;</literal> + 선언이 존재한다. 우리는 그 밖의 어떤것에 대한 그것의 사용에 대해 강력하게 반대한다. + </para> + + <sect3 id="mapping-declaration-id-generator" revision="2"> + <title>Generator</title> + + <para> + 선택적인 <literal>&lt;generator&gt;</literal> 자식 요소는 영속 클래스의 인스턴스들에 대한 유일 식별자들을 생성시키는데 사용되는 + 자바 클래스를 명명한다. 만일 임의의 파라미터들이 생성기 인스턴스를 구성하거나 초기화 시키는데 필요할 경우, 그것들은 <literal>&lt;param&gt;</literal> + 요소 를 사용하여 전달된다. + </para> + + <programlisting><![CDATA[<id name="id" type="long" column="cat_id"> + <generator class="org.hibernate.id.TableHiLoGenerator"> + <param name="table">uid_table</param> + <param name="column">next_hi_value_column</param> + </generator> +</id>]]></programlisting> + + <para> + 모든 생성기들은 <literal>org.hibernate.id.IdentifierGenerator</literal> 인터페이스를 구현한다. 이것은 매우 간단한 인터페이스이다; + 몇몇 어플리케이션들은 그것들 자신의 특화된 구현들을 제공하도록 선택할 수 있다. 하지만 Hibernate는 미리 빈드된 구현들의 영역들을 제공한다. + 빌드-인 생성기(generator)들에 대한 단축 이름들이 존재한다: + + <variablelist> + <varlistentry> + <term><literal>increment</literal></term> + <listitem> + <para> + 동일한 테이블 속으로 데이터를 입력하는 다른 프로세스가 없을 때에만 유일한 <literal>long</literal>, <literal>short</literal> 또는 <literal>int</literal> + 타입의 식별자들을 생성시킨다. <emphasis>클러스터 내에서는 사용하지 말라.</emphasis> + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>identity</literal></term> + <listitem> + <para> + DB2, MySQL, MS SQL Server, Sybase, HypersonicSQL에서 식별 컬럼들을 지원한다. 반환되는 식별자는 <literal>long</literal>, + <literal>short</literal> 또는 <literal>int</literal> 타입이다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>sequence</literal></term> + <listitem> + <para> + DB2, PostgreSQL, Oracle, SAP DB, McKoi에서 시퀀스를 사용하거나 Interbase에서 생성기(generator)를 사용한다. 반환되는 식별자는 + <literal>long</literal>, <literal>short</literal> 또는 <literal>int</literal> 타입이다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>hilo</literal></term> + <listitem> + <para id="mapping-declaration-id-hilodescription" revision="1"> + 테이블과 컬럼(디폴트로 각각 <literal>hibernate_unique_key</literal>와 <literal>next_hi</literal>)이 hi 값들의 + 소스로서 주어지면, <literal>long</literal>, <literal>short</literal> 또는 <literal>int</literal> 타입의 + 식별자들을 효과적으로 생성시키는데 hi/lo 알고리즘을 사용한다. hi/lo 알고리즘은 특정 데이터베이스에 대해서만 유일한 식별자들을 + 생성시킨다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>seqhilo</literal></term> + <listitem> + <para> + 명명된 데이터베이스 시퀀스가 주어지면, <literal>long</literal>, <literal>short</literal> 또는 <literal>int</literal> + 타입의 식별자들을 효과적으로 생성시키는데 hi/lo 알고리즘을 사용한다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>uuid</literal></term> + <listitem> + <para> + 네트웍 내에서 유일한(IP 주소가 사용된다) string 타입의 식별자들을 생성시키기 위해 128 비트 UUID 알고리즘을 사용한다. + UUID는 길이가 32인 16진수들의 문자열로서 인코딩 된다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>guid</literal></term> + <listitem> + <para> + MS SQL Server와 MySQL 상에서 데이터베이스 생성 GUID 문자열을 사용한다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>native</literal></term> + <listitem> + <para> + 기본 데이터베이스의 가용성들에 의존하여 <literal>identity</literal>, <literal>sequence</literal> + 또는 <literal>hilo</literal>를 찾아낸다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>assigned</literal></term> + <listitem> + <para> + 어플리케이션으로 하여금 <literal>save()</literal>가 호출되기 전에 식별자를 객체에 할당하도록 한다. + <literal>&lt;generator&gt;</literal> 요소가 지정되지 않을 경우 이것이 디폴트 방도이다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>select</literal></term> + <listitem> + <para> + 어떤 유일 키에 의해 행을 select하고 프라이머리 키 값을 검색함으로써 데이터베이스 트리거에 의해 할당된 + 프라이머리 키를 검색한다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>foreign</literal></term> + <listitem> + <para> + 또 다른 연관된 객체의 식별자를 사용한다. 대개 <literal>&lt;one-to-one&gt;</literal> 프라이머리 키 + 연관관계와 함께 사용된다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>sequence-identity</literal></term> + <listitem> + <para> + 실제 값 생성을 위해 데이터베이스 시퀀스를 활용하지만, 생성된 식별자 값을 insert 문장 실행의 부분으로서 + 실제로 반환시키기 위해 이것을 JDBC3 getGeneratedKeys와 결합시킨 특화된 시퀀스 생성 방도. 이 방도는 + JDK 1.4에 대상화된 Oracle 10g 드라이버들 상에서만 지원되는 거승로 알려져 있다. 이들 insert 문장들에 + 대한 주석들은 Oracle 드라이버들 내에 있는 버그 때문에 사용불가능하게 되어 있음을 노트하라. + </para> + </listitem> + </varlistentry> + </variablelist> + + </para> + </sect3> + + <sect3 id="mapping-declaration-id-hilo" revision="1"> + <title>Hi/lo algorithm</title> + <para> + <literal>hilo</literal>와 <literal>seqhilo</literal> 생성기들은 식별자 생성에 대한 마음에 드는 접근법인, + hi/lo 알고리즘에 대한 두 개의 대체 구현들은 제공한다. 첫 번째 구현은 다음에 이용 가능한 "hi" 값을 수용하기 위한 "특별한" + 데이터베이스 테이블을 필요로 한다. 두 번째는 (지원되는) Oracle 스타일의 시퀀스를 사용한다. + </para> + + <programlisting><![CDATA[<id name="id" type="long" column="cat_id"> + <generator class="hilo"> + <param name="table">hi_value</param> + <param name="column">next_value</param> + <param name="max_lo">100</param> + </generator> +</id>]]></programlisting> + + <programlisting><![CDATA[<id name="id" type="long" column="cat_id"> + <generator class="seqhilo"> + <param name="sequence">hi_value</param> + <param name="max_lo">100</param> + </generator> +</id>]]></programlisting> + + <para> + 불행히도 당신은 Hibernate에 당신 자신의 <literal>Connection</literal>을 제공할 때 <literal>hilo</literal>를 + 사용할 수 없다. Hibernate가 JTA의 도움을 받는 커넥션들을 얻기 위해 어플리케이션 서버 데이터소스를 사용할 때 당신은 + <literal>hibernate.transaction.manager_lookup_class</literal>를 적절하게 구성해야 한다. + </para> + </sect3> + + <sect3 id="mapping-declaration-id-uuid"> + <title>UUID 알고리즘</title> + <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 질의들을 필요로 한다. + </para> + + <programlisting><![CDATA[<id name="id" type="long" column="person_id"> + <generator class="sequence"> + <param name="sequence">person_id_sequence</param> + </generator> +</id>]]></programlisting> + + <programlisting><![CDATA[<id name="id" type="long" column="person_id" unsaved-value="0"> + <generator class="identity"/> +</id>]]></programlisting> + + <para> + 크로스 플랫폼 개발을 위해서, <literal>native</literal> 방도가 기준 데이터베이스들의 가용성들에 따라 <literal>identity</literal>, + <literal>sequence</literal>, <literal>hilo</literal> 방도 중에서 선택될 것이다. + </para> + </sect3> + + <sect3 id="mapping-declaration-id-assigned"> + <title>할당된 식별자들</title> + <para> + (Hibernate로 하여금 식별자들을 생성시키도록 하는 것과는 반대로) 당신이 어플리케이션으로 하여금 식별자들을 할당하도록 원할 경우, + 당신은 <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>를 + Hibernate에게 사용하도록 한다. + </para> + </sect3> + + <sect3 id="mapping-declaration-id-select"> + <title>트리거들에 의해 할당된 프라이머리 키들</title> + <para> + 리거시 스키마에 대해서만(Hibernate는 트리거들을 가진 DDL을 생성시키지 않는다). + </para> + + <programlisting><![CDATA[<id name="id" type="long" column="person_id"> + <generator class="select"> + <param name="key">socialSecurityNumber</param> + </generator> +</id>]]></programlisting> + + <para> + 위의 예제에서, natural 키로서 클래스에 의해 <literal>socialSecurityNumber</literal>로 명명된 유일 값을 가진 프로퍼티가 존재하고, + 트리거에 의해 그 값이 생성되는 <literal>person_id</literal>로 명명된 대용키가 존재한다. + </para> + + </sect3> + + </sect2> + + <sect2 id="mapping-declaration-compositeid" revision="3"> + <title>composite-id</title> + + <programlisting><![CDATA[<composite-id + name="propertyName" + class="ClassName" + mapped="true|false" + access="field|property|ClassName"> + node="element-name|." + + <key-property name="propertyName" type="typename" column="column_name"/> + <key-many-to-one name="propertyName class="ClassName" column="column_name"/> + ...... +</composite-id>]]></programlisting> + + <para> + composite 키를 가진 테이블의 경우, 당신은 클래스의 여러 프로퍼티들을 식별자 프로퍼티들로서 매핑할 수 있다. + <literal>&lt;composite-id&gt;</literal> 요소는 자식 요소들로서 <literal>&lt;key-property&gt;</literal> + 프로퍼티 매핑과 <literal>&lt;key-many-to-one&gt;</literal> 매핑들을 허용한다. + </para> + + <programlisting><![CDATA[<composite-id> + <key-property name="medicareNumber"/> + <key-property name="dependent"/> +</composite-id>]]></programlisting> + + <para> + 당신의 영속 클래스는 composite 식별자 동등성을 구현하기 위해서 <literal>equals()</literal>와 + <literal>hashCode()</literal>를 오버라이드 <emphasis>시켜야 한다</emphasis>. 그것은 또한 + <literal>Serializable</literal>을 구현해야 한다. + </para> + + <para> + 불행히도, composite 식별자들에 대한 이 접근법은 영속 객체가 그것 자신의 식별자라는 점을 의미한다. 객체 + 자신 외의 다른 "핸들"이 존재하지 않는다. 당신은 당신이 composite key로 연관된 영속 상태를 <literal>load()</literal> + 할 수 있기 이전에 영속 클래스 그 자체의 인스턴스를 초기화 하고 그것의 식별자 프로퍼티들을 군집화 시켜야 한다. 우리는 + 이 접근법을 <emphasis>embedded</emphasis> composite 식별자로 부르고, 중대한 어플리케이션들에 대해 그것을 억제시킨다. + </para> + + <para> + 두 번째 접근법은 우리가 <emphasis>mapped</emphasis> composite 식별자라고 부르는 것인데, 여기서 + <literal>&lt;composite-id&gt;</literal> 요소 내에 명명된 여기서 식별자 프로퍼티들은 영속 클래스와 별도의 식별자 클래스 + 양자 상에 중복된다. + </para> + + <programlisting><![CDATA[<composite-id class="MedicareId" mapped="true"> + <key-property name="medicareNumber"/> + <key-property name="dependent"/> +</composite-id>]]></programlisting> + + <para> + 이 예제에서, composite 식별자 클래스인 <literal>MedicareId</literal>와 엔티티 크래스 그 자체 양자는 + <literal>medicareNumber</literal>와 <literal>dependent</literal>로 명명된 프로퍼티들을 갖는다. 식별자 클래스는 + <literal>equals()</literal>와 <literal>hashCode()</literal>를 오버라이드 시켜고 <literal>Serializable</literal>을 + 구현해야 한다. 이 접근법의 단점은 아주 명백한&mdash;코드 중복이다. + </para> + + <para> + 다음 속성들은 매핑된 composite 식별자를 지정하는데 사용된다: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + <literal>mapped</literal> (옵션, 디폴트는 <literal>false</literal>): + 하나의 매핑된 composite 식별자가 사용됨을, 그리고 포함된 프로퍼티 매핑들이 엔티티 클래스와 + composite 식별자 클래스 양자를 참조함을 나타낸다. + </para> + </listitem> + <listitem> + <para> + <literal>class</literal> (옵션, 하지만 하나의 매핑된 commposite 식별자에 대해서는 필수적임): + 하나의 composite 식별자로서 사용되는 클래스. + </para> + </listitem> + </itemizedlist> + + <para> + 우리는 <xref linkend="components-compositeid"/>에서 composite 식별자가 하나의 component 클래스로서 구현되는 + 보다 편리한 접근법인 세번째 방도를 설명할 것이다. 아래에 설명되어 있는 속성들은 이 대체적인 접근법에만 적용된다: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + <literal>name</literal> (옵션, 이 접근법의 경우에는 필수임): 하나의 component + 식별자를 소유하는 컴포넌트 타입의 프로퍼티(9장을 보라). + </para> + </listitem> + <listitem> + <para> + <literal>access</literal> (옵션 - 디폴트는 <literal>property</literal>): + Hibernate가 프로퍼티 값에 접근하는데 사용할 방도. + </para> + </listitem> + <listitem> + <para> + <literal>class</literal> (옵션 - 디폴트는 reflection에 의해 결정된 프로퍼티 타입): + 하나의 composite 식별자로서 사용되는 컴포넌트 클래스(다음 절을 보라). + </para> + </listitem> + </itemizedlist> + + <para> + 이 세번째 접근법, <emphasis>identifier component</emphasis>은 거의 모든 어플리케이션들에 대해 우리가 권장하는 것이다. + </para> + </sect2> + + <sect2 id="mapping-declaration-discriminator" revision="3"> + <title>discriminator</title> + + <para> + <literal>&lt;discriminator&gt;</literal> 요소는 table-per-class-hierarchy(테이블 당 클래스 계층구조) + 매핑 방도를 사용하는 다형성 영속화에 필요하고 테이블의 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> + + <programlistingco> + <areaspec> + <area id="discriminator1" coords="2 60"/> + <area id="discriminator2" coords="3 60" /> + <area id="discriminator3" coords="4 60" /> + <area id="discriminator4" coords="5 60" /> + <area id="discriminator5" coords="6 60" /> + </areaspec> + <programlisting><![CDATA[<discriminator + column="discriminator_column" + type="discriminator_type" + force="true|false" + insert="true|false" + formula="arbitrary sql expression" +/>]]></programlisting> + <calloutlist> + <callout arearefs="discriminator1"> + <para> + <literal>column</literal> (옵션 - 디폴트는 <literal>class</literal>) + discriminator 컬럼명. + </para> + </callout> + <callout arearefs="discriminator2"> + <para> + <literal>type</literal> (옵션 - 디폴트는 <literal>string</literal>) + Hibernate 타입을 나타내는 이름 + </para> + </callout> + <callout arearefs="discriminator3"> + <para> + <literal>force</literal> (옵션 - 디폴트는 <literal>false</literal>) + 이것은 Hibernate로 하여금 루트 클래스의 모든 인스턴스들을 검색할 때조차도 허용된 discriminator + 값들을 지정하도록 "강제한다". + </para> + </callout> + <callout arearefs="discriminator4"> + <para> + <literal>insert</literal> (옵션 - 디폴트는 <literal>true</literal>) + 당신의 discriminator 컬럼이 또한 매핑된 composite 식별자의 부분일 경우에 이것을 <literal>false</literal>로 설정하라. + (Hibernate에게 SQL <literal>INSERT</literal>들 속에 그 컬럼을 포함하지 않도록 통보한다.) + </para> + </callout> + <callout arearefs="discriminator5"> + <para> + <literal>formula</literal> (옵션) + 타입이 평가 되어야 할 때 실행되는 임의의 SQL 표현식. 컨텐츠 기반의 판별을 허용해준다. + </para> + </callout> + </calloutlist> + </programlistingco> + + <para> + discriminator 컬럼의 실제 값들은 <literal>&lt;class&gt;</literal> 요소와 + <literal>&lt;subclass&gt;</literal> 요소의 <literal>discriminator-value</literal> 속성에 의해 지정된다. + </para> + + <para> + <literal>force</literal> 속성은 테이블이 영속 클래스로 매핑되지 않는 "특별한" discriminator 값들을 가진 행들을 + 포함할 경우에(만) 유용하다. 이것은 대개 그 경우가 아닐 것이다. + </para> + + <para> + <literal>formula</literal> 속성을 사용하여 당신은 행의 타입을 판단하는데 사용될 임의의 SQL 표현식을 선언할 수 있다: + </para> + + <programlisting><![CDATA[<discriminator + formula="case when CLASS_TYPE in ('a', 'b', 'c') then 0 else 1 end" + type="integer"/>]]></programlisting> + + </sect2> + + <sect2 id="mapping-declaration-version" revision="4"> + <title>version (옵션)</title> + + <para> + <literal>&lt;version&gt;</literal> 요소는 옵션이고 테이블이 버전화된 데이터를 포함한다는 것을 나타낸다. + 이것은 당신이 <emphasis>긴 트랜잭션(long transaction)들</emphasis>을 사용할 계획이라면 특히 유용하다 + (아래를 보라). + </para> + + <programlistingco> + <areaspec> + <area id="version1" coords="2 70"/> + <area id="version2" coords="3 70"/> + <area id="version3" coords="4 70"/> + <area id="version4" coords="5 70"/> + <area id="version5" coords="6 70"/> + <area id="version6" coords="7 70"/> + <area id="version7" coords="8 70"/> + </areaspec> + <programlisting><![CDATA[<version + column="version_column" + name="propertyName" + type="typename" + access="field|property|ClassName" + unsaved-value="null|negative|undefined" + generated="never|always" + insert="true|false" + node=&quot;element-name|@attribute-name|element/(a)attribute|.&quot; +/>]]></programlisting> + <calloutlist> + <callout arearefs="version1"> + <para> + <literal>column</literal> (옵션 - 디폴트는 프로퍼티 명): + 버전 번호를 가진 컬럼의 이름. + </para> + </callout> + <callout arearefs="version2"> + <para> + <literal>name</literal>: 영속 클래스의 프로퍼티 명. + </para> + </callout> + <callout arearefs="version3"> + <para> + <literal>type</literal> (옵션 - 디폴트는 <literal>integer</literal>): + 버전 번호의 타입. + </para> + </callout> + <callout arearefs="version4"> + <para> + <literal>access</literal> (옵션 - 디폴트는 <literal>property</literal>): + Hibernate가 프로퍼티 값에 액세스하는데 사용할 방도. + </para> + </callout> + <callout arearefs="version5"> + <para> + <literal>unsaved-value</literal> (옵션 - 디폴트는 <literal>undefined</literal>): + 이전 세션에서 저장되었거나 로드되었던 detached 인스턴스로부터 구별지어서, 인스턴스가 새로이 초기화됨(unsaved)을 + 나타내는 version 프로퍼티 값.(<literal>undefined</literal>는 식별자 프로퍼티 값이 사용될 것임을 지정한다.) + </para> + </callout> + <callout arearefs="version6"> + <para> + <literal>generated</literal> (옵션 - 디폴트는 <literal>never</literal>): + 이 version 프로퍼티 값이 데이터베이스에 의해 실제로 산출되는지를 지정한다. + <xref linkend="mapping-generated">산출되는 프로퍼티들</xref>에 관한 논의를 보라. + </para> + </callout> + <callout arearefs="version7"> + <para> + <literal>insert</literal> (옵션 - 디폴트는 <literal>true</literal>): + version 컬럼이 SQL insert 문장들 속에 포함될 것인지 여부를 지정한다. + 데이터베이스 컬럼이 디폴트 값 <literal>0</literal>으로 정의되는 경우에만 <literal>false</literal>로 + 설정될 수 있다. + </para> + </callout> + </calloutlist> + </programlistingco> + + <para> + 버전 번호들은 <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에 대한 임의의 문제들을 피하는 쉬운 방법이고, + assigned 식별자들이나 composite key들을 사용하는 사람들에게 특히 유용하다!</emphasis> + </para> + </sect2> + + <sect2 id="mapping-declaration-timestamp" revision="4" > + <title>timestamp (옵션)</title> + + <para> + 옵션 <literal>&lt;timestamp&gt;</literal> 요소는 테이블이 타임스탬프화 된 데이터를 포함함을 나타낸다. 이것은 + 버전화에 대한 대체물로서 고안되었다. Timestamp은 고유하게 optimistic 잠금에 대한 다소 안전한 구현이다. 하지만 때때로 + 어플리케이션은 다른 방법들로 timestamp들을 사용할 수도 있다. + </para> + + <programlistingco> + <areaspec> + <area id="timestamp1" coords="2 70"/> + <area id="timestamp2" coords="3 70" /> + <area id="timestamp3" coords="4 70" /> + <area id="timestamp4" coords="5 70" /> + <area id="timestamp5" coords="6 70" /> + <area id="timestamp6" coords="7 70" /> + </areaspec> + <programlisting><![CDATA[<timestamp + column="timestamp_column" + name="propertyName" + access="field|property|ClassName" + unsaved-value="null|undefined" + source="vm|db" + generated="never|always" + node=&quot;element-name|@attribute-name|element/(a)attribute|.&quot; +/>]]></programlisting> + <calloutlist> + <callout arearefs="timestamp1"> + <para> + <literal>column</literal> (옵션 - 디폴트는 프로퍼티 명): + 타임스탬프를 포함하는 컬럼 명. + </para> + </callout> + <callout arearefs="timestamp2"> + <para> + <literal>name</literal>: + 영속 클래스에 대해 자바 <literal>Date</literal> 또는 <literal>Timestamp</literal> 타입을 + 가진 자바빈즈 스타일의 프로퍼티 이름. + </para> + </callout> + <callout arearefs="timestamp3"> + <para> + <literal>access</literal> (옵션 - 디폴트는 <literal>property</literal>): + Hibernate가 프로퍼티 값에 접근하는데 사용할 방도. + </para> + </callout> + <callout arearefs="timestamp4"> + <para> + <literal>unsaved-value</literal> (옵션 - 디폴트는 <literal>null</literal>): + 이전 세션에서 저장되었거나 로드되었던 detached 인스턴스로부터 인스턴스를 구별지우는, 인스턴스가 새로이 + 초기화됨(unsaved)을 나타내는 version 프로퍼티 값.(<literal>undefined</literal>는 식별자 + 프로퍼티 값이 사용될 것임을 지정한다.) + </para> + </callout> + <callout arearefs="timestamp5"> + <para> + <literal>source</literal> (옵션 - 디폴트는 <literal>vm</literal>): + Hibernate는 어디서 timestamp 값을 검색할 것인가? 데이터베이스로부터인가 현재의 JVM으로부터인가? + 데이터베이스 기반의 timestamp들은 Hibernate가 "다음 값"을 결정하기 위해 데이터베이스에 접속해야 + 하기 때문에 오버헤드를 초래하지만, 클러스터링된 환경들에서의 용도로 보다 더 안전할 것이다. 또한 모든 + <literal>Dialect</literal>들이 데이터베이스의 현재의 timestamp에 대한 검색을 지원하는 것으로 알려져 + 있지 않지만, 다른 <literal>Dialect</literal>들은 정밀도 결핍 때문에 잠금에 있어 사용이 안전하지 않을 + 수 있음을 노트하라(예를 들면 오라클 8). + </para> + </callout> + <callout arearefs="timestamp6"> + <para> + <literal>generated</literal> (옵션 - 디폴트는 <literal>never</literal>): + 이 timestamp 프로퍼티 값이 데이터베이스에 의해 실제로 생성됨을 지정한다. + <xref linkend="mapping-generated">산출되는 프로퍼티들</xref>에 대한 논의들 보라. + </para> + </callout> + </calloutlist> + </programlistingco> + + <para> + <literal>&lt;timestamp&gt;</literal>는 <literal>&lt;version type="timestamp"&gt;</literal>과 + 같음을 노트하라. 그리고 <literal>&lt;timestamp use-db="true"&gt;</literal>는 + <literal>&lt;version type="dbtimestamp"&gt;</literal>과 같다 + </para> + </sect2> + + + <sect2 id="mapping-declaration-property" revision="4"> + <title>프로퍼티</title> + + <para> + <literal>&lt;property&gt;</literal> 요소는 클래스의 자바빈즈 스타일의 영속 프로퍼티를 선언한다. + </para> + + <programlistingco> + <areaspec> + <area id="property1" coords="2 70"/> + <area id="property2" coords="3 70"/> + <area id="property3" coords="4 70"/> + <areaset id="property4-5" coords=""> + <area id="property4" coords='5 70'/> + <area id="property5" coords='6 70'/> + </areaset> + <area id="property6" coords="7 70"/> + <area id="property7" coords="8 70"/> + <area id="property8" coords="9 70"/> + <area id="property9" coords="10 70"/> + <area id="property10" coords="11 70"/> + <area id="property11" coords="12 70"/> + <area id="property12" coords="13 70"/> + </areaspec> + <programlisting><![CDATA[<property + name="propertyName" + column="column_name" + type="typename" + update="true|false" + insert="true|false" + formula="arbitrary SQL expression" + access="field|property|ClassName" + lazy="true|false" + unique="true|false" + not-null="true|false" + optimistic-lock="true|false" + generated="never|insert|always" + node=&quot;element-name|@attribute-name|element/(a)attribute|.&quot; + index="index_name" + unique_key="unique_key_id" + length="L" + precision="P" + scale="S" +/>]]></programlisting> + <calloutlist> + <callout arearefs="property1"> + <para> + <literal>name</literal>: 첫 소문자로 시작하는 프로퍼티 이름. + </para> + </callout> + <callout arearefs="property2"> + <para> + <literal>column</literal> (옵션 - 디폴트는 프로퍼티 이름): + 매핑된 데이터베이스 테이블 컬럼의 이름. 이것은 또한 내부에 포함되는 <literal>&lt;column&gt;</literal> 요소(들)에 + 의해 지정될 수도 있다. + </para> + </callout> + <callout arearefs="property3"> + <para> + <literal>type</literal> (옵션): Hibernate 타입을 나타내는 이름. + </para> + </callout> + <callout arearefs="property4-5"> + <para> + <literal>update, insert</literal> (옵션 - 디폴트는 <literal>true</literal>) : + 매핑된 컬럼들이 <literal>UPDATE</literal>와/또는 <literal>INSERT</literal> 문장들속에 포함될 것임을 지정한다. + 둘다 <literal>false</literal>로 설정하는 것은 그 값이 동일한 컬럼(들)로 매핑되는 어떤 다른 프로퍼티로부터 또는 트리거에 + 의해 또는 다른 어플리케이션으로부터 초기화 되는 순수하게 "파생된(derived)" 프로퍼티를 허용해준다. + </para> + </callout> + <callout arearefs="property6"> + <para> + <literal>formula</literal> (옵션): + <emphasis>계산되는</emphasis> 프로퍼티에 대해 값을 정의하는 SQL 표현식. 계산되는 프로퍼티들은 + 그것들 자신에 대한 컬럼 매핑을 갖지 않는다. + </para> + </callout> + <callout arearefs="property7"> + <para> + <literal>access</literal> (옵션 - 디폴트는 <literal>property</literal>): + Hibernate가 프로퍼티 값에 접근하는데 사용할 방도. + </para> + </callout> + <callout arearefs="property8"> + <para> + <literal>lazy</literal> (옵션 - 디폴트는 <literal>false</literal>): + 인스턴스 변수가 처음으로 액세스 될 때 이 프로퍼티가 lazily하게 페치될 것임을 지정한다(빌드-시 바이트코드 + 수단을 필요로 한다). + </para> + </callout> + <callout arearefs="property9"> + <para> + <literal>unique</literal> (옵션): + 컬럼들에 대한 유일 컨스트레인트의 DDL 생성을 가능하게 만든다. 또한 이것이 <literal>property-ref</literal>의 + 타켓이 되는 것을 허용해준다. + </para> + </callout> + <callout arearefs="property10"> + <para> + <literal>not-null</literal> (옵션): + 컬럼들에 대해 null 가능 컨스트레인트의 DDL 생성을 가능하게 만든다. + </para> + </callout> + <callout arearefs="property11"> + <para> + <literal>optimistic-lock</literal> (옵션 - 디폴트는 <literal>true</literal>): + 이 프로퍼티에 대한 업데이트들이 optimistic 잠금을 획득하는 것을 필요로 하거나 필요로 하지 않음을 지정한다. + 달리말해, 이 프로퍼티가 dirty일 때 버전 증가가 발생할 경우인지를 결정한다. + </para> + </callout> + <callout arearefs="property12"> + <para> + <literal>generated</literal> (옵션 - 디폴트는 <literal>never</literal>): + 이 프로퍼티 값이 데이터베이스에 의해 실제로 산출되는지를 지정한다. + <xref linkend="mapping-generated">산출되는 프로퍼티들</xref>에 대한 논의를 보라. + </para> + </callout> + </calloutlist> + </programlistingco> + + <para> + <emphasis>typename</emphasis>은 다음일 수 있다: + </para> + + <orderedlist spacing="compact"> + <listitem> + <para> + Hibernate 기본 타입의 이름 (예를 들어. <literal>integer, string, character, date, timestamp, + float, binary, serializable, object, blob</literal>). + </para> + </listitem> + <listitem> + <para> + 디폴트 기본 타입을 가진 Java 클래스의 이름(예를 들어. <literal>int, float, + char, java.lang.String, java.util.Date, java.lang.Integer, java.sql.Clob</literal>). + </para> + </listitem> + <listitem> + <para> + serializable Java 클래스의 이름. + </para> + </listitem> + <listitem> + <para> + 맞춤 타입의 클래스 이름(예를 들어. <literal>com.illflow.type.MyCustomType</literal>). + </para> + </listitem> + </orderedlist> + + <para> + 만일 당신이 타입을 지정하지 않을 경우, Hibernate는 정확한 Hibernate 타입을 추정하기 위해 명명된 프로퍼티에 대해 + reflection을 사용할 것이다. Hibernate는 그 순서에서 2,3,4 규칙들을 사용하여 프로퍼티 getter의 반환 클래스의 + 이름을 해석하려고 시도할 것이다. 하지만 이것은 항상 충분하지는 않다. 어떤 경우들에서, 당신은 여전히 <literal>type</literal> + 속성을 필요로 할 것이다.(예를 들어, <literal>Hibernate.DATE</literal>와 <literal>Hibernate.TIMESTAMP</literal> + 사이를 구별하기 위해, 또는 맞춤 타입을 지정하기 위해.) + </para> + + <para> + <literal>access</literal> 속성은 당신으로 하여금 Hibernate가 런타임 시에 프로퍼티에 액세스하는 방법을 제어하도록 해준다. + 디폴트로 Hibernate는 프로퍼티 get/set 쌍을 호출할 것이다. 만일 당신이 <literal>access="field"</literal>를 지정할 + 경우, Hibernate는 get/set 쌍을 피하고 reflection을 사용하여 직접 필드에 액세스 할 것이다. 당신은 + <literal>org.hibernate.property.PropertyAccessor</literal> 인터페이스를 구현하는 클래스를 명명함으로써 + 프로퍼티 접근을 위한 당신 자신의 방도를 지정할 수도 있다. + </para> + + <para> + 특별히 강력한 특징은 파생된 플로퍼티들이다. 이들 프로퍼티들은 정의상 읽기 전용이고, 그 프로퍼티 값은 로드 시에 계산된다. 당신은 + 그 계산을 SQL 표현식으로 선언하고, 이것은 인스턴스를 로드시키는 SQL 질의 내의 <literal>SELECT</literal> 절 서브질의로 + 번역된다: + </para> + + <programlisting><![CDATA[ +<property name="totalPrice" + formula="( SELECT SUM (li.quantity*p.price) FROM LineItem li, Product p + WHERE li.productId = p.productId + AND li.customerId = customerId + AND li.orderNumber = orderNumber )"/>]]></programlisting> + + <para> + 당신은 특정 컬럼(주어진 예제에서는 <literal>customerId</literal>)에 대해 alias를 선언하지 않음으로써 엔티티들 자신의 + 테이블을 참조할 수 있음을 노트하라. 또한 당신은 만일 당신이 그 속성을 사용하고 싶지 않을 경우에 내포된 <literal>&lt;formula&gt;</literal> + 매핑 요소를 사용할 수 있음을 노트하라. + </para> + + </sect2> + + <sect2 id="mapping-declaration-manytoone" revision="5"> + <title>many-to-one</title> + + <para> + 또 다른 영속 클래스에 대한 정규 연관관계는 <literal>many-to-one</literal> 요소를 사용하여 선언된다. 관계형 모형은 + many-to-one 연관관계이다.: 하나의 테이블 내에 있는 foreign 키는 대상 테이블의 프라이머리 키 컬럼(들)을 참조하고 있다. + </para> + + <programlistingco> + <areaspec> + <area id="manytoone1" coords="2 70"/> + <area id="manytoone2" coords="3 70"/> + <area id="manytoone3" coords="4 70"/> + <area id="manytoone4" coords="5 70"/> + <area id="manytoone5" coords="6 70"/> + <areaset id="manytoone6-7" coords=""> + <area id="manytoone6" coords='7 70'/> + <area id="manytoone7" coords='8 70'/> + </areaset> + <area id="manytoone8" coords="9 70"/> + <area id="manytoone9" coords="10 70"/> + <area id="manytoone10" coords="11 70"/> + <area id="manytoone11" coords="12 70"/> + <area id="manytoone12" coords="13 70"/> + <area id="manytoone13" coords="14 70"/> + <area id="manytoone14" coords="15 70"/> + <area id="manytoone15" coords="16 70"/> + <area id="manytoone16" coords="17 70"/> + </areaspec> + <programlisting><![CDATA[<many-to-one + name="propertyName" + column="column_name" + class="ClassName" + cascade="cascade_style" + fetch="join|select" + update="true|false" + insert="true|false" + property-ref="propertyNameFromAssociatedClass" + access="field|property|ClassName" + unique="true|false" + not-null="true|false" + optimistic-lock="true|false" + lazy="proxy|no-proxy|false" + not-found="ignore|exception" + entity-name="EntityName" + formula="arbitrary SQL expression" + node=&quot;element-name|@attribute-name|element/(a)attribute|.&quot; + embed-xml="true|false" + index="index_name" + unique_key="unique_key_id" + foreign-key="foreign_key_name" +/>]]></programlisting> + <calloutlist> + <callout arearefs="manytoone1"> + <para> + <literal>name</literal>: 프로퍼티의 이름. + </para> + </callout> + <callout arearefs="manytoone2"> + <para> + <literal>column</literal> (옵션): + foreign key 컬럼의 이름. 이것은 또한 내포된 <literal>&lt;column&gt;</literal> 요소(들)에 의해 + 지정된다. + </para> + </callout> + <callout arearefs="manytoone3"> + <para> + <literal>class</literal> (옵션 - 디폴트는 reflection에 의해 결정된 프로퍼티 타입): + 연관된 클래스의 이름. + </para> + </callout> + <callout arearefs="manytoone4"> + <para> + <literal>cascade</literal> (옵션): + 어느 오퍼레이션들이 부모 객체로부터 연관된 객체로 케스케이드 될 것인지를 지정한다. + </para> + </callout> + <callout arearefs="manytoone5"> + <para> + <literal>fetch</literal> (옵션 - 디폴트는 <literal>select</literal>): + outer-join 페칭 또는 sequential select 페칭 사이에서 선택하라. + </para> + </callout> + <callout arearefs="manytoone6-7"> + <para> + <literal>update, insert</literal> (옵션 - 디폴트는 <literal>true</literal>) + 매핑된 컬럼들이 SQL <literal>UPDATE</literal>와/또는 <literal>INSERT</literal> 문장들 속에 포함될 것인지를 지정한다. + 둘다 <literal>false</literal>로 설정하는 것은 그 값이 동일한 컬럼(들)로 매핑시키는 어떤 다른 컬럼들로부터 초기화 되거나 트리거나 + 다른 어플리케이션에 의해 초기화되는 단순한 "파생된" 연관관계 값을 허용한다. + </para> + </callout> + <callout arearefs="manytoone8"> + <para> + <literal>property-ref</literal>: (옵션) 이 foreign key에 조인되는 연관된 클래스의 프로퍼티 이름. 지정되지 않을 경우, + 연관 클래스의 프라이머리 키가 사용된다. + </para> + </callout> + <callout arearefs="manytoone9"> + <para> + <literal>access</literal> (옵션 - 디폴트는 <literal>property</literal>): + Hibernate가 프로퍼티 값에 접근하는데 사용할 방도. + </para> + </callout> + <callout arearefs="manytoone10"> + <para> + <literal>unique</literal> (옵션): + foreign-key 컬럼을 위한 유일 컨스트레인트의 DDL 생성을 가능하도록 해준다. 또한 이것이 property-ref의 대상이 되는 것을 허용해준다. + 이것은 연관 다중성(association multiplicity)을 효율적으로 일 대 일로 만든다. + </para> + </callout> + <callout arearefs="manytoone11"> + <para> + <literal>not-null</literal> (옵션): + foreign key 컬럼들을 위한 null 가능한 컨스트레인트의 DDL 생성을 가능하도록 해준다. + </para> + </callout> + <callout arearefs="manytoone12"> + <para> + <literal>optimistic-lock</literal> (옵션 - 디폴트는 <literal>true</literal>): + 이 프로퍼티에 대한 업데이트들이 optimistic lock의 획득을 필요로 하는지 아닌지 여부를 지정한다. + 달리 말해 이 프로퍼티가 dirty일 때 version 증가가 발생해야 할 경우인지를 결정한다. + </para> + </callout> + <callout arearefs="manytoone13"> + <para> + <literal>lazy</literal> (옵션 - 디폴트는 <literal>proxy</literal>): + 디폴트로, 단일 포인트 연관들이 프락시된다. <literal>lazy="no-proxy"</literal>는 인스턴스 변수가 처음으로 접근될 때 + 그 프로퍼티가 lazily 페치될 것임을 지정한다(빌드-시 바이트코드 수단을 필요로 한다). <literal>lazy="false"</literal>는 + 그 연관이 항상 eagerly 페치될 것임을 지정한다. + </para> + </callout> + <callout arearefs="manytoone14"> + <para> + <literal>not-found</literal> (옵션 - 디폴트는 <literal>exception</literal>): + 누락된 행들을 참조하는 foreign key들이 어떻게 처리될 것인지를 지정한다: <literal>ignore</literal>는 한 개의 누락된 행을 + 한 개의 null 연관으로 취급할 것이다. + </para> + </callout> + <callout arearefs="manytoone15"> + <para> + <literal>entity-name</literal> (옵션): 연관된 클래스의 엔티티 이름. + </para> + </callout> + </calloutlist> + <callout arearefs="manytoone16"> + <para> + <literal>formula</literal> (옵션): <emphasis>계산된</emphasis> foreign key에 대한 값을 정의하는 SQL 표현식. + </para> + </callout> + </programlistingco> + + <para> + <literal>cascade</literal> 속성 값을 <literal>none</literal> 아닌 어떤 의미있는 다른 값으로 설정하는 것은 + 어떤 오퍼레이션들을 연관된 객체에게 보급할 것이다. 유의미한 값들은 Hibernate의 기본 오퍼레이션들의 이름들, + 즉 <literal>persist, merge, delete, save-update, evict, replicate, lock, refresh</literal> + 뿐만 아니라 특별한 값들, 즉 <literal>delete-orphan</literal>과 <literal>all</literal> 그리고 오퍼레이션 이름들의 + 쉼표 분리된 조합들, 예를 들면 <literal>cascade="persist,merge,evict"</literal> 또는 + <literal>cascade="all,delete-orphan"</literal>이다. 전체 설명은 + <xref linkend="objectstate-transitive"/>를 보라. 단일값 연관들(many-to-one 연관과 + one-to-one 연관)은 orphan delete를 지원하지 않음을 노트하라. + </para> + + <para> + 일반적인 <literal>many-to-one</literal> 선언은 다음과 같이 간단하게 보여진다: + </para> + + <programlisting><![CDATA[<many-to-one name="product" class="Product" column="PRODUCT_ID"/>]]></programlisting> + + <para> + <literal>property-ref</literal> 속성은 오직 foreign key가 프라이머리 키가 아닌 연관된 테이블의 유일 키를 참조하는 + 리거시 데이터를 매핑하는데만 사용된다. 이것은 꼴사나운 관계형 모형이다. 예를 들어, <literal>Product</literal> + 클래스가 프라이머리 키를 아닌, 유일한 시리얼 번호를 갖는다고 가정하자.(<literal>unique</literal> 속성은 + SchemaExport 도구로 Hibernate의 DDL 생성을 제어한다.) + </para> + + <programlisting><![CDATA[<property name="serialNumber" unique="true" type="string" column="SERIAL_NUMBER"/>]]></programlisting> + + <para> + 그런 다음 <literal>OrderItem</literal>에 대한 매핑은 다음을 사용할 것이다: + </para> + + <programlisting><![CDATA[<many-to-one name="product" property-ref="serialNumber" column="PRODUCT_SERIAL_NUMBER"/>]]></programlisting> + + <para> + 하지만 이것은 확실히 권장되지 않는다. + </para> + + <para> + 만일 참조된 유일 키가 연관된 엔티티의 여러 프로퍼티들을 포함할 경우, 당신은 명명된 <literal>&lt;properties&gt;</literal> + 요소 내부에 참조된 프로퍼티들을 매핑할 것이다. + </para> + + <para> + 만일 참조된 유일키가 컴포넌트의 프로퍼티일 경우, 당신은 하나의 프로퍼티 경로를 지정할 수 있다: + </para> + + <programlisting><![CDATA[<many-to-one name="owner" property-ref="identity.ssn" column="OWNER_SSN"/>]]></programlisting> + + </sect2> + + <sect2 id="mapping-declaration-onetoone" revision="3"> + <title>one-to-one</title> + + <para> + 또 다른 영속 클래스에 대한 one-to-one 연관관계는 <literal>one-to-one</literal> 요소를 사용하여 선언된다. + </para> + + <programlistingco> + <areaspec> + <area id="onetoone1" coords="2 70"/> + <area id="onetoone2" coords="3 70"/> + <area id="onetoone3" coords="4 70"/> + <area id="onetoone4" coords="5 70"/> + <area id="onetoone5" coords="6 70"/> + <area id="onetoone6" coords="7 70"/> + <area id="onetoone7" coords="8 70"/> + <area id="onetoone8" coords="9 70"/> + <area id="onetoone9" coords="10 70"/> + <area id="onetoone10" coords="11 70"/> + </areaspec> + <programlisting><![CDATA[<one-to-one + name="propertyName" + class="ClassName" + cascade="cascade_style" + constrained="true|false" + fetch="join|select" + property-ref="propertyNameFromAssociatedClass" + access="field|property|ClassName" + formula="any SQL expression" + lazy="proxy|no-proxy|false" + entity-name="EntityName" + node=&quot;element-name|@attribute-name|element/(a)attribute|.&quot; + embed-xml="true|false" + foreign-key="foreign_key_name" +/>]]></programlisting> + <calloutlist> + <callout arearefs="onetoone1"> + <para> + <literal>name</literal>: 프로퍼티의 이름. + </para> + </callout> + <callout arearefs="onetoone2"> + <para> + <literal>class</literal> (옵션 - 디폴트는 reflection에 의해 결정된 프로퍼티 타입): + 연관된 클래스의 이름. + </para> + </callout> + <callout arearefs="onetoone3"> + <para> + <literal>cascade</literal> (옵션) 어느 오퍼레이션들이 부모 객체로부터 연관된 객체로 + 케스케이드 될 것인지를 지정한다. + </para> + </callout> + <callout arearefs="onetoone4"> + <para> + <literal>constrained</literal> (옵션) 매핑된 테이블의 프라이머리 키에 대한 foreign 키 + 컨스트레인트가 연관된 클래스의 테이블을 참조하는지 여부를 지정한다. 이 옵션은 <literal>save()</literal>와 + <literal>delete()</literal>가 케스케이드 되는 순서에 영향을 주고, 그 연관이 프락시 될 것인지 여부를 결정한다 + (또한 스키마 내보내기 도구에 의해 사용된다). + </para> + </callout> + <callout arearefs="onetoone5"> + <para> + <literal>fetch</literal> (옵션 - 디폴트는 <literal>select</literal>): + outer-join 페칭 또는 순차적인 select 페칭 중에서 선택하라. + </para> + </callout> + <callout arearefs="onetoone6"> + <para> + <literal>property-ref</literal>: (옵션) 이 클래스의 프라이머리 키에 연결된 연관 클래스의 프로퍼티의 이름. + 만일 지정되지 않을 경우, 연관 클래스의 프라이머리 키가 사용된다. + </para> + </callout> + <callout arearefs="onetoone7"> + <para> + <literal>access</literal> (옵션 - 디폴트는 <literal>property</literal>): + Hibernate가 프로퍼티 값에 접근 하는데 사용할 방도. + </para> + </callout> + <callout arearefs="onetoone8"> + <para> + <literal>formula</literal> (옵션): + 거의 모든 one to one 연관관계들은 소유하는 엔티티의 프라이머리 키로 매핑된다. 이것이 그 경우가 아닌 드문 경우들에서, + 당신은 SQL formula 사용에 결합시킬 몇몇 다른 컬럼, 컬럼들, 또는 표현식을 지정할 수 있다.(예제는 + <literal>org.hibernate.test.onetooneformula</literal>를 보라.) + </para> + </callout> + <callout arearefs="onetoone9"> + <para> + <literal>lazy</literal> (옵션 - 디폴트는 <literal>proxy</literal>): + 디폴트로 한쪽 끝 연관들이 프락시 된다. <literal>lazy="no-proxy"</literal>는 인스턴스 변수가 처음 접근될 때 + 그 프로퍼티가 lazily 페치될 것임을 지정한다(빌드-시 바이트코드 수단을 필요로 한다). + <literal>lazy="false"</literal>는 그 연관들이 항상 eagerly 페치될 것임을 지정한다. <emphasis>만일 + <literal>constrained="false"</literal>인 경우에, 프락싱은 불가능하고 Hibernate는 그 연관을 eager 페치시킬 것이다!</emphasis> + </para> + </callout> + <callout arearefs="onetoone10"> + <para> + <literal>entity-name</literal> (옵션): 연관된 클래스의 엔티티 이름. + </para> + </callout> + </calloutlist> + </programlistingco> + + <para> + one-to-one 연관관계에는 두 가지 변종이 존재한다: + </para> + <itemizedlist> + <listitem><para> + 프라이머리 키 연관관계들 + </para></listitem> + <listitem><para> + 유일 foreign 키 연관관계들 + </para></listitem> + </itemizedlist> + + <para> + 프라이머리 키 연관들은 특별한 테이블 컬럼을 필요로 하지 않는다; 만일 두 개의 행들이 그 연관에 의해 관계지워지면, + 두 개의 테이블 행들은 동일한 프라이머리 키 값을 공유한다. 따라서 만일 두 개의 객체들이 프라이머리 키 연관에 의해 + 관계지워지도록 당신이 원할 경우, 당신은 그것들에 동일한 식별자 값이 할당되도록 해야 한다! + </para> + + <para> + 프라이머리 키 연관에 대해, 다음 매핑들을 <literal>Employee</literal>와 <literal>Person</literal> 각각에 추가하라. + </para> + + <programlisting><![CDATA[<one-to-one name="person" class="Person"/>]]></programlisting> + <programlisting><![CDATA[<one-to-one name="employee" class="Employee" constrained="true"/>]]></programlisting> + + <para> + 이제 우리는 PERSON 과 EMPLOYEE 테이블들에서 관계지워진 행들의 프라이머리 키들이 동일함을 확실히 해야 한다! 우리는 + <literal>foreign</literal>로 명명되는 특별한 Hibernate 식별자 생성 방도를 사용한다: + </para> + + <programlisting><![CDATA[<class name="person" table="PERSON"> + <id name="id" column="PERSON_ID"> + <generator class="foreign"> + <param name="property">employee</param> + </generator> + </id> + ... + <one-to-one name="employee" + class="Employee" + constrained="true"/> +</class>]]></programlisting> + + <para> + 그때 <literal>Person</literal>의 새로이 저장된 인스턴스는 그 <literal>Person</literal>의 + <literal>employee</literal> 프로퍼티에 대해 참조된 <literal>Employee</literal> 인스턴스와 동일한 + 프라이머리 키를 할당받는다. + </para> + + <para> + 달리, <literal>Employee</literal>로부터 <literal>Person</literal>으로의 유일 컨스트레인트를 가진 + 하나의 foreign key는 다음과 같이 표현될 수 있다: + </para> + + <programlisting><![CDATA[<many-to-one name="person" class="Person" column="PERSON_ID" unique="true"/>]]></programlisting> + + <para> + 그리고 이 연관은 다음을 <literal>Person</literal> 매핑에 추가함으로써 양방향이 될 수 있다: + </para> + + <programlisting><![CDATA[<one-to-one name="employee" class="Employee" property-ref="person"/>]]></programlisting> + + </sect2> + + <sect2 id="mapping-declaration-naturalid"> + <title>natural-id</title> + + <programlisting><![CDATA[<natural-id mutable="true|false"/> + <property ... /> + <many-to-one ... /> + ...... +</natural-id>]]></programlisting> + + <para> + 비록 우리가 프라이머리 키들로서 대용키들을 사용하는 것을 권장했을지라도, 당신은 여전히 모든 엔티티들에 대한 natural + 키들을 식별하고자 원할 것이다. narutal 키는 유일(unique)하고 null이 아닌 프로퍼티 또는 프로퍼티들의 조합이다. + 그것이 또한 불변하는 것일 경우가 더 좋다. <literal>&lt;natural-id&gt;</literal> 요소 내부에 있는 natural 키의 + 프로퍼티들을 매핑하라. Hibernate는 필수적인 유일 키와 null 허용가능한 컨스트레인트들을 생성시킬 것이고, 당신의 + 매핑은 보다 자가 설명적이게 될 것이다. + </para> + + <para> + 우리는 당신이 엔티티에 대한 narutal 키 프로퍼티들을 비교하는데 <literal>equals()</literal>와 + <literal>hashCode()</literal>를 구현할 것을 강력하게 권장한다. + </para> + + <para> + 이 매핑은 natural 프라이머리 키들을 가진 엔티티들을 위한 용도로 고안된 것은 아니다. + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + <literal>mutable</literal> (옵션, 디폴트는 <literal>false</literal>): + 디폴트로, narutal 식별자 프로퍼티들은 변경될 수 없는 것(상수)으로 가정된다. + </para> + </listitem> + </itemizedlist> + + </sect2> + + <sect2 id="mapping-declaration-component" revision="2"> + <title>component, dynamic-component</title> + + <para> + <literal>&lt;component&gt;</literal> 요소는 자식 객체의 프로퍼티들을 부모 클래스에 대한 테이블의 컬럼들로 매핑시킨다. + 컴포넌트들은 그것들 자신의 프로퍼티들, 컴포넌트들, 또는 콜렉션들을 선언한다. 이래 "컴포넌트들"을 보라. + </para> + + <programlistingco> + <areaspec> + <area id="component1" coords="2 45"/> + <area id="component2" coords="3 45"/> + <area id="component3" coords="4 45"/> + <area id="component4" coords="5 45"/> + <area id="component5" coords="6 45"/> + <area id="component6" coords="7 45"/> + <area id="component7" coords="8 45"/> + <area id="component8" coords="9 45"/> + </areaspec> + <programlisting><![CDATA[<component + name="propertyName" + class="className" + insert="true|false" + update="true|false" + access="field|property|ClassName" + lazy="true|false" + optimistic-lock="true|false" + unique="true|false" + node="element-name|." +> + + <property ...../> + <many-to-one .... /> + ........ +</component>]]></programlisting> + <calloutlist> + <callout arearefs="component1"> + <para> + <literal>name</literal>: 프로퍼티의 이름. + </para> + </callout> + <callout arearefs="component2"> + <para> + <literal>class</literal> (옵션 - 디폴트는 reflection에 의해 결정된 프로퍼티 타입): + 컴포넌트(자식) 클래스의 이름. + </para> + </callout> + <callout arearefs="component3"> + <para> + <literal>insert</literal>: 매핑된 컬럼들이 SQL <literal>INSERT</literal>들 속에 + 나타나야 하는가? + </para> + </callout> + <callout arearefs="component4"> + <para> + <literal>update</literal>: 매핑된 컬럼들이 SQL <literal>UPDATE</literal>들 속에 + 나타나야 하는가? + </para> + </callout> + <callout arearefs="component5"> + <para> + <literal>access</literal> (옵션 - 디폴트는 <literal>property</literal>): + Hibernate가 프로퍼티 값에 액세스하는데 사용할 방도. + </para> + </callout> + <callout arearefs="component6"> + <para> + <literal>lazy</literal> (옵션 - 디폴트는 <literal>false</literal>): + 인스턴스 변수가 처음으로 액세스될 때 이 컴포넌트가 lazily(느리게) 페치되어야 하는지 여부를 지정한다 + (빌드 시 바이트코드 수단을 필요로 한다). + </para> + </callout> + <callout arearefs="component7"> + <para> + <literal>optimistic-lock</literal> (옵션 - 디폴트는 <literal>true</literal>): + 이 컴포넌트에 대한 업데이트들이 optimistic 잠금을 획득하는 것을 필요로 하는지 여부를 지정한다. + 달리 말해 이 프로퍼티가 dirty 일 때 버전 증가가 발생할 것인지 여부를 결정한다. + </para> + </callout> + <callout arearefs="component8"> + <para> + <literal>unique</literal> (옵션 - 디폴트는 <literal>false</literal>): + 유일 컨스트레인트가 컴포넌트의 모든 매핑된 컬럼들에 대해 존재하는지 여부를 지정한다. + </para> + </callout> + </calloutlist> + </programlistingco> + + <para> + 자식 <literal>&lt;property&gt;</literal> 태그들은 자식 클래스의 프로퍼티들을 테이블 컬럼들로 매핑시킨다. + </para> + + <para> + <literal>&lt;component&gt;</literal> 요소는 컴포넌트 클래스의 프로퍼티를 포함하는 엔티티에 대한 참조로서 매핑시키는 + <literal>&lt;parent&gt;</literal> 서브요소를 허용한다. + </para> + + <para> + <literal>&lt;dynamic-component&gt;</literal> 요소는 컴포넌트로서 매핑될<literal>Map</literal>을 허용한다. + 여기서 프로퍼티 이름들은 map의 키들을 참조한다. <xref linkend="components-dynamic"/>을 보라. + </para> + + </sect2> + + <sect2 id="mapping-declaration-properties" revision="2"> + <title>properties</title> + + <para> + <literal>&lt;properties&gt;</literal> 요소는 클래스의 프로퍼티들의 명명된, 논리적 그룹핑에 대한 정의를 허용한다. + 그 구조에 대한 가장 중요한 사용은 그것이 프로퍼티들의 조합이 <literal>property-ref</literal>의 대상이 되는 것을 + 허용해준다는 점이다. 또한 그것은 다중 컬럼 유일 컨스트레인느를 정의하는 편리한 방법이다. + </para> + + <programlistingco> + <areaspec> + <area id="properties1" coords="2 45"/> + <area id="properties2" coords="3 45"/> + <area id="properties3" coords="4 45"/> + <area id="properties4" coords="5 45"/> + <area id="properties5" coords="6 45"/> + </areaspec> + <programlisting><![CDATA[<properties + name="logicalName" + insert="true|false" + update="true|false" + optimistic-lock="true|false" + unique="true|false" +> + + <property ...../> + <many-to-one .... /> + ........ +</properties>]]></programlisting> + <calloutlist> + <callout arearefs="properties1"> + <para> + <literal>name</literal>: 그룹핑의 논리적 이름 - 실제 프로퍼티 이름이 <emphasis>아니다</emphasis>. + </para> + </callout> + <callout arearefs="properties2"> + <para> + <literal>insert</literal>: 매핑된 컬럼들이 SQL <literal>INSERT</literal>들 내에 나타날 것인가? + </para> + </callout> + <callout arearefs="properties3"> + <para> + <literal>update</literal>: 매핑된 컬럼들이 SQL <literal>UPDATE</literal>들 내에 나타날 것인가? + </para> + </callout> + <callout arearefs="properties4"> + <para> + <literal>optimistic-lock</literal> (옵션 - 디폴트는 <literal>true</literal>): + 이들 프로퍼티들에 대한 업데이트들이 optimistic 잠금의 획득을 필요로 하는지 여부를 지정한다. 달리 말해 + 이 프로퍼티가 dirty 일 때 버전 증가가 발생할 것인지 여부를 결정한다. + </para> + </callout> + <callout arearefs="properties5"> + <para> + <literal>unique</literal> (옵션 - 디폴트는 <literal>false</literal>): + 유일 컨스트레인트가 컴포넌트의 모든 매핑된 컬럼들에 대해 존재하는지 여부를 지정한다. + </para> + </callout> + </calloutlist> + </programlistingco> + + <para> + 예를 들어, 만일 우리가 다음 <literal>&lt;properties&gt;</literal> 매핑을 가질 경우: + </para> + + <programlisting><![CDATA[<class name="Person"> + <id name="personNumber"/> + ... + <properties name="name" + unique="true" update="false"> + <property name="firstName"/> + <property name="initial"/> + <property name="lastName"/> + </properties> +</class>]]></programlisting> + + <para> + 그 때 우리는 프라이머리 키가 아닌, <literal>Person</literal> 테이블의 이 유일 키를 참조하는 어떤 리거시 데이터 연관을 + 가질 수 있다: + </para> + + <programlisting><![CDATA[<many-to-one name="person" + class="Person" property-ref="name"> + <column name="firstName"/> + <column name="initial"/> + <column name="lastName"/> +</many-to-one>]]></programlisting> + + <para> + 우리는 리거시 데이터를 매핑시키는 컨텍스트 바깥에서 이런 종류의 것을 사용하는 것을 권장하지 않는다. + </para> + + </sect2> + + <sect2 id="mapping-declaration-subclass" revision="4"> + <title>subclass</title> + + <para> + 마지막으로, 다형성 영속성은 루트 영속 클래스에 대한 각각의 서브클래스 선언을 필요로 한다.(권장되는) + table-per-class-hierarchy(테이블 당 클래스 계층구조) 매핑 방도의 경우, <literal>&lt;subclass&gt;</literal> + 선언이 사용된다. + </para> + + <programlistingco> + <areaspec> + <area id="subclass1" coords="2 55"/> + <area id="subclass2" coords="3 55"/> + <area id="subclass3" coords="4 55"/> + <area id="subclass4" coords="5 55"/> + </areaspec> + <programlisting><![CDATA[<subclass + name="ClassName" + discriminator-value="discriminator_value" + proxy="ProxyInterface" + lazy="true|false" + dynamic-update="true|false" + dynamic-insert="true|false" + entity-name="EntityName" + node="element-name" + extends="SuperclassName"> + + <property .... /> + ..... +</subclass>]]></programlisting> + <calloutlist> + <callout arearefs="subclass1"> + <para> + <literal>name</literal>: 서브클래스의 전체 수식어가 붙은 클래스 이름. + </para> + </callout> + <callout arearefs="subclass2"> + <para> + <literal>discriminator-value</literal> (옵션 - 디폴트는 클래스 이름): + 개개의 서브클래스들을 구분짓는 값. + </para> + </callout> + <callout arearefs="subclass3"> + <para> + <literal>proxy</literal> (옵션): lazy 초기화 프락시들을 사용하는데 클래스 또는 인터페이스를 지정한다. + </para> + </callout> + <callout arearefs="subclass4"> + <para> + <literal>lazy</literal> (옵션 - 디폴트는 <literal>true</literal>): + <literal>lazy="false"</literal> 설정은 lazy 페칭의 사용을 불가능하게 만든다. + </para> + </callout> + </calloutlist> + </programlistingco> + + <para> + 각각의 서브클래스는 그것 자신의 영속 프로퍼티들과 서브클래스들을 선언할 것이다. <literal>&lt;version&gt;</literal> + 프로퍼티와 <literal>&lt;id&gt;</literal> 프로퍼티는 루트 클래스로부터 상속된다고 가정된다. 계층구조 내에서 각각의 + 서브클래스는 유일한 <literal>discriminator-value</literal>를 정의해야 한다. none이 지정될 경우, 전체 수식어가 + 붙은 자바 클래스 이름이 사용된다. + </para> + + <para> + 상속 매핑들에 대한 정보는 <xref linkend="inheritance"/>을 보라. + </para> + + </sect2> + + <sect2 id="mapping-declaration-joinedsubclass" revision="3"> + <title>joined-subclass</title> + + <para> + 다른 방법으로 각각의 서브클래스는 그것 자신이 테이블로 매핑될 수 있다(table-per-subclass 매핑 방도). 상속된 상태는 + 슈퍼클래스의 테이블과 조인함으로써 검색된다. 우리는 <literal>&lt;joined-subclass&gt;</literal> 요소를 사용한다. + </para> + + <programlistingco> + <areaspec> + <area id="joinedsubclass1" coords="2 45"/> + <area id="joinedsubclass2" coords="3 45"/> + <area id="joinedsubclass3" coords="4 45"/> + <area id="joinedsubclass4" coords="5 45"/> + </areaspec> + <programlisting><![CDATA[<joined-subclass + name="ClassName" + table="tablename" + proxy="ProxyInterface" + lazy="true|false" + dynamic-update="true|false" + dynamic-insert="true|false" + schema="schema" + catalog="catalog" + extends="SuperclassName" + persister="ClassName" + subselect="SQL expression" + entity-name="EntityName" + node="element-name"> + + <key .... > + + <property .... /> + ..... +</joined-subclass>]]></programlisting> + <calloutlist> + <callout arearefs="joinedsubclass1"> + <para> + <literal>name</literal>: 서브클래스의 전체 수식어가 붙은 클래스 명. + </para> + </callout> + <callout arearefs="joinedsubclass2"> + <para> + <literal>table</literal>: 서브클래스 테이블의 이름. + </para> + </callout> + <callout arearefs="joinedsubclass3"> + <para> + <literal>proxy</literal> (옵션): 프락시들을 lazy 초기화 시키는데 사용할 클래스 또는 인터페이스를 지정한다. + </para> + </callout> + <callout arearefs="joinedsubclass4"> + <para> + <literal>lazy</literal> (옵션 - 디폴트는 <literal>true</literal>): + <literal>lazy="false"</literal> 설정은 lazy 페칭을 사용불가능하게 만든다 + </para> + </callout> + </calloutlist> + </programlistingco> + + <para> + 판별자(discriminator) 컬럼은 이 매핑 방도에 필요하지 않다. 하지만 각각의 서브클래스는 <literal>&lt;key&gt;</literal> 요소를 + 사용하여 객체 식별자를 보관하는 테이블 컬럼을 선언해야 한다. 이 장의 시작 부분에 있는 매핑은 다음과 같이 다시 작성될 것이다: + </para> + + <programlisting><![CDATA[<?xml version="1.0"?> +<!DOCTYPE hibernate-mapping PUBLIC + "-//Hibernate/Hibernate Mapping DTD//EN" + "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> + +<hibernate-mapping package="eg"> + + <class name="Cat" table="CATS"> + <id name="id" column="uid" type="long"> + <generator class="hilo"/> + </id> + <property name="birthdate" type="date"/> + <property name="color" not-null="true"/> + <property name="sex" not-null="true"/> + <property name="weight"/> + <many-to-one name="mate"/> + <set name="kittens"> + <key column="MOTHER"/> + <one-to-many class="Cat"/> + </set> + <joined-subclass name="DomesticCat" table="DOMESTIC_CATS"> + <key column="CAT"/> + <property name="name" type="string"/> + </joined-subclass> + </class> + + <class name="eg.Dog"> + <!-- mapping for Dog could go here --> + </class> + +</hibernate-mapping>]]></programlisting> + + <para> + 상속 매핑들에 대한 정보는 <xref linkend="inheritance"/>을 보라. + </para> + + </sect2> + + <sect2 id="mapping-declaration-unionsubclass" revision="2"> + <title>union-subclass</title> + + <para> + 제3의 옵션은 상속 계층구조의 concrete 클래스들 만을 테이블들로 매핑하는 것이다 (table-per-concrete-class 방도). 여기서 + 각각의 테이블은 상속된 상태를 포함하여 클래스의 모든 영속 상태를 정의한다. Hibernate에서, 그것은 그런 상속 계층구조들을 + 명시적으로 매핑하는데 필수적이지 않다. 당신은 별도의 <literal>&lt;class&gt;</literal> 선언을 가진 각각의 클래스를 + 간단히 매핑시킬 수 있다. 하지만 당신이 다형성 연관관계들(예를 들면 당신의 계층구조의 슈퍼클래스에 대한 연관)을 사용하고자 원할 + 경우, 당신은 <literal>&lt;union-subclass&gt;</literal> 매핑을 사용할 필요가 있다. + </para> + + <programlistingco> + <areaspec> + <area id="unionsubclass1" coords="2 45"/> + <area id="unionsubclass2" coords="3 45"/> + <area id="unionsubclass3" coords="4 45"/> + <area id="unionsubclass4" coords="5 45"/> + </areaspec> + <programlisting><![CDATA[<union-subclass + name="ClassName" + table="tablename" + proxy="ProxyInterface" + lazy="true|false" + dynamic-update="true|false" + dynamic-insert="true|false" + schema="schema" + catalog="catalog" + extends="SuperclassName" + abstract="true|false" + persister="ClassName" + subselect="SQL expression" + entity-name="EntityName" + node="element-name"> + + <property .... /> + ..... +</union-subclass>]]></programlisting> + <calloutlist> + <callout arearefs="unionsubclass1"> + <para> + <literal>name</literal>: 서브클래스의 전체 수식어가 붙은 클래스 명. + </para> + </callout> + <callout arearefs="unionsubclass2"> + <para> + <literal>table</literal>: 서브클래스 테이블의 이름. + </para> + </callout> + <callout arearefs="unionsubclass3"> + <para> + <literal>proxy</literal> (옵션): 프락시들을 lazy 초기화 시키는데 사용할 클래스 또는 인터페이스를 지정한다. + </para> + </callout> + <callout arearefs="unionsubclass4"> + <para> + <literal>lazy</literal> (옵션 - 디폴트는 <literal>true</literal>): + <literal>lazy="false"</literal> 설정은 lazy 페칭을 사용불가능하게 만든다. + </para> + </callout> + </calloutlist> + </programlistingco> + + <para> + 이 매핑 방도에는 판별자 컬럼이나 키 컬럼이 필요하지 않다. + </para> + + <para> + 상속 매핑들에 대한 정보는 <xref linkend="inheritance"/>을 보라. + </para> + + </sect2> + + <sect2 id="mapping-declaration-join" revision="3"> + <title>join</title> + + <para> + <literal>&lt;join&gt;</literal>요소를 사용하면, 테이블들 사이에 1대일 관계가 존재할 때, + 하나의 클래스에 속한 프로퍼티들을 여러 테이블들로 매핑시키는 것이 + 가능하다. + </para> + + <programlistingco> + <areaspec> + <area id="join1" coords="2 50"/> + <area id="join2" coords="3 50"/> + <area id="join3" coords="4 50"/> + <area id="join4" coords="5 50"/> + <area id="join5" coords="6 50"/> + <area id="join6" coords="7 50"/> + </areaspec> + <programlisting><![CDATA[<join + table="tablename" + schema="owner" + catalog="catalog" + fetch="join|select" + inverse="true|false" + optional="true|false"> + + <key ... /> + + <property ... /> + ... +</join>]]></programlisting> + + <calloutlist> + <callout arearefs="join1"> + <para> + <literal>table</literal>: 조인된 테이블의 이름. + </para> + </callout> + <callout arearefs="join2"> + <para> + <literal>schema</literal> (옵션): 루트 <literal>&lt;hibernate-mapping&gt;</literal> 요소에 + 의해 지정된 스키마 이름을 오버라이드 시킨다 + </para> + </callout> + <callout arearefs="join3"> + <para> + <literal>catalog</literal> (옵션): 루트 <literal>&lt;hibernate-mapping&gt;</literal> 요소에 + 의해 지정된 카타록 이름을 오버라이드 시킨다. + </para> + </callout> + <callout arearefs="join4"> + <para> + <literal>fetch</literal> (옵션 - 디폴트는 <literal>join</literal>): + <literal>join</literal>으로 설정될 경우, 디폴트로 Hibernate는 하나의 클래스 또는 그것의 슈퍼 클래스들에 의해 + 정의된 <literal>&lt;join&gt;</literal>을 검색하는데 inner join을 사용하고 서브클래스에 의해 정의된 + <literal>&lt;join&gt;</literal>을 검색하는데 outer join을 사용할 것이다. 만일 <literal>select</literal>로 + 설정할 경우, Hibernate는 서브클래스 상에 정의된 <literal>&lt;join&gt;</literal>에 대해 sequential + select를 사용할 것이고, 그것은 한 행이 서브클래스의 인스턴스를 표현하는 것으로 판명되는 경우에만 명령이 내려질 것이다. + inner join들은 여전히 클래스와 그것의 슈퍼클래스들에 의해 정의된 <literal>&lt;join&gt;</literal>을 검색하는데 + 사용될 것이다. + </para> + </callout> + <callout arearefs="join5"> + <para> + <literal>inverse</literal> (옵션 - 디폴트는 <literal>false</literal>): + 이용 가능할 경우, Hibernate는 이 조인에 의해 정의된 프로퍼티들을 삽입시키거나 업데이트하려고 시도하지 + 않을 것이다. + </para> + </callout> + <callout arearefs="join6"> + <para> + <literal>optional</literal> (옵션 - 디폴트는 <literal>false</literal>): + 이용 가능할 경우, Hibernate는 이 조인에 의해 정의된 프로퍼티들이 null이 아닐 경우에만 한 행을 삽입시킬 것이고 + 그 프로퍼티들을 검색하는데 outer join을 항상 사용할 것이다. + </para> + </callout> + </calloutlist> + </programlistingco> + + <para> + 예를 들어, (모든 프로퍼티들에 대해 value 타입 의미를 유지하면서) 개인의 주소 정보는 별도의 테이블에 매핑될 수 있다: + </para> + + <programlisting><![CDATA[<class name="Person" + table="PERSON"> + + <id name="id" column="PERSON_ID">...</id> + + <join table="ADDRESS"> + <key column="ADDRESS_ID"/> + <property name="address"/> + <property name="zip"/> + <property name="country"/> + </join> + ...]]></programlisting> + + <para> + 이 특징은 자주 리거시 데이터 모형들에 대해서만 유용하고, 우리는 클래스들과 잘 정제된 도메인 모형 보다 더 적은 테이블들을 + 권장한다. 하지만 뒷 부분에 설명되어 있듯이, 그것은 하나의 계층구조 내에 있는 상속 매핑 방도들 사이를 전환하는 것에 유용하다. + </para> + + </sect2> + + <sect2 id="mapping-declaration-key"> + <title>key</title> + + <para> + 우리는 지금까지 몇 번 나타났던 <literal>&lt;key&gt;</literal> 요소를 보았다. 그것은 부모 매핑 요소가 새로운 테이블에 + 대한 조인을 정의하는 어느 곳에서나 나타나고, 그것은 조인된 테이블의 foreign 키를 정의하고, 그것은 원래의 테이블의 + 프라이머리 키를 참조한다. + </para> + + <programlistingco> + <areaspec> + <area id="key1" coords="2 50"/> + <area id="key2" coords="3 50"/> + <area id="key3" coords="4 50"/> + <area id="key4" coords="5 50"/> + <area id="key5" coords="6 50"/> + <area id="key6" coords="7 50"/> + </areaspec> + <programlisting><![CDATA[<key + column="columnname" + on-delete="noaction|cascade" + property-ref="propertyName" + not-null="true|false" + update="true|false" + unique="true|false" +/>]]></programlisting> + + <calloutlist> + <callout arearefs="key1"> + <para> + <literal>column</literal> (옵션): + foreign key 컬럼의 이름. 이것은 또한 내포된 <literal>&lt;column&gt;</literal> 요소(들)에 의해 지정될 수 있다. + </para> + </callout> + <callout arearefs="key2"> + <para> + <literal>on-delete</literal> (옵션 - 디폴트는 <literal>noaction</literal>): + foreign key 컨스트레인트가 데이터베이스 레벨의 cascade delete를 사용가능하도록 할 것인지 여부를 지정한다. + </para> + </callout> + <callout arearefs="key3"> + <para> + <literal>property-ref</literal> (옵션): + foreign key가 원래의 테이블의 프라이머리 키가 아닌 컬럼들을 참조함을 지정한다. (리거시 데이터에 제공됨.) + </para> + </callout> + <callout arearefs="key4"> + <para> + <literal>not-null</literal> (옵션): + foreign 키 컬럼들이 not null 임를 지정한다(이것은 foreign 키가 또한 프라이머리 키의 부분일 때마다 함축된다). + </para> + </callout> + <callout arearefs="key5"> + <para> + <literal>update</literal> (옵션): + foreign 키가 결코 업데이트되지 않아야 함을 지정한다(이것은 foreign 키가 또한 프라이머리 키의 부분일 때마다 + 함축된다). + </para> + </callout> + <callout arearefs="key6"> + <para> + <literal>unique</literal> (옵션): + foreign 키가 유일 컨스트레인트를 가져야 함을 지정한다 (이것은 foreign 키가 또한 프라이머리 키의 부분일 + 때마다 함축된다). + </para> + </callout> + </calloutlist> + </programlistingco> + + <para> + 우리는 delete 퍼포먼스가 중요한 시스템들에 대해 권장하고, 모든 키들은 <literal>on-delete="cascade"</literal>로 + 정의되고, Hibernate는 많은 <literal>DELETE</literal> 문장들 대신에, 데이터베이스 레벨의 + <literal>ON CASCADE DELETE</literal> 컨스트레인트를 사용할 것이다. 이 특징은 Hibernate의 통상적인 버전화된 + 데이터에 대한 optimistic 잠금 방도를 무시한다는 점을 알고 있어라. + </para> + + <para> + <literal>not-null</literal> 속성과 <literal>update</literal> 속성들은 단방향 one to many 연관관계를 매핑할 때 + 유용하다. 만일 당신이 단방향 one to many를 null이 허용되지 않는 foreign 키로 매핑할 경우, 당신은 + <literal>&lt;key not-null="true"&gt;</literal>를 사용하여 그 키 컬럼을 선언<emphasis>해야 한다</emphasis>. + </para> + + </sect2> + + <sect2 id="mapping-column" revision="4"> + <title>column 요소와 formula 요소</title> + <para> + column 속성을 허용하는 임의의 매핑 요소는 대안적으로 하나의 <literal>&lt;column&gt;</literal> 서브요소를 수용할 것이다. + 비슷하게 <literal>&lt;formula&gt;</literal>는 <literal>formula</literal> 속성에 대한 대안이다. + </para> + + <programlisting><![CDATA[<column + name="column_name" + length="N" + precision="N" + scale="N" + not-null="true|false" + unique="true|false" + unique-key="multicolumn_unique_key_name" + index="index_name" + sql-type="sql_type_name" + check="SQL expression" + default="SQL expression"/>]]></programlisting> + + <programlisting><![CDATA[<formula>SQL expression</formula>]]></programlisting> + + <para> + <literal>column</literal> 속성과 <literal>formula</literal> 속성은 예를 들어 신종 조인 조건들을 표현하기 위해 + 동일한 property 또는 연관관계 매핑 내에 결합될 수 있다. + </para> + + <programlisting><![CDATA[<many-to-one name="homeAddress" class="Address" + insert="false" update="false"> + <column name="person_id" not-null="true" length="10"/> + <formula>'MAILING'</formula> +</many-to-one>]]></programlisting> + + </sect2> + + <sect2 id="mapping-declaration-import"> + <title>import</title> + + <para> + 당신의 어플리케이션이 동일한 이름을 가진 두 개의 영속 클래스들을 갖고, 당신이 Hibernate 질의들 내에서 전체 수식어가 붙은 + (패키지)이름을 지정하는 것을 원하지 않는다고 가정하자. 클래스들은 <literal>auto-import="true"</literal>에 의존하기 + 보다 명시적으로 "임포트 될 " 것이다. 당신은 심지어 명시적으로 매핑되지 않는 클래스들과 인터페이스들을 임포트 시킬 수(가져오기 할 수) + 있다. + </para> + + <programlisting><![CDATA[<import class="java.lang.Object" rename="Universe"/>]]></programlisting> + + <programlistingco> + <areaspec> + <area id="import1" coords="2 40"/> + <area id="import2" coords="3 40"/> + </areaspec> + <programlisting><![CDATA[<import + class="ClassName" + rename="ShortName" +/>]]></programlisting> + <calloutlist> + <callout arearefs="import1"> + <para> + <literal>class</literal>: 임의의 Java 클래스의 전체 수식어가 붙은 클래스 이름. + </para> + </callout> + <callout arearefs="import2"> + <para> + <literal>rename</literal> (옵션 - 디폴트는 수식어가 붙지 않은 클래스 이름): + 질의 언어 내에서 사용될 이름. + </para> + </callout> + </calloutlist> + </programlistingco> + + </sect2> + + <sect2 id="mapping-types-anymapping" revision="2"> + <title>any</title> + + <para> + 하나 이상의 프로퍼티 매핑 타입이 존재한다. <literal>&lt;any&gt;</literal> 매핑 요소는 여러 테이블들로부터 클래스들에 + 대한 하나의 다형성 연관관계를 정의한다. 이 매핑 타입은 언제나 하나 이상의 컬럼을 필요로 한다. 첫 번째 컬럼은 연관된 엔티티의 + 타입을 보관한다. 나머지 컬럼들은 식별자를 보관한다. 이런 종류의 연관관계들에 대해 foreign key 컨스트레인트를 지정하는 것이 + 불가능해서, 이것은 (다형성) 연관관계들을 매핑하는 통상적인 방법으로서 가장 확실한 수단이 아니다. 당신은 매우 특별한 경우들 + (예를 들어 감사 로그들, 사용자 세션 데이터 등)에서만 이것을 사용해야 한다. + </para> + + <para> + <literal>meta-type</literal> 속성은 어플리케이션으로 하여금 데이터베이스 컬럼 값들을 <literal>id-type</literal>에 + 의해 지정된 타입의 식별자 프로퍼티들을 가진 영속 클래스들로 매핑시키는 맞춤형 타입을 지정하도록 한다. 당신은 meta-type의 + 값들로부터 클래스 이름들로의 매핑을 지정해야 한다. + </para> + + <programlisting><![CDATA[<any name="being" id-type="long" meta-type="string"> + <meta-value value="TBL_ANIMAL" class="Animal"/> + <meta-value value="TBL_HUMAN" class="Human"/> + <meta-value value="TBL_ALIEN" class="Alien"/> + <column name="table_name"/> + <column name="id"/> +</any>]]></programlisting> + + <programlistingco> + <areaspec> + <area id="any1" coords="2 50"/> + <area id="any2" coords="3 50"/> + <area id="any3" coords="4 50"/> + <area id="any4" coords="5 50"/> + <area id="any5" coords="6 50"/> + <area id="any6" coords="7 50"/> + </areaspec> + <programlisting><![CDATA[<any + name="propertyName" + id-type="idtypename" + meta-type="metatypename" + cascade="cascade_style" + access="field|property|ClassName" + optimistic-lock="true|false" +> + <meta-value ... /> + <meta-value ... /> + ..... + <column .... /> + <column .... /> + ..... +</any>]]></programlisting> + <calloutlist> + <callout arearefs="any1"> + <para> + <literal>name</literal>: 프로퍼티 이름. + </para> + </callout> + <callout arearefs="any2"> + <para> + <literal>id-type</literal>: 식별자 타입. + </para> + </callout> + <callout arearefs="any3"> + <para> + <literal>meta-type</literal> (옵션 - 디폴트는 <literal>string</literal>): + discriminator 매핑에 허용되는 임의의 타입. + </para> + </callout> + <callout arearefs="any4"> + <para> + <literal>cascade</literal> (optional- defaults to <literal>none</literal>): + cascade 스타일. + </para> + </callout> + <callout arearefs="any5"> + <para> + <literal>access</literal> (옵션 - 디폴트는 <literal>property</literal>): + Hibernate가 프로퍼티 값에 접근하는데 사용할 방도. + </para> + </callout> + <callout arearefs="any6"> + <para> + <literal>optimistic-lock</literal> (옵션 - 디폴트는 <literal>true</literal>): + 이 프로퍼티에 대한 업데이트들이 optimistic 잠금 획득을 필요로 하는지 여부를 지정한다. 달리 말해, + 이 프로퍼티가 dirty일 경우에 버전증가가 발생할 것인지 여부를 정의한다. + </para> + </callout> + </calloutlist> + </programlistingco> + + </sect2> + + </sect1> + + <sect1 id="mapping-types"> + <title>Hibernate 타입들</title> + + <sect2 id="mapping-types-entitiesvalues" revision="1"> + <title>엔티티들과 값들</title> + + <para> + 영속 서비스에 관한 여러 Java 언어-레벨의 객체들을 이해하기 위해, 우리는 그것들을 다음 두 개의 그룹들로 분류할 필요가 있다: + </para> + + <para> + <emphasis>entity</emphasis>는 엔티티에 대한 참조들을 보관하는 임의의 다른 객체들과는 독립적으로 존재한다. 참조되지 않은 + 객체가 쓰레기 수집되는 통상의 자바 모형과 이것은 대조적이다. (저장들과 삭제들이 부모 엔티티로부터 그것의 자식으로의 케스케이드 + 되는 경우를 제외하면) 엔티티들은 명시적으로 저장되고 삭제되어야 한다. 이것은 도달 가능성(reachablity)에 의한 객체 영속성의 + ODMG 모형과는 다르다 - 그리고 어플리케이션 객체들이 대형 시스템들에서 대개 어떻게 사용되는가에 훨씬 더 가깝게 대응한다. + 엔티티들은 순환 참조와 공유 참조들을 지원한다. 그것들 또한 버전화 될 수 있다. + </para> + + <para> + 엔티티의 영속 상태는 다른 엔티티들에 대한 참조들과 <emphasis>value</emphasis> 타입들로 구성된다. 값들은 원시 타입들, + 콜렉션들(하나의 콜렉션 내부에 있지 않는 것들), 컴포넌트들, 그리고 어떤 불변의 객체들이다. entities와는 달리, (특별한 + 콜렉션들과 컴포넌트들에서) 값들은 도달가능성(reachability)에 의해 영속화 <emphasis>되고</emphasis> 삭제 된다. + value 객체들(과 원시 타입들)이 그것들의 포함하는 엔티티에 따라 영속화 되고 삭제 되므로, 그것들은 독립적으로 버전화 되지 + 않는다. 값들은 독립적인 엔티티를 갖지 않아서, 그것들은 두 개의 엔티티들이나 콜렉션들에 의해 공유될 수 없다. + </para> + + <para> + 지금까지 우리는 엔티티들을 참조하기 위해 "영속 클래스"를 사용해 왔다. 우리는 그것을 계속 사용할 것이다. 하지만 엄격히 말해, + 영속 상태를 가진 모든 사용자 정의 클래스들은 엔티티들이 아니다. <emphasis>컴포넌트</emphasis>는 value 의미를 가진 + 사용자 정의 클래스이다. <literal>java.lang.String</literal> 타입의 자바 프로퍼티는 또한 value 의미를 갖는다. + 이 정의가 주어지면, 우리는 JDK에 의해 제공된 모든 타입들(클래스들)이 자바에서 value 타입 의미를 갖고, 반면에 사용자 정의 + 타입들은 엔티티 또는 type 의미로서 매핑된다고 말할 수 있다. 이 판단은 어플리케이션 개발자에게 달려 있다. 도메인 모형에서 + 엔티티 클래스에 대한 좋은 힌트는 그 클래스의 하나의 인스턴스에 대한 공유된 참조들인 반면에, composition이나 aggregation은 + 대개 value 타입으로 변환된다. + </para> + + <para> + 우리는 문서를 통해 두 개념들을 다시 고찰할 것이다. + </para> + + <para> + 도점점은 Java type 시스템(과 엔티티들 및 value 타입들에 대한 개발자의 정의)를 SQL/데이터베이스 type 타입으로 매핑하는 + 것이다. 두 시스템들 사이의 다리는 Hibernate에 의해 제공된다: 엔티티들의 경우 우리는 <literal>&lt;class&gt;</literal>, + <literal>&lt;subclass&gt;</literal> 등을 사용한다.value 타입들의 경우 우리는 대개<literal>type</literal> 속성을 가진 + <literal>&lt;property&gt;</literal>, <literal>&lt;component&gt;</literal> 등을 사용한다. 이 속성의 값은 + Hibernate <emphasis>매핑 타입</emphasis>의 이름이다. Hibernate는 (표준 JDK value 타입들에 대해) 많은 매핑들을 + 제공한다. 나중에 보게 되듯이, 당신은 당신 자신의 매핑 타입들을 작성할 수 있고 마찬가지로 당신의 맞춤형 변환 방도들을 구현할 수 + 있다. + </para> + + <para> + 콜렉션들을 제외한 모든 미리 빌드된 Hibernate 타입들은 null 의미를 지원한다. + </para> + + </sect2> + + <sect2 id="mapping-types-basictypes" revision="3"> + <title>기본 value 타입들</title> + + <para> + 미리-만들어진 <emphasis>기본 매핑 타입들</emphasis>은 대략 다음과 같이 카테고리로 분류된다 + + <variablelist> + <varlistentry> + <term><literal>integer, long, short, float, double, character, byte, + boolean, yes_no, true_false</literal></term> + <listitem> + <para> + 자바 원시타입들이나 wrapper 클래스들로부터 적절한(벤더-지정적인) SQL 컬럼 타입들로의 타입 매핑. + <literal>boolean, yes_no</literal>와 <literal>true_false</literal>는 + Java <literal>boolean</literal>이나 <literal>java.lang.Boolean</literal>에 대한 + 모든 대체적인 인코딩들이다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>string</literal></term> + <listitem> + <para> + <literal>java.lang.String</literal>으로부터 <literal>VARCHAR</literal> + (또는 Oracle <literal>VARCHAR2</literal>)로의 타입 매핑. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>date, time, timestamp</literal></term> + <listitem> + <para> + <literal>java.util.Date</literal>와 그것의 서브클래스로부터 SQL 타입들인 + <literal>DATE</literal>, <literal>TIME</literal>, <literal>TIMESTAMP</literal> + (또는 등가물)로의 타입 매핑들. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>calendar, calendar_date</literal></term> + <listitem> + <para> + <literal>java.util.Calendar</literal>로부터 SQL 타입들인 + <literal>TIMESTAMP</literal>, <literal>DATE</literal> (또는 등가물)로의 타입 매핑들. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>big_decimal, big_integer</literal></term> + <listitem> + <para> + <literal>java.math.BigDecimal</literal>과 <literal>java.math.BigInteger</literal>로부터 + <literal>NUMERIC</literal> (또는 Oracle <literal>NUMBER</literal>)로의 타입 매핑들. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>locale, timezone, currency</literal></term> + <listitem> + <para> + <literal>java.util.Locale</literal>, <literal>java.util.TimeZone</literal>, 그리고 + <literal>java.util.Currency</literal>로부터 <literal>VARCHAR</literal>(또는 Oracle + <literal>VARCHAR2</literal>)로의 타입 매핑. <literal>Locale</literal>과 <literal>Currency</literal>의 + 인스턴스들은 그것들의 ISO 코드들로 매핑된다. <literal>TimeZone</literal>의 인스턴스들은 그것들의 + <literal>ID</literal>로 매핑된다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>class</literal></term> + <listitem> + <para> + <literal>java.lang.Class</literal>로부터 <literal>VARCHAR</literal> (또는 Oracle + <literal>VARCHAR2</literal>)로의 타입 매핑. <literal>Class</literal>는 그것의 전체 + 수식어가 붙은 이름으로 매핑된다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>binary</literal></term> + <listitem> + <para> + byte 배열들을 적절한 SQL binary 타입으로 매핑시킨다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>text</literal></term> + <listitem> + <para> + long Java 문자열을 SQL <literal>CLOB</literal> 또는 <literal>TEXT</literal> 타입으로 + 매핑시킨다 + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>serializable</literal></term> + <listitem> + <para> + serializable Java 타입들을 적절한 SQL binary 타입으로 매핑시킨다. 당신은 또한 디폴트로 기본 타입이 + 아닌 serializable 자바 클래스 또는 인터페이스의 이름을 가진 Hibernate 타입 <literal>serializable</literal>을 + 나타낼 수도 있다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>clob, blob</literal></term> + <listitem> + <para> + <literal>java.sql.Clob</literal>와 <literal>java.sql.Blob</literal> JDBC 클래스들에 대한 타입 매핑들. + 이들 타입들은 몇몇 어플리케이션들에서는 불편하다. 왜냐하면 blob 또는 clob 객체는 트랜잭션 외부에서 재사용될 수 없기 + 때문이다.(게다가 드라이버 지원이 비일관적이고 페치되어야 한다) + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + <literal>imm_date, imm_time, imm_timestamp, imm_calendar, imm_calendar_date, + imm_serializable, imm_binary</literal> + </term> + <listitem> + <para> + 대개 가변적인 Java 타입들로 간주되는 것에 대한 타입 매핑들. 여기서 Hibernate는 불변적인 Java 타입들에 대해서만 적절한 + 어떤 최적화를 행하고, 어플리케이션 그 객체를 변할 수 없는 것으로 취급한다. 예를 들어, 당신은 <literal>imm_timestamp</literal>로서 + 매핑된 인스턴스에 대해 <literal>Date.setTime()</literal>을 호출하지 않을 것이다. 프로퍼티의 값을 변경시키고, + 그 변경을 영속화 시키기 위해서, 어플리케이션은 하나의 새로운 (동일하지 않은) 객체를 그 프로퍼티에 할당해야 한다. + </para> + </listitem> + </varlistentry> + </variablelist> + + </para> + + <para> + 엔트리들과 콜렉션들의 유일 식별자들은 <literal>binary</literal>, <literal>blob</literal> 그리고 <literal>clob</literal>를 + 제외한 기본 타입 중 어느 것일 수 있다. (Composite 식별자들이 또한 허용된다. 아래를 보라.) + </para> + + <para> + 기본 value 타입들은 <literal>org.hibernate.Hibernate</literal>에 정의되어 있는 대응하는 + <literal>Type</literal> 상수들을 갖는다. 예를 들어, <literal>Hibernate.STRING</literal>은 + <literal>string</literal> 타입을 표현한다. + </para> + + </sect2> + + <sect2 id="mapping-types-custom" revision="2"> + <title>맞춤형 value 타입들</title> + + <para> + 개발자들이 그들 자신들의 value 타입들을 생성시키는 것이 상대적으로 쉽다. 예를 들어, 당신은 + <literal>java.lang.BigInteger</literal> 타입의 프로퍼티들을 <literal>VARCHAR</literal> 컬럼들로 + 영속화 시키고자 원할 수 있다. Hibernate는 이것을 위한 미리 만들어진 타입을 제공하지 않는다. 그러나 맞춤형 타입들은 + 프로퍼티(또는 콜렉션 요소)를 하나의 테이블 컬럼으로의 매핑하는 것에 제약되지 않는다. 따라서 예를 들어, 당신은 + <literal>FIRST_NAME</literal>, <literal>INITIAL</literal>, <literal>SURNAME</literal> 컬럼들로 + 영속화 되는 <literal>java.lang.String</literal> 타입의 자바 프로퍼티<literal>getName()</literal>/ + <literal>setName()</literal>를 가질 수 있다. + </para> + + <para> + 맞춤형 타입을 구현하려면, <literal>org.hibernate.UserType</literal> 또는 <literal>org.hibernate.CompositeUserType</literal>을 + 구현하고 그 타입의 전체 수식어가 붙은 클래스명을 사용하여 프로퍼티들을 선언하라. 가능한 종류의 것들을 보려면 + <literal>org.hibernate.test.DoubleStringType</literal>을 체크하라. + </para> + + <programlisting><![CDATA[<property name="twoStrings" type="org.hibernate.test.DoubleStringType"> + <column name="first_string"/> + <column name="second_string"/> +</property>]]></programlisting> + + <para> + 하나의 프로퍼티를 여러 개의 컬럼들로 매핑시키는 <literal>&lt;column&gt;</literal> 태그의 사용을 주목하라. + </para> + + <para> + <literal>CompositeUserType</literal>, <literal>EnhancedUserType</literal>, + <literal>UserCollectionType</literal>, 그리고 <literal>UserVersionType</literal> 인터페이스들은 + 더 많은 특화된 사용들을 위한 지원을 제공한다. + </para> + + <para> + 당신은 매핑 파일 속에 <literal>UserType</literal>에 대한 파라미터들을 제공할 수도 있다. 이것을 행하기 위해, + 당신의 <literal>UserType</literal>은 <literal>org.hibernate.usertype.ParameterizedType</literal> + 인터페이스를 구현해야 한다. 당신의 맞춤형 타입에 파라미터들을 제공하기 위해, 당신은 당신의 매핑 파일들 속에 + <literal>&lt;type&gt;</literal> 요소를 사용할 수 있다. + </para> + + <programlisting><![CDATA[<property name="priority"> + <type name="com.mycompany.usertypes.DefaultValueIntegerType"> + <param name="default">0</param> + </type> +</property>]]></programlisting> + + <para> + <literal>UserType</literal>은 이제 그것에 전달된 <literal>Properties</literal> 객체로부터 + <literal>default</literal>로 명명된 파라미터에 대한 값을 검색할 수 있다. + </para> + + <para> + 만일 당신이 매우 자주 어떤 UserType을 사용할 경우, 그것은 그것에 대한 더 짧은 이름을 정의하는 것이 유용할 수 있다. + <literal>&lt;typedef&gt;</literal> 요소를 사용하여 이것을 행할 수 있다. Typedef들은 이름을 맞춤형 타입에 + 할당하고, 또한 만일 그 타입이 파라미터화 된 경우에 디폴트 파라미터 값들의 리스트를 포함할 수도 있다. + </para> + + <programlisting><![CDATA[<typedef class="com.mycompany.usertypes.DefaultValueIntegerType" name="default_zero"> + <param name="default">0</param> +</typedef>]]></programlisting> + + <programlisting><![CDATA[<property name="priority" type="default_zero"/>]]></programlisting> + + <para> + property 매핑 상에 type 파라미터들을 사용함으로써 경우에 맞게 typedef 내에 제공된 파라미터들을 오버라이드 시키는 것이 + 가능하다. + </para> + + <para> + 비록 Hibernate의 풍부한 범위의 미리 만들어진 타입들과 컴포넌트들에 대한 지원이 당신이 가끔 맞춤형 타입을 사용할 <emphasis>필요가</emphasis> + 거의 없을 것임을 의미할 지라도, 그럼에도 불구하고 그것은 당신의 어플리케이션에서 자주 발생하는 (엔티티가 아닌) 클래스들에 대해 + 맞춤형 타입들을 사용하는 좋은 형식으로 간주된다. 예를 들어 <literal>MonetaryAmount</literal> 클래스는 비록 그것이 + 컴포넌트로서 쉽게 매핑될 수 있을지라도, <literal>CompositeUserType</literal>에 대한 좋은 후보이다. 이것에 대한 + 하나의 동기는 추상화이다. 맞춤형 타입으로, 당신의 매핑 문서들은 화폐 값들을 표현하는 당신의 방법에서 가능한 변경들에 대해 장차 + 검증될 것이다. + </para> + + </sect2> + + </sect1> + + <sect1 id="mapping-entityname"> + <title>하나의 클래스를 한 번 이상 매핑하기</title> + <para> + 하나의 특정한 영속 클래스에 대해 하나 이상의 매핑을 제공하는 것이 가능하다. 이 경우에 당신은 두 개의 매핑된 엔티티들의 + 인스턴스들 사이를 명확하게 하기 위해 <emphasis>하나의 엔티티 이름</emphasis>을 지정해야 한다. (디폴트로, 엔티티 + 이름은 클래스 이름과 동일한 것이다.) Hibernate는 영속 객체들에 대해 작업할 때, 질의들을 작성할 때, 또는 명명된 엔티티에 + 대한 연관들을 매핑할 때 당신으로 하여금 엔티티 이름을 지정하도록 한다. + </para> + + <programlisting><![CDATA[<class name="Contract" table="Contracts" + entity-name="CurrentContract"> + ... + <set name="history" inverse="true" + order-by="effectiveEndDate desc"> + <key column="currentContractId"/> + <one-to-many entity-name="HistoricalContract"/> + </set> +</class> + +<class name="Contract" table="ContractHistory" + entity-name="HistoricalContract"> + ... + <many-to-one name="currentContract" + column="currentContractId" + entity-name="CurrentContract"/> +</class>]]></programlisting> + + <para> + 연관들은 이제 <literal>class</literal> 대신에 <literal>entity-name</literal>을 사용하여 어떻게 지정되는지를 + 주목하라. + </para> + + </sect1> + + <sect1 id="mapping-quotedidentifiers"> + <title>SQL 인용부호 표시된 식별자들</title> + <para> + 당신은 매핑 문서 내에서 테이블 또는 컬럼 이름을 역인용기호(`)들 속에 넣어서 생성된 SQL에서 식별자를 인용부호 처리하도록 + Hibernate에게 강제할 수도 있다. Hibernate는 SQL <literal>Dialect</literal>에 대해 정확한 인용 스타일을 사용할 + 것이다(대개 이중 인용부호 이지만, SQL Server의 경우에는 모난 괄호들이고 MySQL의 경우에는 역인용부호(`)). + </para> + + <programlisting><![CDATA[<class name="LineItem" table="`Line Item`"> + <id name="id" column="`Item Id`"/><generator class="assigned"/></id> + <property name="itemNumber" column="`Item #`"/> + ... +</class>]]></programlisting> + + </sect1> + + + <sect1 id="mapping-alternatives"> + <title>Metadata 대안들</title> + + <para> + XML은 모든 사람들을 위한 것이 아니지만, Hibernate에서 O/R 매핑 메타데이터를 정의하는 몇몇 대안적인 방법들이 존재한다. + </para> + + <sect2 id="mapping-xdoclet"> + <title>XDoclet 마크업 사용하기</title> + + <para> + 많은 Hibernate 사용자들은 XDoclet <literal&gt;(a)hibernate.xn--tags&lt;/literal&gt;-g352f 사용하여 소스 코드 속에 + 직접 매핑 정보를 삽입시키는 것을 선호한다. 우리는 이 문서에서 이 접근법을 다루지 않을 것이다. 왜냐하면 그것은 + 엄격하게는 XDoclet의 부분으로 간주되기 때문이다. 하지만 우리는 XDoclet 매핑들을 가진 <literal>Cat</literal> + 클래스에 관한 다음 예제를 포함한다. + </para> + + <programlisting><![CDATA[package eg; +import java.util.Set; +import java.util.Date; + +/** + * @hibernate.class + * table="CATS" + */ +public class Cat { + private Long id; // identifier + private Date birthdate; + private Cat mother; + private Set kittens + private Color color; + private char sex; + private float weight; + + /* + * @hibernate.id + * generator-class="native" + * column="CAT_ID" + */ + public Long getId() { + return id; + } + private void setId(Long id) { + this.id=id; + } + + /** + * @hibernate.many-to-one + * column="PARENT_ID" + */ + public Cat getMother() { + return mother; + } + void setMother(Cat mother) { + this.mother = mother; + } + + /** + * @hibernate.property + * column="BIRTH_DATE" + */ + public Date getBirthdate() { + return birthdate; + } + void setBirthdate(Date date) { + birthdate = date; + } + /** + * @hibernate.property + * column="WEIGHT" + */ + public float getWeight() { + return weight; + } + void setWeight(float weight) { + this.weight = weight; + } + + /** + * @hibernate.property + * column="COLOR" + * not-null="true" + */ + public Color getColor() { + return color; + } + void setColor(Color color) { + this.color = color; + } + /** + * @hibernate.set + * inverse="true" + * order-by="BIRTH_DATE" + * @hibernate.collection-key + * column="PARENT_ID" + * @hibernate.collection-one-to-many + */ + public Set getKittens() { + return kittens; + } + void setKittens(Set kittens) { + this.kittens = kittens; + } + // addKitten not needed by Hibernate + public void addKitten(Cat kitten) { + kittens.add(kitten); + } + + /** + * @hibernate.property + * column="SEX" + * not-null="true" + * update="false" + */ + public char getSex() { + return sex; + } + void setSex(char sex) { + this.sex=sex; + } +}]]></programlisting> + + <para> + XDoclet과 ibernate에 관한 추가 예제들은 Hibernate 웹 사이트를 보라. + </para> + + </sect2> + + <sect2 id="mapping-annotations" revision="2"> + <title>JDK 5.0 Annotations 사용하기</title> + + <para> + JDK 5.0은 언어 레벨에서 XDoclet-스타일의 주석들, type-safe와 컴파일 시 체킹을 도입했다. 이 메커니즘은 XDoclet + 주석들 보다 더 강력하며 도구들과 IDE들에 의해 더 좋게 지원된다. 예를 들어 IntelliJ IDEA는 JDK 5.0 주석들에 대한 + 자동-완성 기능과 구문 강조를 지원한다. EJB 명세서의 새로운 개정판(JSR-220)은 엔티티 빈즈에 대한 프라이머리 메타데이터 + 메커니즘으로서 JDK 5.0 Annotations을 사용한다. Hibernate3는 JSR-220(영속 API)의 <literal>EntityManager</literal>를 + 구현하고, 매핑 메타데이터에 대한 지원은 별도의 내려받기로서 <emphasis>Hibernate Annotations</emphasis> 패키지를 + 통해 이용 가능하다. EJB3 (JSR-220)과 Hibernate3 metadata 양자가 지원된다. + </para> + + <para> + 다음은 EJB 엔티티 빈으로서 주석이 붙은 POJO 클래스에 관한 예제이다: + </para> + + <programlisting><![CDATA[@Entity(access = AccessType.FIELD) +public class Customer implements Serializable { + + @Id; + Long id; + + String firstName; + String lastName; + Date birthday; + + @Transient + Integer age; + + @Embedded + private Address homeAddress; + + @OneToMany(cascade=CascadeType.ALL) + @JoinColumn(name="CUSTOMER_ID") + Set<Order> orders; + + // Getter/setter and business methods +}]]></programlisting> + + <para> + JDK 5.0 Annotations(그리고 JSR-220)에 대한 지원은 여전히 작업이 진행 중이고 완성되지 않았음을 노트하라. 상세한 것은 + Hibernate Anotations를 참조하라. + </para> + + </sect2> + </sect1> + + <sect1 id="mapping-generated" revision="1"> + <title>산출되는 프로퍼티들</title> + <para> + 산출되는 프로퍼티들은 데이터베이스에 의해 산출되는 그것들의 값들을 갖는 프로퍼티들이다. 전형적으로, + Hibernate 어플리케이션들은 데이터베이스가 값들을 생성시켰던 임의의 프로퍼티들을 포함하는 객체들을 + <literal>갱신</literal>시킬 필요가 있었다.하지만 generated로 마크된 프로퍼티들은 어플리케이션으로 + 하여금 이 책임을 Hibernate에게 위임시키도록 한다. 본질적으로 Hibernate가 산출되는 프로퍼티들을 정의했던 엔티티에 + 대해 SQL INSERT 또는 UPDATE 명령을 내릴 때마다 바로 직후에 산출되는 값들을 검색하기 위해 하나의 select 명령을 + 내린다. + </para> + <para> + generated로 마크된 프로퍼티들은 부가적으로 inser 가능하지 않아야 하고 update 불가능해야 한다. 오직 + Properties marked as generated must additionally be non-insertable and non-updateable. + <xref linkend="mapping-declaration-version">versions</xref>, + <xref linkend="mapping-declaration-timestamp">timestamps</xref>, 그리고 + <xref linkend="mapping-declaration-property">단순 프로퍼티들</xref> 만이 generated로 + 마크될 수 있다. + </para> + <para> + <literal>never</literal> (디폴트) - 는 주어진 프로퍼티 값이 데이터베이스 내에 생성되지 않을 것임을 의미한다. + </para> + <para> + <literal>insert</literal> - 는 주어진 프로퍼티 값이 insert 시에 생성되지만, 차후의 업데이트들에서 다시 + 생성되지 않을 것임을 기술한다. 생성-날짜와 같은 것들이 이 카테고리 내로 포함될 것이다. 비록 + <xref linkend="mapping-declaration-version">version</xref>과 + <xref linkend="mapping-declaration-timestamp">timestamp</xref> 프로퍼티들이 생성되는 것으로서 + 마크될 수 있을 지라도, 이 옵션은 거기서 이용 불가능함을 노트하라... + </para> + <para> + <literal>always</literal> - 는 프로퍼티 값이 insert 시와 update 시 모두에 생성됨을 기술한다. + </para> + </sect1> + + <sect1 id="mapping-database-object"> + <title>보조 데이터베이스 객체들</title> + <para> + Hibernate 매핑 파일들 내에 사용자 스키마를 완전하게 정의하기 위한 능력을 제공하기 위해서, + Hibernate의 스키마 방출 도구들과 함께 임의적인 데이터베이스 객체들에 대한 CREATE와 DROP을 허용해준다. + 비록 트리거들 또는 내장 프로시저들과 같은 것들을 생성시키고 드롭시키기 이해 특별히 고안되었을지라도 + 하나의 <literal>java.sql.Statement.execute()</literal> 메소드를 통해 실행될 수 있는 SQL 명령이 + 여기서 유효하다(ALTERs, INSERTS, 기타). 보조 데0이터베이스 객체들을 정의하는 두 가지 모드들이 본질적으로 + 존재한다... + </para> + <para> + 첫 번째 모드는 매핑 파일 바깥에서 CREATE 및 DROP 명령들을 명시적으로 나열하는 것이다: + </para> + <programlisting><![CDATA[<hibernate-mapping> + ... + <database-object> + <create>CREATE TRIGGER my_trigger ...</create> + <drop>DROP TRIGGER my_trigger</drop> + </database-object> +</hibernate-mapping>]]></programlisting> + <para> + 두번째 모드는 CREATE 및 DROP 명령들을 생성시키는 방법을 알고 있는 하나의 맞춤 클래스를 제공하는 것이다. + 이 맞춤 클래스는 <literal>org.hibernate.mapping.AuxiliaryDatabaseObject</literal> + 인터페이스를 구현해야 한다. + </para> + <programlisting><![CDATA[<hibernate-mapping> + ... + <database-object> + <definition class="MyTriggerDefinition"/> + </database-object> +</hibernate-mapping>]]></programlisting> + <para> + 덧붙여 이들 데이터베이스 객체들은 어떤 dialect들이 사용될 때 그것들이 단지 적용될 수 있도록 선택적으로 + 변동될 수 있다. + </para> + <programlisting><![CDATA[<hibernate-mapping> + ... + <database-object> + <definition class="MyTriggerDefinition"/> + <dialect-scope name="org.hibernate.dialect.Oracle9Dialect"/> + <dialect-scope name="org.hibernate.dialect.OracleDialect"/> + </database-object> +</hibernate-mapping>]]></programlisting> + </sect1> +</chapter> + Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/batch.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/batch.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/batch.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/batch.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,320 @@ +<chapter id="batch"> + <title>Batch 처리</title> + + <para> + Hibernate를 사용하여 데이터베이스 내에서 100 000 개의 행들을 삽입시키는 본래의 접근법은 다음과 같다: + </para> + +<programlisting><![CDATA[Session session = sessionFactory.openSession(); +Transaction tx = session.beginTransaction(); +for ( int i=0; i<100000; i++ ) { + Customer customer = new Customer(.....); + session.save(customer); +} +tx.commit(); +session.close();]]></programlisting> + + <para> + 이것은 50 000번째 행 가까운 곳에서 <literal>OutOfMemoryException</literal>으로 떨어질 것이다. 그것은 Hibernate가 + session-level 캐시 속에 모든 새로이 삽입된 <literal>Customer</literal> 인스턴스들을 캐시시키기 때문이다. + </para> + + <para> + 이 장에서 우리는 이 문제를 피하는 방법을 당신에게 보여줄 것이다. 하지만 먼저 당신이 배치 처리를 행하는 중이라면, 당신이 적당한 퍼포먼스를 + 성취하려고 할 경우에 당신이 JDBC 배치 사용을 가능하게 하는 것은 절대적으로 필요하다. JDBC 배치 사이즈를 적당한 숫자(10-50)로 설정하라: + </para> + +<programlisting><![CDATA[hibernate.jdbc.batch_size 20]]></programlisting> + + <para id="disablebatching" revision="1"> + 만일 당신이 <literal>identiy</literal> 식별자 생성자를 사용할 경우 + Hibernate가 JDBC 레벨에서 투명하게 insert 배치작업을 사용불가능하게 한다는 점을 노트하라. + </para> + + <para> + 당신은 또한 second-level 캐시를 가진 상호작용이 완전하게 불가능한 프로세스 내에서 이런 종류의 작업을 행하고 싶어할 수도 있다: + </para> + +<programlisting><![CDATA[hibernate.cache.use_second_level_cache false]]></programlisting> + + <para> + 하지만 이것은 절대적으로 필요하지 않다. 왜냐하면 우리는 second-level 캐시와의 상호작용을 불가능하도록 하기 위해 + 명시적으로 <literal>CacheMode</literal>를 설정할 수 있기 때문이다. + </para> + + <sect1 id="batch-inserts"> + <title>Batch inserts</title> + + <para> + 새로운 객체들을 영속화 시킬 때, 당신은 first-level 캐시의 사이즈를 제어하기 위해 세션을 정기적으로 <literal>flush()</literal> + 시키고 나서 <literal>clear()</literal> 시켜야 한다. + </para> + +<programlisting><![CDATA[Session session = sessionFactory.openSession(); +Transaction tx = session.beginTransaction(); + +for ( int i=0; i<100000; i++ ) { + Customer customer = new Customer(.....); + session.save(customer); + if ( i % 20 == 0 ) { //20, same as the JDBC batch size + //flush a batch of inserts and release memory: + session.flush(); + session.clear(); + } +} + +tx.commit(); +session.close();]]></programlisting> + + </sect1> + + <sect1 id="batch-update" > + <title>Batch updates</title> + + <para> + 데이터 검색과 업데이트의 경우 동일한 개념들이 적용된다. 게다가 당신은 많은 데이터 행들을 반환하는 질의들에 대해 서버-측 커서들의 장점을 + 취하는데 <literal>scroll()</literal>을 사용할 필요가 있다. + </para> + +<programlisting><![CDATA[Session session = sessionFactory.openSession(); +Transaction tx = session.beginTransaction(); + +ScrollableResults customers = session.getNamedQuery("GetCustomers") + .setCacheMode(CacheMode.IGNORE) + .scroll(ScrollMode.FORWARD_ONLY); +int count=0; +while ( customers.next() ) { + Customer customer = (Customer) customers.get(0); + customer.updateStuff(...); + if ( ++count % 20 == 0 ) { + //flush a batch of updates and release memory: + session.flush(); + session.clear(); + } +} + +tx.commit(); +session.close();]]></programlisting> + + </sect1> + + <sect1 id="batch-statelesssession"> + <title>StatelessSession 인터페이스</title> + <para> + 다른 방법으로 Hibernate는 분리된(detached) 객체들의 형식으로 데이터베이스로 그리고 데이터베이스로부터 + 데이터를 스트리밍하는데 사용될 수 있는 하나의 명령 지향 API를 제공한다. <literal>StatelessSession</literal>은 + 그것과 연관된 영속 컨텍스트를 갖지 않고 많은 보다 높은 레벨의 생명 주기 의미를 제공하지 않는다. + 특히 하나의 상태 없는 세션은 첫 번째 레벨 캐시를 구현하지 않거나 임의의 두 번째 레벨 캐시 또는 질의 캐시와 + 상호작용하지 않는다. 그것은 전통적인 쓰기-이면(write-behind)의 체킹이나 자동적인 dirty 체킹을 구현하지 않는다. + 하나의 상태 없는 세션을 사용하여 수행된 연산들은 연관된 인스턴스들에 대해 케스케이드 되지 않는다. 콜렉션들은 + 상태 없는 세션에 의해 무시된다. 상태없는 세션을 통해 수행된 연산들은 Hibernate의 이벤트 모형과 인터셉터들을 + 우회한다. 상태없는 세션들은 첫번째-레벨의 캐시의 부족으로 인해 데이터 alias 효과들에 취약하다. 상태없는 세션은 + 기본 JDBC에 훨씬 더 가까운 하나의 보다 낮은 레벨의 추상화(abstraction)이다. + </para> + +<programlisting><![CDATA[StatelessSession session = sessionFactory.openStatelessSession(); +Transaction tx = session.beginTransaction(); + +ScrollableResults customers = session.getNamedQuery("GetCustomers") + .scroll(ScrollMode.FORWARD_ONLY); +while ( customers.next() ) { + Customer customer = (Customer) customers.get(0); + customer.updateStuff(...); + session.update(customer); +} + +tx.commit(); +session.close();]]></programlisting> + + <para> + 이 코드 예제에서, 질의에 의해 반환된 <literal>Customer</literal> 인스턴스들은 곧바고 분리된다(detached). + 그것들은 임의의 영속 컨텍스트와 결코 연관되지 않는다. + </para> + + <para> + <literal>StatelessSession</literal> 인터페이스에 의해 정의된 + <literal>insert(), update()</literal> 그리고 <literal>delete()</literal> 연산들은 직접적인 + 데이터베이스 저급 연산들로 갖주되고, 그것은 각각 하나의 SQL <literal>INSERT, UPDATE</literal> 또는 + <literal>DELETE</literal>의 즉각적인 실행으로 귀결된다. 따라서 그것들은 <literal>Session</literal> + 인터페이스에 의해 정의된 <literal>save(), saveOrUpdate()</literal>와 <literal>delete()</literal> + 연산들과는 매우 다른 의미들을 갖는다. + </para> + + </sect1> + + <sect1 id="batch-direct" revision="3"> + <title>DML-스타일 연산들</title> + + <para> + 이미 논의했듯이, 자동적이고 투명한 객체/관계형 매핑은 객체 상태에 대한 관리에 관계된다. 이것은 객체 상태가 메모리 내에서 이용 가능함을 + 의미하므로, (SQL <literal>Data Manipulation Language</literal>(DML) 문장들 : <literal>INSERT</literal>, + <literal>UPDATE</literal>, <literal>DELETE</literal>를 사용하여) 데이터베이스에서 직접 데이터를 + 업데이트하거나 삭제하는 것은 메모리 내 상태에 영향을 주지 않을 것이다. 하지만 Hibernate는 Hibernate Query Language + (<xref linkend="queryhql">HQL</xref>)를 통해 실행되는 대량 SQL-스타일의 DML 문장 실행을 위한 메소드들을 제공한다. + </para> + + <para> + <literal>UPDATE</literal>와 <literal>DELETE</literal> 문장들에 대한 유사 구문은 다음과 같다: + <literal>( UPDATE | DELETE ) FROM? EntityName (WHERE where_conditions)?</literal>. 노트할 몇 가지: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + from-절에서, FROM 키워드는 옵션이다 + </para> + </listitem> + <listitem> + <para> + from-절 내에 한 개의 명명된 엔티티가 오직 존재할 수 있다; 그것은 선택적으로 alias될 수 있다. 만일 엔티티 + 이름이 alias되면, 그때 임의의 프로퍼티 참조들은 그 alias를 사용하여 수식되어야 한다; 만일 엔티티 이름이 + alias되지 않을 경우, 임의의 프로퍼티 참조들에 대해 수식되는 것은 규칙에 어긋난다. + </para> + </listitem> + <listitem> + <para> + <xref linkend="queryhql-joins-forms">join들</xref>은 (함축적이든 명시적이든) + 대량 HQL 질의 속에 지정될 수 없다. 서브-질의들이 where-절에 사용될 수 있다; + 서브질의들 그 자신들은 조인들을 포함할 수 있다. + </para> + </listitem> + <listitem> + <para> + where-절 또한 옵션이다. + </para> + </listitem> + </itemizedlist> + + <para> + 하나의 예제로서, 한 개의 HQL <literal>UPDATE</literal>를 실행하기 위해, <literal>Query.executeUpdate()</literal> + 메소드(이 메소드는 JDBC의 <literal>PreparedStatement.executeUpdate()</literal>와 유사하게 명명된다)를 사용하라: + </para> + +<programlisting><![CDATA[Session session = sessionFactory.openSession(); +Transaction tx = session.beginTransaction(); + +String hqlUpdate = "update Customer c set c.name = :newName where c.name = :oldName"; +// or String hqlUpdate = "update Customer set name = :newName where name = :oldName"; +int updatedEntities = s.createQuery( hqlUpdate ) + .setString( "newName", newName ) + .setString( "oldName", oldName ) + .executeUpdate(); +tx.commit(); +session.close();]]></programlisting> + + <para> + HQL <literal>UPDATE</literal> 문장들은 디폴트로 영향받는 엔티티들에 대한 + <xref linkend="mapping-declaration-version">version</xref> 또는 + <xref linkend="mapping-declaration-timestamp">timestamp</xref> 프로퍼티 값들에 영향을 주지 않는다; + 이것은 EJB3 명세서에서 유지되고 있다. 하지만 당신은 하이버네이트로 하여금 <literal>versioned update</literal>의 + 사용을 통해 <literal>version</literal> 또는 <literal>timestamp</literal> 프로퍼티 값들을 적절하게 + 재설정하도록 강제할 수 있다. 이것은 <literal>UPDATE</literal> 키워드 뒤에 <literal>VERSIONED</literal> 키워드를 + 추가시켜서 성취된다. + </para> +<programlisting><![CDATA[Session session = sessionFactory.openSession(); +Transaction tx = session.beginTransaction(); +String hqlVersionedUpdate = "update versioned Customer set name = :newName where name = :oldName"; +int updatedEntities = s.createQuery( hqlUpdate ) + .setString( "newName", newName ) + .setString( "oldName", oldName ) + .executeUpdate(); +tx.commit(); +session.close();]]></programlisting> + + <para> + 맞춤형 version 타입들(<literal>org.hibernate.usertype.UserVersionType</literal>)은 + <literal>update versioned</literal> 문장과 함께 사용하는 것이 허용되지 않음을 노트하라. + </para> + + <para> + HQL <literal>DELETE</literal>를 실행하려면, 같은 메소드 <literal>Query.executeUpdate()</literal>를 + 사용하라: + </para> + +<programlisting><![CDATA[Session session = sessionFactory.openSession(); +Transaction tx = session.beginTransaction(); + +String hqlDelete = "delete Customer c where c.name = :oldName"; +// or String hqlDelete = "delete Customer where name = :oldName"; +int deletedEntities = s.createQuery( hqlDelete ) + .setString( "oldName", oldName ) + .executeUpdate(); +tx.commit(); +session.close();]]></programlisting> + + <para> + <literal>Query.executeUpdate()</literal> 메소드에 의해 반환되는 <literal>int</literal> 값은 그 오퍼레이션에 의해 + 영향받은 엔티티들의 개수를 나타낸다. 이것이 데이터베이스 내에서 영향받은 행들의 개수와 상관이 있는지 없는지 여부를 살펴보자. HQL + 대량 오퍼레이션은 예를 들어 joined-subclass의 경우에 실행 중인 여러 개의 실제 SQL 문장들로 귀결될 수 있다. 반환되는 숫자는 + 그 문장에 의해 영향받은 실제 엔티티들의 개수를 나타낸다. joined-subclass 예제로 되돌아가면, 서브 클래스들 중 하나에 대한 삭제는 + 단지 그 서브클래스가 매핑되어 있는 테이블에 대한 삭제 뿐만 아니라 또한 "루트" 테이블과 상속 계층에서 더 내려온 잠정적으로 + 조인된-서브클래스 테이블들에 대한 삭제들로 귀결될 수 있다. + </para> + + <para> + 장래의 배포본들에서 전달될 대량 HQL 오퍼레이션들에 대한 몇 가지 제한들이 현재 존재함을 노트하라; 상세한 것은 JIRA 로드맵을 참조하라. + <literal>INSERT</literal> 문장들을 위한 유사-구문은 다음과 같다: + <literal>INSERT INTO EntityName properties_list select_statement</literal>. 노트할 몇 가지: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + 오직 INSERT INTO ... SELECT ... 형식 만일 지원된다; INSERT INTO ... VALUES ... 형식은 지원되지 않는다. + </para> + <para> + properties_list는 SQL <literal>INSERT</literal> 내에서 <literal>column speficiation</literal>과 유사하다. + 매핑된 상속에 참여하는 엔티티들의 경우, 그 주어진 클래스-레벨 상에 직접 정의된 프로퍼티들 만이 properties_list에 사용될 수 있다. + 슈퍼클래스 프로퍼티들은 허용되지 않는다; 그리고 서브클래스 프로퍼티들은 의미가 없다. 달리 말해 <literal>INSERT</literal> 문장들은 + 본래적으로 다형적이지 않다. + </para> + </listitem> + <listitem> + <para> + select_statement는 반환 타입들이 insert에 의해 기대되는 타입들과 일치해야 한다는 단서 하에 임의의 유효한 HQL select 질의일 수 + 있다. 현재 이것은 체크를 데이터베이스로 이관시키는 것을 허용하기 보다는 질의 컴파일 동안에 체크된다. 하지만 이것은 + <emphasis>equal</emphasis>과는 대조적으로 <emphasis>등가인(equivalent)</emphasis> Hibernate <literal>Type</literal>들 + 사이에서 문제점들을 일으킬 수도 있음을 노트하라. 비록 데이터베이스가 구별짓지 않을 수 있거나 변환을 처리할 수 있을 지라도, 이것은 + <literal>org.hibernate.type.DateType</literal>로서 정의된 프로퍼티와 <literal>org.hibernate.type.TimestampType</literal>으로 + 정의된 프로퍼티 사이에 불일치 쟁점들을 일으킨다. + </para> + </listitem> + <listitem> + <para> + id 프로퍼티의 경우, insert 문장은 당신에게 두 개의 옵션을 준다. 당신은 properties_list 내에 id 프로퍼티를 명시적으로 + 지정할 수 있거나(그것의 값이 대응하는 select 표현식으로부터 얻어진 경우) 또는 properties_list에서 그것을 생략할 수도 있다 + (산출된 값이 사용되는 경우). 이 후자의 옵션은 데이터베이스 내에서 연산되는 id 연산자들을 사용할 때에만 이용 가능하다; + 임의의 "메모리 내" 타입 연산자들과 함께 이 옵션을 사용하려고 시도하는 것은 파싱 동안에 예외상황을 일으킬 것이다. 이 논의의 + 목적 상, 데이터베이스 내 산출자(generator)들은 <literal>org.hibernate.id.SequenceGenerator</literal> + (그리고 그것의 서브클래스들) 그리고 임의의 <literal>org.hibernate.id.PostInsertIdentifierGenerator</literal>의 + 구현자들이라고 간주됨을 노트하라. 여기서 가장 주목할 만한 예외상황은 그것이 그것의 값들을 얻기 위한 select 가능한 방법을 + 노출시키지 않기 때문ㅇ에 사용될 수 없는 <literal>org.hibernate.id.TableHiLoGenerator</literal>이다. + </para> + </listitem> + <listitem> + <para> + <literal>version</literal> 또는 <literal>timestamp</literal>로서 매핑된 프로퍼티들의 경우에, + insert 문장은 당신에게 두 개의 옵션들을 준다. 당신은 properties_list 내에 그 프로퍼티를 지정할 수 있거나 + (그 것의 값이 대응하는 select 표현식으로부터 얻어진 경우) 또는 properties_list에서 그것을 생략할 수 있다 + (<literal>org.hibernate.type.VersionType</literal>에 의해 정의된 <literal>seed value</literal> + 값이 사용되는 경우). + </para> + </listitem> + </itemizedlist> + + <para> + 예제 HQL <literal>INSERT</literal> 문장 실행: + </para> + +<programlisting><![CDATA[Session session = sessionFactory.openSession(); +Transaction tx = session.beginTransaction(); + +String hqlInsert = "insert into DelinquentAccount (id, name) select c.id, c.name from Customer c where ..."; +int createdEntities = s.createQuery( hqlInsert ) + .executeUpdate(); +tx.commit(); +session.close();]]></programlisting> + + </sect1> + +</chapter> Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/best_practices.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/best_practices.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/best_practices.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/best_practices.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,204 @@ +<chapter id="best-practices" revision="3"> + <title>최상의 실전 경험들</title> + + <variablelist spacing="compact"> + <varlistentry> + <term>fine-grained 클래스들을 작성하고 <literal>&lt;component&gt;</literal>를 사용하여 그것들을 매핑하라. </term> + <listitem> + <para> + <literal>street</literal>, <literal>suburb</literal>, <literal>state</literal>, <literal>postcode</literal>를 + 캡슐화 시키는데 <literal>Address</literal> 클래스를 사용하라. 이것은 코드 재사용성을 촉진시키고 리팩토링을 단순화 시킨다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>영속 클래스들에 대해 식별자 프로퍼티들을 선언하라.</term> + <listitem> + <para> + Hibernate는 식별자 프로퍼티들을 옵션으로 만든다. 왜 우리가 그것들을 사용해야 하는가에 대한 모든 종류의 이유들이 존재한다. + 우리는 식별자들이 '합성(synthetic)'이 되는(비지니스 의미 없이 생성되는) 것을 권장한다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>고유 키들을 식별하라.</term> + <listitem> + <para> + 모든 엔티티들에 대해 고유 키들을 식별하고, <literal>&lt;natural-id&gt;</literal>를 사용하여 그것들을 매핑하라. + 고유 키를 구성하는 프로퍼티들을 비교하기 위해 <literal>equals()</literal>와 <literal>hashCode()</literal>를 + 구현하라. + </para> + </listitem> + </varlistentry> + <varlistentry><term>각각의 클래스 매핑을 그것 자신의 파일 내에 위치지워라.</term> + <listitem> + <para> + 하나의 한덩어리 매핑 문서를 사용하지 말라. <literal>com/eg/Foo.hbm.xml</literal> 파일 속에 + <literal>com.eg.Foo</literal>를 매핑하라. 이것은 팀 환경에서 특히 좋은 의미를 준다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>매핑들을 리소스들로서 로드시켜라.</term> + <listitem> + <para> + 그것들이 매핑하는 클래스들에 따라서 매핑들을 배치하라 + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>질의 문자열들을 객관화 시키는 것을 고려하라.</term> + <listitem> + <para> + 당신의 질의들이 ANSI 표준이 아닌 SQL 함수들을 호출하는 경우는 좋은 실전연습이다. 질의 문자열들을 매핑 파일들에다가 + 외부화 시키는 것은 어플리케이션을 보다 이식성 있도록 만들어줄 것이다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>바인드 변수들을 사용하라.</term> + <listitem> + <para> + JDBC에서처럼, 상수 아닌 값들을 "?"로 대체시켜라. 질의 속에 상수 아닌 값을 바인드 시키는데 문자열 처리를 결코 + 사용하지 말라! 더 좋게는 질의들 속에 명명된 파라미터들을 사용하는 것을 고려하라. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>당신 자신의 JDBC 커넥션들을 관리하지 말라.</term> + <listitem> + <para> + Hibernate는 어플리케이션으로 하여금 JDBC 커넥션들을 관리하도록 한다. 이 접근법은 마지막 수단으로서 고려되어야 한다. + 만일 당신이 미리 만들어진 커넥션 프로바이더들을 사용할 수 없을 경우, <literal>org.hibernate.connection.ConnectionProvider</literal>에 + 대한 당신 자신의 구현을 제공하는 것을 고려하라. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>맞춤형 타입 사용을 고려하라.</term> + <listitem> + <para> + 당신이 자바 타입을 갖고 있고, 어떤 라이브러리로부터 말하고, 그것이 영속화 될 필요가 있지만 그것을 컴포넌트로서 매핑시키는데 + 필요한 accessor들을 제공할 필요가 없다고 가정하자. 당신은 <literal>org.hibernate.UserType</literal>을 구현하는 + 것을 고려해야 할 것이다. 이 접근법은 Hibernate 타입으로/으로부터 변환들을 구현하는 것으로부터 어플리케이션 코드를 자유롭게 + 해준다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>병목 지점들에서 수작업으로 코딩된 JDBC를 사용하라.</term> + <listitem> + <para> + 시스템의 퍼포먼스가 중대한 영역들에서, 몇몇 종류의 오퍼레이션들은 직접적인 JDBC에서 이득을 본다. 그러나 당신이 어떤 것이 병목인지를 + <emphasis>알기</emphasis> 전까지 기다리길 바란다. 그리고 직접적인 JDBC가 반드시 더 빠르다고 가정하지 말라. 만일 당신이 직접적인 + JDBC를 사용할 필요가 있을 경우, Hibernate <literal>Session</literal>을 열고 그 SQL 커넥션을 사용할 가치가 있다. 그 방법으로 + 당신은 동일한 트랜잭션 방도와 기본 커넥션 프로바이더를 여전히 사용할 수 있다 + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>Session</literal> flushing을 이해하라.</term> + <listitem> + <para> + 시간이 지남에 따라 Session은 그것의 영속 상태를 데이터베이스와 동기화 시킨다. 만일 이 과정이 너무 자주 발생할 경우 퍼포먼스가 + 영향을 받을 것이다. 당신은 때때로 자동적인 flushing을 사용 불가능하게 만들거나 특정 트랜잭션 내에서 질의들의 순서와 다른 + 오퍼레이션들의 순서를 변경시켜서 불필요한 flushing을 최소화 시킬 수 있다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>3-tier 아키텍처에서, <literal>saveOrUpdate()</literal> 사용을 고려하라.</term> + <listitem> + <para> + servlet / session 빈 아키텍처를 사용할 때, 당신은 sesson bean 내에 로드된 영속 객체들을 서블릿/JSP 계층으로/으로부터 + 전달할/받을 수 있다. 각각의 요청을 서비스하는데 새로운 세션을 사용하라. 객체들을 데이터베이스와 동기화 시키기 위해서 + <literal>Session.merge()</literal> 또는 <literal>Session.saveOrUpdate()</literal>를 사용하라. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>2-tier 아키텍처에서, 수명이 긴 영속 컨텍스트들을 사용하는 것을 고려하라.</term> + <listitem> + <para> + 데이터베이스 트랜잭션들은 최상의 가용성을 위해 가능한 한 짧아야 한다. 하지만 장기간 실행되는 <emphasis>어플리케이션 트랜잭션들</emphasis>, + 사용자의 뷰 관점에서 한 개의 단위 작업을 구현하는 것이 가끔 필수적이다. 하나의 어플리케이션 트랜잭션은 몇 개의 클라이언트 요청들과 + 응답 주기들에 걸칠 수도 있다. 어플리케이션 트랜잭션들을 구현하는데 detached 객체들을 사용하는 것이 공통적이다. 2-티어 아키텍처에서 + 매우 적절한 대안은 어플리케이션 트랜잭션의 전체 생명주기 동안에 한 개의 열려진 영속 접속 (세션)을 유지하는 것이고 각각의 요청의 끝에서 + JDBC 커넥션을 간단하게 연결해제하고 차후의 요청의 시작 시에 다시 연결하는 것이다. 한 개 이상의 어플리케이션 트랜잭션을 가로질러서 + 하나의 단일 세션을 결코 공유하지 말라. 공유할 경우에 당신은 실효성이 없는 데이터로 작업하게 될 것이다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>예외상황들을 복구가능한 것으로서 다루지 말라.</term> + <listitem> + <para> + 이것은 "최상의" 실전이 아닌 보다 필수적인 실전이다. 예외상황이 발생할 때, <literal>Transaction</literal>을 롤백시키고 + <literal>Session</literal>을 닫아라. 만일 당신이 그렇게 하지 않을 경우, Hibernate는 메모리 내 상태가 영속 상태를 정확하게 + 표현하는 것을 보증할 수 없다. 이 특별한 경우처럼, 만일 주어진 식별자를 가진 인스턴스가 데이터베이스 상에 존재하는지 여부를 결정하는데 + <literal>Session.load()</literal>를 사용하지 말라; 대신에 <literal>Session.get()</literal> 또는 하나의 질의를 + 사용하라. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>연관들에 대한 lazy 페칭을 선호하라.</term> + <listitem> + <para> + eager 페칭을 관대하게 사용하라. second-level 캐시 내에 완전하게 보관되지 않을 것 같은 클래스들에 대한 대붑분의 연관들에 + 대해 프락시들과 lazy 콜렉션들을 사용하라. 캐시된 클래스들에 대한 연관들의 경우, 이곳은 캐시 성공의 매우 높은 확률이 존재하는 + 곳이며, <literal>lazy="false"</literal>를 사용하여 eager 페칭을 명시적으로 사용 불가능하게 하라. 한의 join 페칭이 + 특정 쓰임새에 대해 적절할 때, 하나의 <literal>left join fetch</literal>를 가진 질의를 사용하라. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + 페치되지 않은 데이터 문제점들을 피하기 위해 <emphasis>뷰 내에 열려진 세션(open session in view)</emphasis> 패턴 또는 + 하나의 정리된 <emphasis>어셈블리 단계(assembly phase)</emphasis>를 사용하라. + </term> + <listitem> + <para> + Hibernate는 개발자들이 <emphasis>Data Transfer Objects</emphasis> (DTO)를 지루하게 작성하는 것으로부터 + 자유롭게 해준다. 전통적인 EJB 아키텍처에서, DTO는 이중 용도로 기능한다: 첫 번째로 그것들은 엔티티 빈즈가 직렬화 가능하지 않는 + 문제점에 대해 착수한다; 두 번째로 그것들은 뷰에 의해 사용되는 모든 데이터가 프리젠테이션 티어로 컨트롤을 반환하기 전에 DTO들 속으로 + 페치되고 마샬링되는 어셈블리 단계를 암묵적으로 정의한다. Hibernate는 첫 번째 용도를 제거시킨다. 하지만 당신이 뷰 렌더링 프로세스를 + 가로질러 열려져 있는 영속 컨텍스트(세션)을 보관할 준비가 되어 있지 않는 한, 당신은 여전히 어셈블리 단계를 필요로 할 것이다(detached + 객체들에서 이용가능한 데이터가 무엇인지에 대해 프리젠테이션 티어와 엄격하게 계약을 갖도록 당신의 비지니스 메소드들을 고려하라) + 이것은 Hibernate의 한계점이 아니다! 그것은 안전한 트랜잭션 데이터 접근의 필수 조건이다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>Hibernate에서 당신의 비지니스 로직을 추상화 시키는 것을 고려하라.</term> + <listitem> + <para> + (Hibernate) 데이터 액세스 코드를 인터페이스 이면에 은폐시켜라. <emphasis>DAO</emphasis>와 + <emphasis>Thread Local Session</emphasis> 패턴들을 결합시켜라. 당신은 심지어 <literal>UserType</literal>을 + 통해 Hibernate에 연관된, 수작업으로 코딩된 JDBC로서 몇몇 클래스들을 영속화 시킬 수도 있다. (이 충고는 "충분히 큰" + 어플리케이션들에 대한 것이다; 그것은 5개의 테이블들을 가진 어플리케이션에 대해서는 적절하지 않다!) + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>신종의 연관 매핑을 사용하지 말라.</term> + <listitem> + <para> + 실제의 many-to-many 연관들에 대한 좋은 쓰임새들은 드물다. 대부분의 시간 동안 당신은 "연결 테이블" 내에 저장된 추가적인 정보를 필요로 한다. + 이 경우에, 매개하는 연결 클래스에 대해 두 개의 one-to-many 연관들을 사용하는 것이 훨씬 더 좋다. 사실 우리는 대부분의 연관들이 one-to-many와 + many-to-one이라고 생각하며, 당신은 다른 연관 스타일을 사용할 때 주의해야 하고 그것이 진정 필수적인지를 당신 스스로 질문하라. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>양방향 연관들을 선호하라.</term> + <listitem> + <para> + 단방향 연관들은 질의하기가 더 어렵다. 많은 어플리케이션에서, 거의 모든 연관들은 질의들 내에서 양 방향으로 네비게이트 가능해야 한다. + </para> + </listitem> + </varlistentry> + </variablelist> + +</chapter> + Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/collection_mapping.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/collection_mapping.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/collection_mapping.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/collection_mapping.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,1158 @@ +<chapter id="collections"> + <title>콜렉션 매핑</title> + + <sect1 id="collections-persistent" revision="3"> + <title>영속 콜렉션들</title> + + <para> + 예를 들어 Hibernate는 영속 콜렉션-값을 가진 필드들이 인터페이스 타입으로서 선언될 것을 필요로 한다: + </para> + + <programlisting><![CDATA[public class Product { + private String serialNumber; + private Set parts = new HashSet(); + + public Set getParts() { return parts; } + void setParts(Set parts) { this.parts = parts; } + public String getSerialNumber() { return serialNumber; } + void setSerialNumber(String sn) { serialNumber = sn; } +}]]></programlisting> + + <para> + 실제 인터페이스는 <literal>java.util.Set</literal>, <literal>java.util.Collection</literal>, + <literal>java.util.List</literal>, <literal>java.util.Map</literal>, <literal>java.util.SortedSet</literal>, + <literal>java.util.SortedMap</literal> 또는 당신이 좋아하는 어떤 것일 수 있다!(여기서 "당신이 좋아하는 어떤 것"이란 + 당신이 <literal>org.hibernate.usertype.UserCollectionType</literal>에 대한 구현을 작성해야 함을 의미한다.) + </para> + + <para> + 우리가 <literal>HashSet</literal>의 인스턴스를 가진 인스턴스 변수를 초기화 시켰던 방법을 주목하라. 이것은 새로이 + 초기화 된(비-영속) 인스턴스들을 가진 콜렉션 값 프로퍼티들을 초기화 시키는 최선의 방법이다. 당신이 -예를 들어 + <literal>persist()</literal>를 호출하여- 인스턴스를 영속화 시킬 때 Hibernate는 실제로 <literal>HashSet</literal>을 + <literal>Set</literal>에 대한 Hibernate 자신의 구현의 인스턴스로 대체시킬 것이다. 다음과 같은 오류들을 관찰하라: + </para> + + <programlisting><![CDATA[Cat cat = new DomesticCat(); +Cat kitten = new DomesticCat(); +.... +Set kittens = new HashSet(); +kittens.add(kitten); +cat.setKittens(kittens); +session.persist(cat); +kittens = cat.getKittens(); // Okay, kittens collection is a Set +(HashSet) cat.getKittens(); // Error!]]></programlisting> + + <para> + Hibernate에 의해 도입된 영속 콜렉션들은 인터페이스 타입에 따라 <literal>HashMap</literal>, <literal>HashSet</literal>, + <literal>TreeMap</literal>, <literal>TreeSet</literal> 또는 <literal>ArrayList</literal>와 같이 행위한다. + </para> + + <para> + 콜렉션 인스턴스들은 value 타입들을 가진 통상의 특징을 갖는다. 그것들은 영속 객체에 의해 참조될 때 자동적으로 영속화 되고 + 참조 해제될 때 자동적으로 삭제된다. 만일 하나의 콜렉션이 하나의 영속 객체로부터 또 다른 영속 객체로 전달될 때, 그것의 요소들은 + 하나의 테이블로부터 다른 테이블로 이동될 수 있다. 두 개의 엔티티들은 동일한 콜렉션 인스턴스에 대한 참조를 공유하지 않는다. + 기본 관계형 모형 때문에 콜렉션 값 프로퍼티들은 null 값 의미들을 지원하지 않는다; Hibernate는 null 콜렉션 참조와 공백의 + 콜렉션 사이를 구별 짓지 않는다. + </para> + + <para> + 당신은 이것의 어떤 것에 대해 너무 많이 걱정하지 않아도 될 것이다. 당신이 통상의 자바 콜렉션들을 사용하는 것과 동일한 방법으로 + 영속 콜렉션들을 사용하라. 단지 당신이 양방향 연관관계들에 대한 의미를 확실히 이해하도록 하라(나중에 논의됨). + </para> + + </sect1> + + <sect1 id="collections-mapping" revision="4"> + <title>콜렉션 매핑들</title> + + <para> + 콜렉션을 매핑하는데 사용되는 Hiberante 매핑 요소는 인터페이스의 타입에 의존한다. 예를 들어<literal>&lt;set&gt;</literal> + 요소는 <literal>Set</literal> 타입의 매핑 프로퍼티들에 사용된다 + </para> + + <programlisting><![CDATA[<class name="Product"> + <id name="serialNumber" column="productSerialNumber"/> + <set name="parts"> + <key column="productSerialNumber" not-null="true"/> + <one-to-many class="Part"/> + </set> +</class>]]></programlisting> + + <para> + <literal>&lt;set&gt;</literal>과는 별도로, 또한 <literal>&lt;list&gt;</literal>, <literal>&lt;map&gt;</literal>, + <literal>&lt;bag&gt;</literal>, <literal>&lt;array&gt;</literal>, 그리고 <literal>&lt;map&gt;</literal> + 매핑 요소들이 존재한다. <literal>&lt;map&gt;</literal> 요소가 대표적이다: + </para> + + <programlistingco> + <areaspec> + <area id="mappingcollection1" coords="2 65"/> + <area id="mappingcollection2" coords="3 65"/> + <area id="mappingcollection3" coords="4 65"/> + <area id="mappingcollection4" coords="5 65"/> + <area id="mappingcollection5" coords="6 65"/> + <area id="mappingcollection6" coords="7 65"/> + <area id="mappingcollection7" coords="8 65"/> + <area id="mappingcollection8" coords="9 65"/> + <area id="mappingcollection9" coords="10 65"/> + <area id="mappingcollection10" coords="11 65"/> + <area id="mappingcollection11" coords="12 65"/> + <area id="mappingcollection12" coords="13 65"/> + <area id="mappingcollection13" coords="14 65"/> + <area id="mappingcollection14" coords="15 65"/> + </areaspec> + <programlisting><![CDATA[<map + name="propertyName" + table="table_name" + schema="schema_name" + lazy="true|extra|false" + inverse="true|false" + cascade="all|none|save-update|delete|all-delete-orphan|delete-orphan" + sort="unsorted|natural|comparatorClass" + order-by="column_name asc|desc" + where="arbitrary sql where condition" + fetch="join|select|subselect" + batch-size="N" + access="field|property|ClassName" + optimistic-lock="true|false" + mutable="true|false" + node="element-name|." + embed-xml="true|false" +> + + <key .... /> + <map-key .... /> + <element .... /> +</map>]]></programlisting> + <calloutlist> + <callout arearefs="mappingcollection1"> + <para> + <literal>name</literal> 콜렉션 프로퍼티 이름 + </para> + </callout> + <callout arearefs="mappingcollection2"> + <para> + <literal>table</literal> (옵션 - 디폴트는 프로퍼티 이름) + 콜렉션 테이블의 이름(one-to-many 연관관계들에 대해서는 사용되지 않음) + </para> + </callout> + <callout arearefs="mappingcollection3"> + <para> + <literal>schema</literal> (옵션) + 루트 요소 상에 선언된 스키마를 오버라이드 시키는 테이블 스키마의 이름 + </para> + </callout> + <callout arearefs="mappingcollection4"> + <para> + <literal>lazy</literal> (옵션 - 디폴트는 <literal>true</literal>)는 + lazy 페칭을 사용 불가능하도록 하고 그 연관이 항상 eagerly 페치됨을 지정하는데 , 또는 대부분의 + 연산들이 콜렉션을 초기화시키지 않는 곳에서 "extra-lazy" 페칭을 이용 가능하도록 하는데(매우 큰 콜렉션들에 + 적당함) 사용될 수 있다 + </para> + </callout> + <callout arearefs="mappingcollection5"> + <para> + <literal>inverse</literal> (옵션 - 디폴트는 <literal>false</literal>) + 이 콜렉션을 양방향 연관관계의 "inverse" 끝(end)으로 표시한다 + </para> + </callout> + <callout arearefs="mappingcollection6"> + <para> + <literal>cascade</literal> (옵션 - 디폴트는 <literal>none</literal>) + 오퍼레이션들이 자식 엔티티들에 대해 케스케이드하는 것을 이용 가능하게 한다 + </para> + </callout> + <callout arearefs="mappingcollection7"> + <para> + <literal>sort</literal> (옵션) + <literal>natural</literal> 정렬 순서로 정렬된(sorted) 콜렉션 또는 주어진 comparator 클래스를 지정한다 + </para> + </callout> + <callout arearefs="mappingcollection8"> + <para> + <literal>order-by</literal> (옵션, JDK1.4에서만) + <literal>asc</literal> 또는 <literal>desc</literal> 옵션과 함께 <literal>Map</literal>, + <literal>Set</literal> 또는 bag의 반복 순서를 정의하는 테이블 컬럼(또는 컬럼들)을 지정한다 + </para> + </callout> + <callout arearefs="mappingcollection9"> + <para> + <literal>where</literal> (옵션) + 콜렉션을 검색하거나 제거할 때 사용될 임의적인 SQL <literal>WHERE</literal> 조건을 지정한다 + (콜렉션이 오직 이용 가능한 데이터의 부분집합 만을 포함할 경우에 유용하다) + </para> + </callout> + <callout arearefs="mappingcollection10"> + <para> + <literal>fetch</literal> (옵션, 디폴트는 <literal>select</literal>) + outer-join 페칭, sequential select 페칭, 그리고 sequential subselect 페칭 사이에서 선택하라. + </para> + </callout> + <callout arearefs="mappingcollection11"> + <para> + <literal>batch-size</literal> (옵션, 디폴트는 <literal>1</literal>) + 이 콜렉션의 lazily fetching 인스턴스에 대해 "배치 사이즈"를 지정하라. + </para> + </callout> + <callout arearefs="mappingcollection12"> + <para> + <literal>access</literal> (옵션 - 디폴트는 <literal>property</literal>): + Hibernate가 콜렉션 프로퍼티 값에 접근하는데 사용할 방도. + </para> + </callout> + <callout arearefs="mappingcollection13"> + <para> + <literal>optimistic-lock</literal> (옵션 - 디폴트는 <literal>true</literal>): + 콜렉션의 상태에 대한 변경들이 소유하는 엔티티의 버전의 증가로 귀결될 것인지를 지정한다. + (one to many 연관들에 대해, 이 설정을 사용 불가능하게 하는 것이 종종 합당하다.) + </para> + </callout> + <callout arearefs="mappingcollection14"> + <para> + <literal>mutable</literal> (옵션 - 디폴트는 <literal>true</literal>): + <literal>false</literal> 값은 콜렉션의 요소들이 결코 변경되지 않음을 지정한다. + (몇몇 경우들에서 마이너 퍼포먼스 최적화). + </para> + </callout> + </calloutlist> + </programlistingco> + + <sect2 id="collections-foreignkeys" > + <title>콜렉션 foreign 키들</title> + + <para> + 콜렉션 인스턴스들은 그 콜렉션을 소유하는 엔티티의 foreign 키에 의해 데이터베이스 내에서 구별지워진다. 이 foreign 키는 + 그 콜렉션 테이블의 <emphasis>콜렉션 키 컬럼</emphasis> (또는 컬럼들)로서 참조된다. 그 콜렉션 키 컬럼은 + <literal>&lt;key&gt;</literal> 요소에 의해 매핑된다. + </para> + + <para> + foreign 키 컬럼에 대한 null 허용 가능 컨스트레인트가 존재할 수 있다. 대부분의 콜렉션들에 대해, 이것이 당연히 수반된다. + 단방향 one to many 연관들의 경우, foreign 키는 디폴트로 null 허용 가능하여서, 당신은 <literal>not-null="true"</literal>를 + 지정할 필요가 있을 수 있다. + </para> + + <programlisting><![CDATA[<key column="productSerialNumber" not-null="true"/>]]></programlisting> + + <para> + foreign 키 컨스트레인트는 <literal>ON DELETE CASCADE</literal>를 사용할 수도 있다. + </para> + + <programlisting><![CDATA[<key column="productSerialNumber" on-delete="cascade"/>]]></programlisting> + + <para> + <literal>&lt;key&gt;</literal> 요소에 대한 전체 정의는 앞 장을 보라. + </para> + + </sect2> + + <sect2 id="collections-elements" > + <title>콜렉션 요소들</title> + + <para> + 콜렉션들은 모든 기본 타입들, 컴포넌트들, 그리고 물론 다른 엔티티들에 대한 참조들을 포함하여 거의 대부분의 + 어떤 다른 Hibernate 타입을 포함할 수도 있다. 이것은 중요한 구분이다: 콜렉션 내에 있는 객체는 "값(value)" + 의미로 처리될 수도 있거나(그것의 생명주기는 콜렉션 소유자에 의존한다) 그것은 그것 자신의 생명주기를 가진 + 또 다른 엔티티에 대한 참조일 수 있다. 후자의 경우, 두 개의 객체들 사이의 "링크" 만이 그 콜렉션에 의해 소유된 + 상태로 간주된다. + </para> + + <para> + 포함된 타입은 콜렉션 요소 타입으로서 불려진다. 콜렉션 요소들은 <literal>&lt;element&gt;</literal> + 또는 <literal>&lt;composite-element&gt;</literal>에 의해 매핑되거나, 엔티티 참조들의 경우에 + <literal>&lt;one-to-many&gt;</literal> 또는 <literal>&lt;many-to-many&gt;</literal>로서 + 매핑된다. 앞의 두 개는 value 의미를 가진 요소들을 매핑시키고, 뒤의 두개는 엔티티 연관들을 매핑하는데 사용된다. + </para> + + </sect2> + + <sect2 id="collections-indexed"> + <title>인덱싱 된 콜렉션들</title> + + <para> + set 과 bag 의미들을 가진 것들을 제외하면, 모든 콜렉션 매핑들은 콜렉션 테이블 내에 <emphasis>인덱스 컬럼</emphasis>- + 배열 인덱스, 또는 <literal>List</literal> 인덱스 또는 <literal>Map</literal> 키로 매핑되는 컬럼-을 필요로 한다. + <literal>Map</literal>의 인덱스는 <literal>&lt;map-key&gt;</literal>로 매핑된, 어떤 기본 타입일 수 있고, + 그것은 <literal>&lt;map-key-many-to-many&gt;</literal>로 매핑된 엔티티 참조일 수 있거나, 그것은 + <literal>&lt;composite-map-key&gt;</literal>로 매핑된 composite 타입일 수 있다. 배열 또는 리스트의 인덱스는 + 항상 <literal>integer</literal> 타입이고 <literal>&lt;list-index&gt;</literal> 요소를 사용하여 매핑된다. + 매핑된 컬럼은 순차적인 정수들을 포함한다(디폴트로 0에서 시작하는 번호가 붙여짐). + </para> + + <programlistingco> + <areaspec> + <area id="index1" coords="2 45"/> + <area id="index2" coords="3 45"/> + </areaspec> + <programlisting><![CDATA[<list-index + column="column_name" + base="0|1|..."/>]]></programlisting> + <calloutlist> + <callout arearefs="index1"> + <para> + <literal>column_name</literal> (필수): + 콜렉션 인덱스 값들을 보관하는 컬럼의 이름. + </para> + </callout> + <callout arearefs="index1"> + <para> + <literal>base</literal> (옵션, 디폴트는 <literal>0</literal>): + 리스트 또는 배열의 첫 번째 요소에 대응하는 인덱스 컬럼의 값. + </para> + </callout> + </calloutlist> + </programlistingco> + + <programlistingco> + <areaspec> + <area id="mapkey1" coords="2 45"/> + <area id="mapkey2" coords="3 45"/> + <area id="mapkey3" coords="4 45"/> + </areaspec> + <programlisting><![CDATA[<map-key + column="column_name" + formula="any SQL expression" + type="type_name" + node="@attribute-name" + length="N"/>]]></programlisting> + <calloutlist> + <callout arearefs="mapkey1"> + <para> + <literal>column</literal> (옵션): + 콜렉션 인덱스 값들을 보관하는 컬럼의 이름. + </para> + </callout> + <callout arearefs="mapkey2"> + <para> + <literal>formula</literal> (옵션): + map의 키를 평가하는데 사용되는 SQL formula. + </para> + </callout> + <callout arearefs="mapkey3"> + <para> + <literal>type</literal> (필수): The type of the map 키들의 타입 + </para> + </callout> + </calloutlist> + </programlistingco> + + <programlistingco> + <areaspec> + <area id="indexmanytomany1" coords="2 45"/> + <area id="indexmanytomany2" coords="3 45"/> + <area id="indexmanytomany3" coords="3 45"/> + </areaspec> + <programlisting><![CDATA[<map-key-many-to-many + column="column_name" + formula="any SQL expression" + class="ClassName" +/>]]></programlisting> + <calloutlist> + <callout arearefs="indexmanytomany1"> + <para> + <literal>column</literal> (옵션): + 콜렉션 인덱스 값들에 대한 foreign 키 컬럼의 이름. + </para> + </callout> + <callout arearefs="indexmanytomany2"> + <para> + <literal>formula</literal> (옵션): + map의 foreign 키를 평가하는데 사용되는 SQL formula. + </para> + </callout> + <callout arearefs="indexmanytomany3"> + <para> + <literal>class</literal> (필수): map 키로서 사용되는 엔티티 클래스. + </para> + </callout> + </calloutlist> + </programlistingco> + + + <para> + 만일 당신의 테이블이 인덱스 컬럼을 가지 않고, 당신이 여전히 프로퍼티 타입으로서 <literal>List</literal>를 사용하고자 + 원할 경우, 당신은 그 프로퍼티를 Hibernate <emphasis>&lt;bag&gt;</emphasis>으로서 매핑해야 한다. bag이 + 데이터베이스로부터 검색될 때 그것은 그것의 순서를 보유하지 않지만, 그것은 선택적으로 정렬(sorting)되거나 ordering될 + 수도 있다. + </para> + + </sect2> + + <para> + 많은 공통된 관계형 모형들을 다루는, 콜렉션들에 대해 생성될 수 있는 매핑들의 영역이 꽤 존재한다. 여러가지 매핑 선언들이 데이터베이스 + 테이블들로 변환되는 방법을 당신이 느끼려면 스키마 생성 도구로 실험할 것을 우리는 제안한다. + </para> + + <sect2 id="collections-ofvalues" revision="2"> + <title>값들을 가진 콜렉션들과 many-to-many 연관들</title> + + <para> + 어떤 값들을 가진 콜렉션 또는 many-to-many 연관은 foreign 키 컬럼이나 컬럼들, <emphasis>콜렉션 요소 컬럼</emphasis>이나 + 컬럼들 그리고 가능하면 인덱스 컬럼들이나 컬럼들을 가진 전용 <emphasis>콜렉션 테이블</emphasis>을 필요로 한다. + </para> + + <para> + 값들을 가진 콜렉션의 경우, 우리는 <literal>&lt;element&gt;</literal> 태그를 사용한다. + </para> + + <programlistingco> + <areaspec> + <area id="element1b" coords="2 50"/> + <area id="element2b" coords="3 50"/> + <area id="element3b" coords="4 50"/> + </areaspec> + <programlisting><![CDATA[<element + column="column_name" + formula="any SQL expression" + type="typename" + length="L" + precision="P" + scale="S" + not-null="true|false" + unique="true|false" + node="element-name" +/>]]></programlisting> + <calloutlist> + <callout arearefs="element1b"> + <para> + <literal>column</literal> (옵션): 콜렉션 요소 값들을 소유하는 컬럼의 이름. + </para> + </callout> + <callout arearefs="element2b"> + <para> + <literal>formula</literal> (옵션): 요소를 평가하는데 사용되는 SQL formula. + </para> + </callout> + <callout arearefs="element3b"> + <para> + <literal>type</literal> (필수): 콜렉션 요소의 타입. + </para> + </callout> + </calloutlist> + </programlistingco> + + <para> + <emphasis>many-to-many association</emphasis> 연관은 <literal>&lt;many-to-many&gt;</literal> 요소를 + 사용하여 지정된다. + </para> + + <programlistingco> + <areaspec> + <area id="manytomany1" coords="2 60"/> + <area id="manytomany2" coords="3 60"/> + <area id="manytomany3" coords="4 60"/> + <area id="manytomany4" coords="5 60"/> + <area id="manytomany5" coords="6 60"/> + <area id="manytomany6" coords="7 60"/> + <area id="manytomany7" coords="8 60"/> + <area id="manytomany8" coords="9 60"/> + </areaspec> + <programlisting><![CDATA[<many-to-many + column="column_name" + formula="any SQL expression" + class="ClassName" + fetch="select|join" + unique="true|false" + not-found="ignore|exception" + entity-name="EntityName" + property-ref="propertyNameFromAssociatedClass" + node="element-name" + embed-xml="true|false" + />]]></programlisting> + <calloutlist> + <callout arearefs="manytomany1"> + <para> + <literal>column</literal> (옵션): 요소 foreign 키 컬럼의 이름. + </para> + </callout> + <callout arearefs="manytomany2"> + <para> + <literal>formula</literal> (옵션): 요소 foreign 키 값을 평가하는데 사용되는 SQL formula. + </para> + </callout> + <callout arearefs="manytomany3"> + <para> + <literal>class</literal> (필수): 연관된 클래스의 이름. + </para> + </callout> + <callout arearefs="manytomany4"> + <para> + <literal>fetch</literal> (옵션 - 디폴트는 <literal>join</literal>): + 이 연관에 대해 outer-join 페칭 또는 sequential select 페칭을 이용 가능하게 만든다. 이것은 특별한 경우이다; + 엔티티 그리고 다른 엔티티들과 그것의 many-to-many 관계들에 대한 (하나의 <literal>SELECT</literal> + 내에서) 전체 eager 페칭의 경우, 당신은 콜렉션 그 자체에 대해서 뿐만 아니라 내포된 요소 <literal>&lt;many-to-many&gt;</literal> + 상의 이 속성에 대해 <literal>join</literal> 페칭을 이용 가능하게 할 것이다. + </para> + </callout> + <callout arearefs="manytomany5"> + <para> + <literal>unique</literal> (옵션): + foreign-key 컬럼에 대한 유일 컨스트레인트의 DDL 생성을 가능하도록 한다. 이것은 연관 다중성 + (association multiplicity)을 효율적으로 one to many로 만든다. + </para> + </callout> + <callout arearefs="manytomany6"> + <para> + <literal>not-found</literal> (옵션 - 디폴트는 <literal>exception</literal>): + 누락된 행들을 참조하는 foreign 키들이 어떻게 처리될 것인지를 지정한다: + <literal>ignore</literal>는 누락된 한 행을 한 개의 연관으로 다룰 것이다. + </para> + </callout> + <callout arearefs="manytomany7"> + <para> + <literal>entity-name</literal> (옵션): <literal>class</literal>에 대한 하나의 대안으로서, + 연관된 클래스의 엔티티 이름. + </para> + </callout> + <callout arearefs="manytomany8"> + <para> + <literal>property-ref</literal>: (옵션) 이 foreign 키에 조인된 연관 클래스의 프로퍼티의 이름. + 지정되지 않을 경우, 연관 클래스의 프라이머리 키가 사용된다. + </para> + </callout> + </calloutlist> + </programlistingco> + + <para> + 몇몇 예제들, 먼저 문자열들을 가진 set: + </para> + + <programlisting><![CDATA[<set name="names" table="person_names"> + <key column="person_id"/> + <element column="person_name" type="string"/> +</set>]]></programlisting> + + <para> + (<literal>order-by</literal> 속성에 의해 결정되는 반복 순서를 가진) 정수들을 포함하는 bag : + </para> + + <programlisting><![CDATA[<bag name="sizes" + table="item_sizes" + order-by="size asc"> + <key column="item_id"/> + <element column="size" type="integer"/> +</bag>]]></programlisting> + + <para> + 엔티티들을 가진 배열 - 이 경우에, many to many 연관 : + </para> + + <programlisting><![CDATA[<array name="addresses" + table="PersonAddress" + cascade="persist"> + <key column="personId"/> + <list-index column="sortOrder"/> + <many-to-many column="addressId" class="Address"/> +</array>]]></programlisting> + + <para> + 날짜들에 대한 문자열 인덱스들을 가진 map : + </para> + + <programlisting><![CDATA[<map name="holidays" + table="holidays" + schema="dbo" + order-by="hol_name asc"> + <key column="id"/> + <map-key column="hol_name" type="string"/> + <element column="hol_date" type="date"/> +</map>]]></programlisting> + + <para> + 컴포넌트들의 리스트(다음 장에서 논의됨): + </para> + + <programlisting><![CDATA[<list name="carComponents" + table="CarComponents"> + <key column="carId"/> + <list-index column="sortOrder"/> + <composite-element class="CarComponent"> + <property name="price"/> + <property name="type"/> + <property name="serialNumber" column="serialNum"/> + </composite-element> +</list>]]></programlisting> + + </sect2> + + <sect2 id="collections-onetomany"> + <title>One-to-many 연관들</title> + + <para> + <emphasis>one to many 연관</emphasis>은 중재하는 콜렉션 테이블 없이 foreign 키를 통해 두 개의 클래스들의 테이블들을 + 연결시킨다. 이 매핑은 통상의 자바 콜렉션들의 어떤 의미를 상실한다: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + 포함된 엔티티 클래스의 인스턴스는 그 콜렉션의 하나 이상의 인스턴스에 속하지 않을 수 있다 + </para> + </listitem> + <listitem> + <para> + 포함된 엔티티 클래스의 인스턴스는 콜렉션 인덱스의 하나 이상의 값에서 나타나지 않을 수 있다 + </para> + </listitem> + </itemizedlist> + + <para> + <literal>Product</literal>로부터 <literal>Part</literal>로의 연관은 foreign 키 컬럼과 <literal>Part</literal> + 테이블에 대한 인덱스 컬럼의 존재를 필요로 한다. <literal>&lt;one-to-many&gt;</literal> 태그는 이것이 one to many + 연관임을 나타낸다. + </para> + + <programlistingco> + <areaspec> + <area id="onetomany1" coords="2 60"/> + <area id="onetomany2" coords="3 60"/> + <area id="onetomany3" coords="4 60"/> + </areaspec> + <programlisting><![CDATA[<one-to-many + class="ClassName" + not-found="ignore|exception" + entity-name="EntityName" + node="element-name" + embed-xml="true|false" + />]]></programlisting> + <calloutlist> + <callout arearefs="onetomany1"> + <para> + <literal>class</literal> (필수): 연관된 클래스의 이름. + </para> + </callout> + <callout arearefs="onetomany2"> + <para> + <literal>not-found</literal> (옵션 - 디폴트는 <literal>exception</literal>): + 누락된 행들을 참조하는 캐시된 식별자들이 어떻게 처리될 것인지를 지정한다: + <literal>ignore</literal>는 누락된 한 행을 한 개의 연관으로 다룰 것이다. + </para> + </callout> + <callout arearefs="onetomany3"> + <para> + <literal>entity-name</literal> (옵션): <literal>class</literal>에 대한 대안으로서, + 연관된 클래스의 엔티티 이름. + </para> + </callout> + </calloutlist> + </programlistingco> + + <para> + <literal>&lt;one-to-many&gt;</literal> 요소는 어떤 컬럼들을 선언하는데 필요하지 않음을 주목하라. 어딘가에 + <literal>table</literal> 이름을 지정하는 것도 필수적이지 않다. + </para> + + <para> + <emphasis>매우 중요한 노트</emphasis>: 만일 <literal>&lt;one-to-many&gt;</literal> 연관의 foreign 키 컬럼이 + <literal>NOT NULL</literal>로 선언될 경우, 당신은 <literal>&lt;key&gt;</literal> 매핑을 <literal>not-null="true"</literal>로 + 선언해야 하거나 <literal>inverse="true"</literal>로 마크된 콜렉션 매핑을 가진 <emphasis>양방향 연관을 사용해야 한다</emphasis>. + 양방향 연관들에 대한 논의는 이 장의 뒷부분을 보라. + </para> + + <para> + 이 예제는 name으로 <literal>Part</literal> 엔티티들을 가진 map을 보여준다(여기서 <literal>partName</literal>은 + <literal>Part</literal>의 영속 프로퍼티이다). formula-기반 index의 사용을 주목하라. + </para> + + <programlisting><![CDATA[<map name="parts" + cascade="all"> + <key column="productId" not-null="true"/> + <map-key formula="partName"/> + <one-to-many class="Part"/> +</map>]]></programlisting> + </sect2> + + </sect1> + + <sect1 id="collections-advancedmappings"> + <title>개선된 콜렉션 매핑들</title> + + <sect2 id="collections-sorted" revision="2"> + <title>Sorted 콜렉션들</title> + + <para> + Hibernate는 <literal>java.util.SortedMap</literal>과 <literal>java.util.SortedSet</literal>를 구현하는 + 콜렉션들을 지원한다. 당신은 매핑 파일 속에 하나의 comparator를 지정해야 한다: + </para> + + <programlisting><![CDATA[<set name="aliases" + table="person_aliases" + sort="natural"> + <key column="person"/> + <element column="name" type="string"/> +</set> + +<map name="holidays" sort="my.custom.HolidayComparator"> + <key column="year_id"/> + <map-key column="hol_name" type="string"/> + <element column="hol_date" type="date"/> +</map>]]></programlisting> + + <para> + <literal>sort</literal> 속성에 허용되는 값들은 <literal>unsorted</literal>, <literal>natural</literal>, + 그리고 <literal>java.util.Comparator</literal>를 구현하는 클래스의 이름이다. + </para> + + <para> + Sorted 콜렉션들은 <literal>java.util.TreeSet</literal> 또는 <literal>java.util.TreeMap</literal>처럼 행동한다. + </para> + + <para> + 만일 당신이 데이터베이스 그 자체가 콜렉션 요소들을 순서지우도록(order)원할 경우 <literal>set</literal>, + <literal>bag</literal> 또는<literal>map</literal> 매핑들에 대해 <literal>order-by</literal> 속성을 사용하라. + 이 해결책은 JDK 1.4 이상의 버전에서만 이용 가능하다(그것은 <literal>LinkedHashSet</literal> 또는 <literal>LinkedHashMap</literal>을 + 사용하여 구현된다). 이것은 메모리 내가 아닌, SQL 질의 내에서 순서지움(ordering)을 수행한다. + </para> + + <programlisting><![CDATA[<set name="aliases" table="person_aliases" order-by="lower(name) asc"> + <key column="person"/> + <element column="name" type="string"/> +</set> + +<map name="holidays" order-by="hol_date, hol_name"> + <key column="year_id"/> + <map-key column="hol_name" type="string"/> + <element column="hol_date type="date"/> +</map>]]></programlisting> + + <para> + <literal>order-by</literal> 속성의 값은 HQL 순서지움(ordering)이 아니라 SQL 순서지움(ordering)임을 노트하라! + </para> + + <para> + 연관들은 콜렉션 <literal>filter()</literal>를 사용하여 실행 시에 어떤 임의의 criteria(기준)을 사용하여 정렬(sort)될 + 수도 있다. + </para> + + <programlisting><![CDATA[sortedUsers = s.createFilter( group.getUsers(), "order by this.name" ).list();]]></programlisting> + + </sect2> + + <sect2 id="collections-bidirectional" revision="1"> + <title>양방향 연관들</title> + + <para> + <emphasis>양방향 연관</emphasis>은 연관의 양 "끝(end)들"로부터 네비게이션을 허용한다. + 두 가지 종류의 양방향 연관들이 지원된다: + + <variablelist> + <varlistentry> + <term>one-to-many</term> + <listitem> + <para> + 한쪽 끝에 set 또는 bag 값을 갖고, 다른 쪽 긑에 단일 값을 가진 연관 + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>many-to-many</term> + <listitem> + <para> + 양 끝에서 set 또는 bag 값을 가진 연관 + </para> + </listitem> + </varlistentry> + </variablelist> + + </para> + + <para> + 당신은 동일한 두 개의 many-to-many 연관들을 동일한 데이터베이스 테이블로 간단하게 매핑하고 한 쪽 끝을 + <emphasis>inverse</emphasis>(당신의 선택은 하나이지만, 그것은 인덱싱된 콜렉션일 수 없다)로 선언함으로써 하나의 양방향 + many-to-many 연관을 지정할 수도 있다. + </para> + + <para> + 다음은 양방향 many-to-many 연관에 관한 예제이다; 각각의 카테고리는 많은 아이템들을 가질 수 있고 각각의 아이템은 많은 + 카테고리들 속에 있을 수 있다: + </para> + + <programlisting><![CDATA[<class name="Category"> + <id name="id" column="CATEGORY_ID"/> + ... + <bag name="items" table="CATEGORY_ITEM"> + <key column="CATEGORY_ID"/> + <many-to-many class="Item" column="ITEM_ID"/> + </bag> +</class> + +<class name="Item"> + <id name="id" column="ITEM_ID"/> + ... + + <!-- inverse end --> + <bag name="categories" table="CATEGORY_ITEM" inverse="true"> + <key column="ITEM_ID"/> + <many-to-many class="Category" column="CATEGORY_ID"/> + </bag> +</class>]]></programlisting> + + <para> + 연관의 inverse 끝(end)에 대해서만 행해진 변경들은 영속화 되지 <emphasis>않는다</emphasis>. 이것은 Hibernate가 + 모든 양방향 연관에 대해 메모리 내에 두 개의 표상들을 갖는다는 점을 의미한다: A로부터 B로의 하나의 링크와 B로부터 A로의 또 다른 링크. + 만일 당신이 자바 객체 모형에 대해 그리고 자바에서 many-to-many 관계를 생성시키는 방법에 대해 생각하면 이것은 이해하기가 더 쉽다: + </para> + + <programlisting><![CDATA[ +category.getItems().add(item); // The category now "knows" about the relationship +item.getCategories().add(category); // The item now "knows" about the relationship + +session.persist(item); // The relationship won't be saved! +session.persist(category); // The relationship will be saved]]></programlisting> + + <para> + non-inverse 측은 메모리 내 표상을 데이터베이스로 저장하는데 사용된다. + </para> + + <para> + 당신은 하나의 one-to-many 연관을 하나의 many-to-one 연관으로서 동일한 테이블 컬럼(들)로 매핑하고 many-값을 가진 끝(end)을 + <literal>inverse="true"</literal>로 선언함으로써 하나의 양방향 연관을 정의할 수도 있다. + </para> + + <programlisting><![CDATA[<class name="Parent"> + <id name="id" column="parent_id"/> + .... + <set name="children" inverse="true"> + <key column="parent_id"/> + <one-to-many class="Child"/> + </set> +</class> + +<class name="Child"> + <id name="id" column="child_id"/> + .... + <many-to-one name="parent" + class="Parent" + column="parent_id" + not-null="true"/> +</class>]]></programlisting> + + <para> + 연관의 한쪽 끝을 <literal>inverse="true"</literal>로 매핑하는 것은 cascade들을 가진 오퍼레이션에 영향을 주지 않으며, + 이것들은 orthogonal(직교) 개념들이다! + </para> + + </sect2> + + <sect2 id="collections-indexedbidirectional"> + <title>인덱싱된 콜렉션들을 가진 양방향 연관들</title> + <para> + 한쪽 끝이 하나의 <literal>&lt;list&gt;</literal> 또는 <literal>&lt;map&gt;</literal>으로서 표현되는 양방향 + 연관은 특별한 검토를 필요로 한다. 만일 인덱스 컬럼으로 매핑되는 child 클래스의 프로퍼티가 하나 존재한다면 문제가 없고, + 우리는 콜렉션 매핑 상에 <literal>inverse="true"</literal>를 사용하여 계속할 수 있다: + </para> + + <programlisting><![CDATA[<class name="Parent"> + <id name="id" column="parent_id"/> + .... + <map name="children" inverse="true"> + <key column="parent_id"/> + <map-key column="name" + type="string"/> + <one-to-many class="Child"/> + </map> +</class> + +<class name="Child"> + <id name="id" column="child_id"/> + .... + <property name="name" + not-null="true"/> + <many-to-one name="parent" + class="Parent" + column="parent_id" + not-null="true"/> +</class>]]></programlisting> + + <para> + 그러나 만일 child 클래스 상에 그런 프로퍼티가 존재하지 않을 경우, 우리는 그 연관을 진정하게 양방향으로 간주할 수 없다 + (다른 쪽 끝에서 이용가능하지 않은 그 연관의 끝에서 이용 가능한 정보가 존재한다). 이 경우에 우리는 그 콜렉션을 + <literal>inverse="true"</literal>로 매핑시킬 수 없다. 대신에 우리는 다음 매핑을 사용할 수 있다: + </para> + + <programlisting><![CDATA[<class name="Parent"> + <id name="id" column="parent_id"/> + .... + <map name="children"> + <key column="parent_id" + not-null="true"/> + <map-key column="name" + type="string"/> + <one-to-many class="Child"/> + </map> +</class> + +<class name="Child"> + <id name="id" column="child_id"/> + .... + <many-to-one name="parent" + class="Parent" + column="parent_id" + insert="false" + update="false" + not-null="true"/> +</class>]]></programlisting> + + <para> + 이 매핑에서 그 연관의 콜렉션 값을 가진 끝이 foreign 키에 대한 업데이트 책임이 있음을 노트하라. + </para> + + </sect2> + + <sect2 id="collections-ternary"> + <title>Ternary associations(세겹 연관들)</title> + + <para> + 세 겹의 연관을 매핑하는 세 가지 가능한 접근법들이 존재한다. 하나의 접근법은 그것의 인덱스로서 연관관계를 가진 + <literal>Map</literal>을 사용하는 것이다: + </para> + + <programlisting><![CDATA[<map name="contracts"> + <key column="employer_id" not-null="true"/> + <map-key-many-to-many column="employee_id" class="Employee"/> + <one-to-many class="Contract"/> +</map>]]></programlisting> + + <programlisting><![CDATA[<map name="connections"> + <key column="incoming_node_id"/> + <map-key-many-to-many column="outgoing_node_id" class="Node"/> + <many-to-many column="connection_id" class="Connection"/> +</map>]]></programlisting> + + <para> + 두 번째 접근법은 그 연관을 엔티티 클래스로서 단순하게 리모델링 하는 것이다. 이것은 우리가 가장 공통적으로 사용하는 접근법이다. + </para> + + <para> + 마지막 대안은 우리가 나중에 논의하게 될 composite 요소들을 사용하는 것이다. + </para> + + </sect2> + + <sect2 id="collections-idbag" revision="1"> + <title><literal>&lt;idbag&gt;</literal> 사용하기</title> + + <para> + 만일 당신이 composite 키들이 나쁜 것이고 엔티티들이 합성 식별자들(대용 키들, surrogate keys)을 가져야 한다는 + 우리의 견해를 전적으로 수용할 경우, 당신은 우리가 지금까지 보여주었던 값들을 가진 콜렉션들과 many to many 연관들이 모두 + composite 키들을 가진 테이블들로 매핑된다는 약간 이상한 점을 발견할 수도 있다! 이제 이 점은 꽤 논의의 여지가 있다; 순수한 + 연관 테이블은 (비록 composite 값들을 가진 콜렉션<emphasis>일 수도</emphasis> 있을지라도) 대용 키로부터 많은 이점을 + 취하지 않는 것처럼 보인다. 그럼에도 불구하고 Hibernate는 당신이 값들을 가진 콜렉션들과 many to many 연관들을 대용 키를 가진 + 테이블로 매핑시키는 것을 당신에게 허용해주는 특징을 제공한다. + </para> + + <para> + <literal>&lt;idbag&gt;</literal> 요소는 bag 의미를 가진 <literal>List</literal>(또는 <literal>Collection</literal>)을 + 매핑하도록 당신에게 허용해준다. + </para> + +<programlisting><![CDATA[<idbag name="lovers" table="LOVERS"> + <collection-id column="ID" type="long"> + <generator class="sequence"/> + </collection-id> + <key column="PERSON1"/> + <many-to-many column="PERSON2" class="Person" fetch="join"/> +</idbag>]]></programlisting> + + <para> + 당신이 볼 수 있듯이, <literal>&lt;idbag&gt;</literal>은 마치 엔티티 클래스인양 synthetic id generator(합성 id 생성기)를 + 갖는다! 다른 대용 키는 각각의 콜렉션 행에 할당된다. 하지만 Hibernate는 특정 행의 대용 키 값을 발견하는 메커니즘을 제공하지 않는다. + </para> + + <para> + <literal>&lt;idbag&gt;</literal>의 업데이트 퍼포먼스는 정규 <literal>&lt;bag&gt;</literal> 보다 훨씬 좋다는 점을 + 노트하라! Hibernate는 마치 list, map, 또는 set인양, 개별 행들을 효율적으로 위치지울 수 있고 그것들을 개별적으로 업데이트 + 하거나 삭제시킬 수 있다. + </para> + + <para> + 현재 구현에서, <literal>native</literal> 식별자 생성 방도는 <literal>&lt;idbag&gt;</literal> 콜렉션 식별자들에 대해 + 지원되지 않는다. + </para> + + </sect2> + + </sect1> + + <!--다음 요소를 문서화하지 않음 --> + + <!--sect1 id="collections-heterogeneous"> + <title>Heterogeneous Associations</title> + + <para> + <literal>&lt;many-to-any&gt;</literal>와 <literal>&lt;index-many-to-any&gt;</literal> 요소들은 + 진정한 이종의(heterogeneous) 연관들을 제공한다. 이들 매핑 요소들은 <literal>&lt;any&gt;</literal> 요소와 + 동일한 방법으로 동작한다 - 그리고 또한 아마 드물게 사용될 수 있을 것이다. + </para> + + </sect1--> + + <sect1 id="collections-example" revision="1"> + <title>콜렉션 예제들</title> + + <para> + 앞의 절들은 꽤 혼동스럽다. 따라서 예제를 살펴보자. 다음 클래스: + </para> + + <programlisting><![CDATA[package eg; +import java.util.Set; + +public class Parent { + private long id; + private Set children; + + public long getId() { return id; } + private void setId(long id) { this.id=id; } + + private Set getChildren() { return children; } + private void setChildren(Set children) { this.children=children; } + + .... + .... +}]]></programlisting> + + <para> + 는 <literal>Child</literal> 인스턴스들을 가진 하나의 콜렉션을 갖고 있다. 만일 각각의 자식이 최소한 한 개의 부모를 가질 경우, + 대부분의 고유한 매핑은 one-to-many 연관이다: + </para> + + <programlisting><![CDATA[<hibernate-mapping> + + <class name="Parent"> + <id name="id"> + <generator class="sequence"/> + </id> + <set name="children"> + <key column="parent_id"/> + <one-to-many class="Child"/> + </set> + </class> + + <class name="Child"> + <id name="id"> + <generator class="sequence"/> + </id> + <property name="name"/> + </class> + +</hibernate-mapping>]]></programlisting> + + <para> + 이것은 다음 테이블 정의들로 매핑된다: + </para> + + <programlisting><![CDATA[create table parent ( id bigint not null primary key ) +create table child ( id bigint not null primary key, name varchar(255), parent_id bigint ) +alter table child add constraint childfk0 (parent_id) references parent]]></programlisting> + + <para> + 만일 부모가 <emphasis>필수적</emphasis>이라면, 양방향 one-to-many 연관관계를 사용하라: + </para> + + <programlisting><![CDATA[<hibernate-mapping> + + <class name="Parent"> + <id name="id"> + <generator class="sequence"/> + </id> + <set name="children" inverse="true"> + <key column="parent_id"/> + <one-to-many class="Child"/> + </set> + </class> + + <class name="Child"> + <id name="id"> + <generator class="sequence"/> + </id> + <property name="name"/> + <many-to-one name="parent" class="Parent" column="parent_id" not-null="true"/> + </class> + +</hibernate-mapping>]]></programlisting> + + <para> + <literal>NOT NULL</literal> 컨스트레인트를 주목하라: + </para> + + <programlisting><![CDATA[create table parent ( id bigint not null primary key ) +create table child ( id bigint not null + primary key, + name varchar(255), + parent_id bigint not null ) +alter table child add constraint childfk0 (parent_id) references parent]]></programlisting> + + <para> + 대안적으로, 만일 당신이 이 연관관계가 단방향이어야 함을 절대적으로 역설할 경우, 당신은 <literal>&lt;key&gt;</literal> + 매핑 상에 <literal>NOT NULL</literal> 컨스트레인트를 선언할 수 있다: + </para> + + <programlisting><![CDATA[<hibernate-mapping> + + <class name="Parent"> + <id name="id"> + <generator class="sequence"/> + </id> + <set name="children"> + <key column="parent_id" not-null="true"/> + <one-to-many class="Child"/> + </set> + </class> + + <class name="Child"> + <id name="id"> + <generator class="sequence"/> + </id> + <property name="name"/> + </class> + +</hibernate-mapping>]]></programlisting> + + <para> + 반면에, 만일 자식이 여러 부모들을 가질 수 있을 경우, many-to-many 연관이 적절하다: + </para> + + <programlisting><![CDATA[<hibernate-mapping> + + <class name="Parent"> + <id name="id"> + <generator class="sequence"/> + </id> + <set name="children" table="childset"> + <key column="parent_id"/> + <many-to-many class="Child" column="child_id"/> + </set> + </class> + + <class name="Child"> + <id name="id"> + <generator class="sequence"/> + </id> + <property name="name"/> + </class> + +</hibernate-mapping>]]></programlisting> + + <para> + 테이블 정의들: + </para> + + <programlisting><![CDATA[create table parent ( id bigint not null primary key ) +create table child ( id bigint not null primary key, name varchar(255) ) +create table childset ( parent_id bigint not null, + child_id bigint not null, + primary key ( parent_id, child_id ) ) +alter table childset add constraint childsetfk0 (parent_id) references parent +alter table childset add constraint childsetfk1 (child_id) references child]]></programlisting> + + <para> + 부모/자식 관계 매핑을 연습하는 더 많은 예제들과 전체 리허설은 <xref linkend="example-parentchild"/>를 보라. + </para> + + <para> + 비록 더 많은 신종 연관 매핑들이 가능할지라도, 우리는 다음 장에서 모든 가능성들을 분류할 것이다. + </para> + + </sect1> + +</chapter> Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/component_mapping.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/component_mapping.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/component_mapping.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/component_mapping.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,373 @@ +<chapter id="components"> + <title>Component 매핑</title> + + <para> + <emphasis>component</emphasis>의 개념은 Hibernate에서 다른 용도로 몇몇 다른 컨텍스트들 내에서 재사용된다. + </para> + + <sect1 id="components-dependentobjects" revision="2" > + <title>종속 객체들</title> + + <para> + 하나의 컴포넌트는 엔티티 참조가 아닌, value 타입으로서 영속화 되는 하나의 포함된 객체이다. "컴포넌트" 용어는 + (아키텍처 수준의 컴포넌트들이 아닌) composition(구성,합성)에 대한 객체-지향적인 개념을 언급한다. + 예를 들어 당신은 다음과 같이 개인을 모형화 시킬 수도 있다: + </para> + + <programlisting><![CDATA[public class Person { + private java.util.Date birthday; + private Name name; + private String key; + public String getKey() { + return key; + } + private void setKey(String key) { + this.key=key; + } + public java.util.Date getBirthday() { + return birthday; + } + public void setBirthday(java.util.Date birthday) { + this.birthday = birthday; + } + public Name getName() { + return name; + } + public void setName(Name name) { + this.name = name; + } + ...... + ...... +}]]></programlisting> + +<programlisting><![CDATA[public class Name { + char initial; + String first; + String last; + public String getFirst() { + return first; + } + void setFirst(String first) { + this.first = first; + } + public String getLast() { + return last; + } + void setLast(String last) { + this.last = last; + } + public char getInitial() { + return initial; + } + void setInitial(char initial) { + this.initial = initial; + } +}]]></programlisting> + + <para> + 이제 <literal>Name</literal>은 <literal>Person</literal>의 컴포넌트로서 영속화 될 수도 있다. <literal>Name</literal>이 + 그것의 영속 프로퍼티들에 대한 getter 메소드와 setter 메소드를 정의하지만, 어떤 인터페이스들이나 식별자 프로퍼티들을 선언하는 것을 + 필요로 하지 않음을 주목하라. + </para> + + <para> + 우리의 Hibernate 매핑은 다음과 같을 것이다: + </para> + + <programlisting><![CDATA[<class name="eg.Person" table="person"> + <id name="Key" column="pid" type="string"> + <generator class="uuid"/> + </id> + <property name="birthday" type="date"/> + <component name="Name" class="eg.Name"> <!-- class attribute optional --> + <property name="initial"/> + <property name="first"/> + <property name="last"/> + </component> +</class>]]></programlisting> + + <para> + person 테이블은 + <literal>pid</literal>, + <literal>birthday</literal>, + <literal>initial</literal>, + <literal>first</literal>, + <literal>last</literal> 컬럼들을 가질 것이다. + </para> + + <para> + 모든 값(value) 타입들처럼, 컴포넌트들은 공유된 참조들을 지원하지 않는다. 달리 말해, 두 명의 개인들은 동일한 이름을 가질 수 + 있지만, 두 개의 person 객체들은 오직 값 만이 "동일한" 두 개의 독립적인 name 객체들을 포함할 것이다. 컴포넌트의 null 값 의미는 + <emphasis>특별한 용도를 위한 것이다</emphasis>. 포함된 객체를 다시 로드시킬 때, Hibernate는 모든 컴포넌트 컬럼들이 + null일 경우에 전체 컴포넌트가 null이라고 가정할 것이다. 이것은 대부분의 용도에 맞을 것이다. + </para> + + <para> + 컴포넌트의 프로퍼티들은 임의의 Hibernate 타입일 수 있다(콜렉션들, many-to-one 연관들, 다른 컴포넌트들, 기타). + 내포된 컴포넌트들은 신종의 사용례로 간주되지 <emphasis>않을</emphasis> 것이다. Hibernate는 매우 잘 정제된 객체 모형을 + 지원하도록 고안되어있다. + </para> + + <para> + <literal>&lt;component&gt;</literal> 요소는 컴포넌트 클래스의 프로퍼티를 포함되는 엔티티에 대한 역 참조로서 매핑시키는 + <literal>&lt;parent&gt;</literal> 서브요소를 허용한다. + </para> + + <programlisting><![CDATA[<class name="eg.Person" table="person"> + <id name="Key" column="pid" type="string"> + <generator class="uuid"/> + </id> + <property name="birthday" type="date"/> + <component name="Name" class="eg.Name" unique="true"> + <parent name="namedPerson"/> <!-- reference back to the Person --> + <property name="initial"/> + <property name="first"/> + <property name="last"/> + </component> +</class>]]></programlisting> + + </sect1> + + <sect1 id="components-incollections" revision="1"> + <title>종속 객체들을 가진 콜렉션들</title> + + <para> + 컴포넌트들을 가진 콜렉션들이 지원된다(예를 들면 <literal>Name</literal> 타입을 가진 배열). + <literal>&lt;element&gt;</literal> 태그를 <literal>&lt;composite-element&gt;</literal> 태그로 + 대체시켜서 당신의 컴포넌트 콜렉션을 선언하라. + </para> + + <programlisting><![CDATA[<set name="someNames" table="some_names" lazy="true"> + <key column="id"/> + <composite-element class="eg.Name"> <!-- class attribute required --> + <property name="initial"/> + <property name="first"/> + <property name="last"/> + </composite-element> +</set>]]></programlisting> + + <para> + 노트: 만일 당신이 composite 요소를 가진 하나의 <literal>Set</literal>를 정의할 경우, <literal>equals()</literal>와 + <literal>hashCode()</literal>를 정확하게 구현하는 것이 매우 중요하다. + </para> + + <para> + Composite 요소들은 컴포넌트들을 포함하지만 콜렉션들을 포함하지 않는다. 만일 당신의 composite 요소 자체가 컴포넌트들을 포함할 + 경우, <literal>&lt;nested-composite-element&gt;</literal> 태그를 사용하라. 이것은 꽤 신종의 경우-그것들 자체가 + 컴포넌트들을 갖고 있는 컴포넌트들의 콜렉션-이다. 이 단계에서 당신은 one-to-many 연관이 더 적절한지를 당신 스스로에게 질문하게 + 될 것이다. 하나의 엔티티로서 composite 요소를 다시 모델링하려고 시도하라 - 그러나 자바 모형들이 동일할지라도, + 관계형 모형과 영속화 의미들은 여전히 약간 다르다. + </para> + + <para> + 당신이 하나의 <literal>&lt;set&gt;</literal>을 사용 중이라면, 하나의 composite 요소 매핑은 null 가능한 프로퍼티들을 + 지원하지 않음을 노트하길 바란다. Hibernate는 객체들을 삭제할 때 하나의 레코드를 식별하는데 각각의 컬럼들 값을 사용해야 하며 + (composite 요소 테이블 내에 별도의 프라이머리 키 컬럼이 존재하지 않는다), 그것은 null 값들에 대해서는 불가능하다. 당신은 + 하나의 composite-요소 내에 not-null 프로퍼티들 만을 사용해야 하거나 하나의 <literal>&lt;list&gt;</literal>, + <literal>&lt;map&gt;</literal>, <literal>&lt;bag&gt;</literal> 또는 <literal>&lt;idbag&gt;</literal>을 + 선택해야 한다. + </para> + + <para> + composite 요소에 대한 하나의 특별한 경우는 내포된 <literal>&lt;many-to-one&gt;</literal> 요소를 가진 composite 요소이다. + 이같은 매핑은 many-to-many 연관 테이블의 특별한 컬럼들을 composite 요소 클래스로 매핑시키는 것을 당신에게 허용해준다. 다음은 + <literal>Order</literal>로부터 <literal>Item</literal>으로의 many-to-many 연관이다. 여기서 + <literal>purchaseDate</literal>, <literal>price</literal>, 그리고 <literal>quantity</literal>는 연관의 + 프로퍼티들이다: + </para> + + <programlisting><![CDATA[<class name="eg.Order" .... > + .... + <set name="purchasedItems" table="purchase_items" lazy="true"> + <key column="order_id"> + <composite-element class="eg.Purchase"> + <property name="purchaseDate"/> + <property name="price"/> + <property name="quantity"/> + <many-to-one name="item" class="eg.Item"/> <!-- class attribute is optional --> + </composite-element> + </set> +</class>]]></programlisting> + + <para> + 물론, 양방향 연관 네비게이션의 경우, 다른 측 상에 있는 purchase에 대한 참조가 존재할 수 없다. 컴포넌트들이 값(value) 타입들이고 + 공유된 참조들을 허용하지 않음을 기억하라. 하나의 <literal>Purchase</literal>는<literal>Order</literal>를 가진 set + 내에 있을 수 있지만, 그것은 동시에 <literal>Item</literal>에 의해 참조될 수 없다. + </para> + + <para>심지어 세겹의(또는 네 겹의, 기타) 연관들이 가능하다:</para> + + <programlisting><![CDATA[<class name="eg.Order" .... > + .... + <set name="purchasedItems" table="purchase_items" lazy="true"> + <key column="order_id"> + <composite-element class="eg.OrderLine"> + <many-to-one name="purchaseDetails class="eg.Purchase"/> + <many-to-one name="item" class="eg.Item"/> + </composite-element> + </set> +</class>]]></programlisting> + + <para> + composite 요소들은 다른 엔티티들에 대한 연관들과 동일한 구문을 사용하여 질의들 내에 나타날 수도 있다. + </para> + + </sect1> + + <sect1 id="components-asmapindex"> + <title>Map 인덱스들로서 컴포넌트들</title> + + <para> + <literal>&lt;composite-map-key&gt;</literal> 요소는 당신에게 하나의 컴포넌트 클래스를 하나의 <literal>Map</literal>의 + 키로서 매핑시키도록 한다. 당신은 컴포넌트 클래스 상에서 <literal>hashCode()</literal>와 <literal>equals()</literal>를 + 정확하게 오버라이드 시키도록 하라. + </para> + </sect1> + + <sect1 id="components-compositeid" revision="1"> + <title>composite 식별자들로서 컴포넌트들</title> + + <para> + 당신은 하나의 컴포넌트를 하나의 엔티티 클래스에 대한 하나의 식별자로서 사용할 수도 있다. 당신의 컴포넌트 클래스는 어떤 사양들을 + 충족시켜야 한다: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + 그것은 <literal>java.io.Serializable</literal>을 구현해야 한다. + </para> + </listitem> + <listitem> + <para> + 그것은 composite 키 등가(equality)에 대한 데이터베이스 개념과 일치되게, <literal>equals()</literal>와 + <literal>hashCode()</literal>를 다시 구현해야 한다. + </para> + </listitem> + </itemizedlist> + + <para> + <emphasis>노트: Hibernate3에서, 두 번째 사양은 Hibernate의 절대적으로 엄격한 사양이 아니다. + 그러나 아무튼 그것을 행하라.</emphasis> + </para> + + <para> + 당신은 compsite 키들을 생성시키는데 <literal>IdentifierGenerator</literal>를 사용할 수 없다. 대신에 어플리케이션은 + 그것 자신의 식별자들을 할당해야 한다. + </para> + + <para> + 통상의 <literal>&lt;id&gt;</literal> 선언 위치에 (내포된 <literal>&lt;key-property&gt;</literal> 요소들을 가진) + <literal>&lt;composite-id&gt;</literal> 태그를 사용하라. 예를 들어, <literal>OrderLine</literal> 클래스는 + <literal>Order</literal>의 (composite) 프라이머리 키에 의존하는 프라이머리 키를 갖는다. + </para> + + <programlisting><![CDATA[<class name="OrderLine"> + + <composite-id name="id" class="OrderLineId"> + <key-property name="lineId"/> + <key-property name="orderId"/> + <key-property name="customerId"/> + </composite-id> + + <property name="name"/> + + <many-to-one name="order" class="Order" + insert="false" update="false"> + <column name="orderId"/> + <column name="customerId"/> + </many-to-one> + .... + +</class>]]></programlisting> + + <para> + 이제 <literal>OrderLine</literal> 테이블을 참조하는 임의의 foreign 키들이 또한 compsite이다. 당신은 다른 클래스들에 대한 + 당신의 매핑들 속에 이것을 선언해야 한다. <literal>OrderLine</literal>에 대한 하나의 연관은 다음과 같이 매핑될 것이다: + </para> + + <programlisting><![CDATA[<many-to-one name="orderLine" class="OrderLine"> +<!-- the "class" attribute is optional, as usual --> + <column name="lineId"/> + <column name="orderId"/> + <column name="customerId"/> +</many-to-one>]]></programlisting> + + <para> + (<literal>&lt;column&gt;</literal> 태그가 모든 곳에서 <literal>column</literal> 속성에 대한 대안임을 노트하라.) + </para> + + <para> + <literal>OrderLine</literal>에 대한 <literal>many-to-many</literal> 연관은 또한 composite foreign 키를 사용한다: + </para> + + <programlisting><![CDATA[<set name="undeliveredOrderLines"> + <key column name="warehouseId"/> + <many-to-many class="OrderLine"> + <column name="lineId"/> + <column name="orderId"/> + <column name="customerId"/> + </many-to-many> +</set>]]></programlisting> + + <para> + <literal>Order</literal>에서 <literal>OrderLine</literal>들의 콜렉션이 사용될 것이다: + </para> + + <programlisting><![CDATA[<set name="orderLines" inverse="true"> + <key> + <column name="orderId"/> + <column name="customerId"/> + </key> + <one-to-many class="OrderLine"/> +</set>]]></programlisting> + + <para> + (통상적으로 <literal>&lt;one-to-many&gt;</literal> 요소는 컬럼들을 선언하지 않는다.) + </para> + + <para> + 만일 <literal>OrderLine</literal> 자체가 하나의 콜렉션을 소유할 경우, 그것은 또한 하나의 composite foreign 키를 갖는다. + </para> + + <programlisting><![CDATA[<class name="OrderLine"> + .... + .... + <list name="deliveryAttempts"> + <key> <!-- a collection inherits the composite key type --> + <column name="lineId"/> + <column name="orderId"/> + <column name="customerId"/> + </key> + <list-index column="attemptId" base="1"/> + <composite-element class="DeliveryAttempt"> + ... + </composite-element> + </set> +</class>]]></programlisting> + + </sect1> + + <sect1 id="components-dynamic" revision="1"> + <title>동적인 컴포넌트들</title> + + <para> + 당신은 <literal>Map</literal> 타입의 프로퍼티를 매핑시킬 수도 있다: + </para> + + <programlisting><![CDATA[<dynamic-component name="userAttributes"> + <property name="foo" column="FOO" type="string"/> + <property name="bar" column="BAR" type="integer"/> + <many-to-one name="baz" class="Baz" column="BAZ_ID"/> +</dynamic-component>]]></programlisting> + + <para> + <literal>&lt;dynamic-component&gt;</literal> 매핑의 의미는 <literal>&lt;component&gt;</literal>와 동일하다. + 이런 종류의 매핑의 장점은 배치 시에 단지 매핑 문서를 편집함으로써 그 bean의 실제 프로퍼티들을 결정하는 가용성이다. 매핑 문서에 + 대한 런타임 처리는 또한 DOM 파서를 사용하여 가능하다. 더 좋게는 당신이 <literal>Configuration</literal> 객체를 통해 + Hibernate의 구성-시 메타모형에 접근할 수 있다(그리고 변경시킬 수 있다) + </para> + + </sect1> + +</chapter> Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/configuration.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/configuration.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/configuration.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/configuration.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,1648 @@ +<chapter id="session-configuration" revision="1"> + + <title>구성</title> + + <para> + Hibernate가 많은 다른 환경들에서 동작하도록 설계되어 있으므로, 많은 개수의 구성 파라미터들이 존재한다. 다행히 대부분은 유의미한 + 디폴트 값들이고 Hibernate는 다양한 옵션들을 보여주는 <literal>etc/</literal> 내의 예제 파일 <literal>hibernate.properties</literal>로 + 배포된다. 당신은 단지 당신의 classpath 경로 속에 그 파일을 집어넣고 그것을 커스트마이징하기만 해야 한다. + </para> + + <sect1 id="configuration-programmatic" revision="1"> + <title>프로그램 상의 구성</title> + + <para> + <literal>org.hibernate.cfg.Configuration</literal>의 인스턴스는 어플리케이션의 Java 타입들을 SQL 데이터베이스 + 타입으로의 전체 매핑 집합을 표현한다. <literal>Configuration</literal>은 (불변의) <literal>SessionFactory</literal>를 + 빌드하는데 사용된다. 매핑들은 여러 XML 매핑 파일들로부터 컴파일 된다. + </para> + + <para> + 당신은 <literal>Configuration</literal> 인스턴스를 초기화 시키고 XML 매핑 문서들을 지정함으로써 <literal>Configuration</literal> + 인스턴스를 얻을 수 있다. 만일 매핑 파일들이 classpath 내에 있다면, <literal>addResource()</literal>를 사용하라: + </para> + + <programlisting><![CDATA[Configuration cfg = new Configuration() + .addResource("Item.hbm.xml") + .addResource("Bid.hbm.xml");]]></programlisting> + + <para> + (때때로 더 나은) 다른 방법은 매핑된 클래스를 지정하는 것이고, Hibernate로 하여금 당신을 위해 매핑 문서를 찾도록 하라: + </para> + + <programlisting><![CDATA[Configuration cfg = new Configuration() + .addClass(org.hibernate.auction.Item.class) + .addClass(org.hibernate.auction.Bid.class);]]></programlisting> + + <para> + 그때 Hibernate는 classpath 내에서 <literal>/org/hibernate/auction/Item.hbm.xml</literal>과 + <literal>/org/hibernate/auction/Bid.hbm.xml</literal>로 명명된 매핑 파일들을 룩업할 것이다. 이 접근법은 + 임의의 하드코딩된 파일 이름들을 제거한다. + </para> + + <para> + <literal>Configuration</literal>은 또한 구성 프로퍼티들을 지정하는 것을 허용해준다: + </para> + + <programlisting><![CDATA[Configuration cfg = new Configuration() + .addClass(org.hibernate.auction.Item.class) + .addClass(org.hibernate.auction.Bid.class) + .setProperty("hibernate.dialect", "org.hibernate.dialect.MySQLInnoDBDialect") + .setProperty("hibernate.connection.datasource", "java:comp/env/jdbc/test") + .setProperty("hibernate.order_updates", "true");]]></programlisting> + + <para> + 이것은 컨피그레이션 프로퍼티들을 Hibernate에 전달하는 유일한 방법이 아니다. 여러 가지 옵션들은 다음을 포함한다: + </para> + + <orderedlist spacing="compact"> + <listitem> + <para> + <literal>java.util.Properties</literal>의 인스턴스를 <literal>Configuration.setProperties()</literal>에 + 전달한다 . + </para> + </listitem> + <listitem> + <para> + classpath의 루트 디렉토리에 <literal>hibernate.properties</literal>를 위치지운다. + </para> + </listitem> + <listitem> + <para> + <literal>java -Dproperty=value</literal>를 사용하여 <literal>System</literal> 프로퍼티들을 설정한다. + </para> + </listitem> + <listitem> + <para> + <literal>hibernate.cfg.xml</literal>에 <literal>&lt;property&gt;</literal> 요소들을 포함한다 + (나중에 논의됨). + </para> + </listitem> + </orderedlist> + + <para> + 당신이 빠르게 시작하고 원할 경우 <literal>hibernate.properties</literal>는 가장 쉬운 접근법이다. + </para> + + <para> + <literal>Configuration</literal>은 시작 시(startup-time) 객체로서 일단 <literal>SessionFactory</literal>가 + 생성되면 폐기되게끔 예정되어 있다. + </para> + + </sect1> + + <sect1 id="configuration-sessionfactory"> + <title>SessionFactory 얻기</title> + + <para> + 모든 매핑들이 <literal>Configuration</literal>에 의해 파싱되었을 때, 어플리케이션은 <literal>Session</literal> + 인스턴스들에 대한 팩토리를 얻어야 한다. 이 팩토리는 모든 어플리케이션 쓰레드들에 의해 공유되도록 고안되었다: + </para> + + <programlisting><![CDATA[SessionFactory sessions = cfg.buildSessionFactory();]]></programlisting> + + <para> + 하지만 Hibernate는 당신의 어플리케이션이 하나 이상의 <literal>SessionFactory</literal>를 초기화 시키는 것을 허용한다. + 이것은 당신이 하나 이상의 데이터베이스를 사용하는 경우에 유용하다. + </para> + + </sect1> + + <sect1 id="configuration-hibernatejdbc" revision="1"> + <title>JDBC 커넥션들</title> + + <para> + 대개 당신은 <literal>SessionFactory</literal>로 하여금 당신을 위한 JDBC 커넥션들을 생성시키고 풀링시키는 것을 원한다. + 만일 당신이 이 접근법을 취할 경우, 한 개의 <literal>Session</literal>을 여는 것은 다음과 같이 간단하다: + </para> + + <programlisting><![CDATA[Session session = sessions.openSession(); // open a new Session]]></programlisting> + + <para> + 당신이 데이터베이스에 대한 접근을 요청하는 어떤 것을 행하자 마자, 한 개의 JDBC 커넥션이 그 풀로부터 얻어질 것이다. + </para> + + <para> + 이것이 동작하도록 하기 위해서, 우리는 몇몇 JDBC 커넥션 프로퍼티들을 Hibernate에 전달할 필요가 있다. 모든 Hibernate 프로퍼티 + 이름들과 의미론들은 <literal>org.hibernate.cfg.Environment</literal> 클래스 상에 정의되어 있다. 우리는 이제 JDBC + 커넥션 구성을 위한 가장 중요한 설정들을 설명할 것이다. + </para> + + <para> + 만일 당신이 다음 프로퍼티들을 설정할 경우 Hibernate는 <literal>java.sql.DriverManager</literal>를 사용하여 커넥션들을 + 얻을 것이다(그리고 풀링시킬 것이다): + </para> + + <table frame="topbot"> + <title>Hibernate JDBC 프로퍼티들</title> + <tgroup cols="2"> + <colspec colname="c1" colwidth="1*"/> + <colspec colname="c2" colwidth="1*"/> + <thead> + <row> + <entry>프로퍼티 이름</entry> + <entry>용도</entry> + </row> + </thead> + <tbody> + <row> + <entry> + <literal>hibernate.connection.driver_class</literal> + </entry> + <entry> + <emphasis>jdbc 드라이버 클래스</emphasis> + </entry> + </row> + <row> + <entry> + <literal>hibernate.connection.url</literal> + </entry> + <entry> + <emphasis>jdbc URL</emphasis> + </entry> + </row> + <row> + <entry> + <literal>hibernate.connection.username</literal> + </entry> + <entry> + <emphasis>데이터베이스 사용자</emphasis> + </entry> + </row> + <row> + <entry> + <literal>hibernate.connection.password</literal> + </entry> + <entry> + <emphasis>데이터베이스 사용자 패스워드</emphasis> + </entry> + </row> + <row> + <entry> + <literal>hibernate.connection.pool_size</literal> + </entry> + <entry> + <emphasis>풀링된 커넥션들의 최대 개수</emphasis> + </entry> + </row> + </tbody> + </tgroup> + </table> + + <para> + 하지만 Hibernate 자신의 커넥션 풀링 알고리즘은 아주 기본적이다. 그것은 당신이 시작하는 것을 도와주려고 의도되었고 <emphasis>제품 + 시스템 용도 또는 퍼포먼스 테스트용으로는 고안되지 않았다</emphasis>. 최상의 퍼포먼스와 안정성을 위해서는 제 3의 풀을 사용하라. 즉 + <literal>hibernate.connection.pool_size</literal> 프로퍼티를 커넥션 풀 지정 설정들로 대체하라. 이것은 Hibernate의 내부 + pool을 오프시킬 것이다. 예를 들어 당신은 C3P0를 사용할 수도 있다. + </para> + + <para> + C3P0는 <literal>lib</literal> 디펙토리 속에 Hibernate에 배포된 오픈 소스 JDBC 커넥션 풀이다. 당신이 <literal>hibernate.c3p0.*</literal> + 프로퍼티들을 설정할 경우 Hibernate는 커넥션 풀링을 위해 그것의 <literal>C3P0ConnectionProvider</literal>를 사용할 것이다. + 만일 당신이 Proxool을 사용하고자 원할 경우 패키지화 된 <literal>hibernate.properties</literal>를 참조하고 추가 정보는 + Hibernate 웹 사이트를 참조하라. + </para> + + <para> + 다음은 C3P0에 대한 사용하는 예제 <literal>hibernate.properties</literal> 파일이다: + </para> + + <programlisting id="c3p0-configuration" revision="1"><![CDATA[hibernate.connection.driver_class = org.postgresql.Driver +hibernate.connection.url = jdbc:postgresql://localhost/mydatabase +hibernate.connection.username = myuser +hibernate.connection.password = secret +hibernate.c3p0.min_size=5 +hibernate.c3p0.max_size=20 +hibernate.c3p0.timeout=1800 +hibernate.c3p0.max_statements=50 +hibernate.dialect = org.hibernate.dialect.PostgreSQLDialect]]></programlisting> + + <para> + 어플리케이션 서버 내부의 용도로, 당신은 JNDI로 등록된 어플리케이션 서버 <literal>Datasource</literal>로부터 커넥션을 얻기 + 위해 항상 Hibernate를 구성해야 한다. 당신은 적어도 다음 프로퍼티들 중 하나를 최소한으로 설정할 필요가 있을 것이다. + </para> + + <table frame="topbot"> + <title>Hibernate Datasource Properties</title> + <tgroup cols="2"> + <colspec colname="c1" colwidth="1*"/> + <colspec colname="c2" colwidth="1*"/> + <thead> + <row> + <entry>프로퍼티 이름</entry> + <entry>용도</entry> + </row> + </thead> + <tbody> + <row> + <entry> + <literal>hibernate.connection.datasource</literal> + </entry> + <entry> + <emphasis>데이터소스 JNDI 이름</emphasis> + </entry> + </row> + <row> + <entry> + <literal>hibernate.jndi.url</literal> + </entry> + <entry> + <emphasis>JNDI 프로바이더의 URL</emphasis> (옵션) + </entry> + </row> + <row> + <entry> + <literal>hibernate.jndi.class</literal> + </entry> + <entry> + <emphasis>JNDI <literal>InitialContextFactory</literal>의 클래스 </emphasis> (옵션) + </entry> + </row> + <row> + <entry> + <literal>hibernate.connection.username</literal> + </entry> + <entry> + <emphasis>데이터베이스 사용자</emphasis> (옵션) + </entry> + </row> + <row> + <entry> + <literal>hibernate.connection.password</literal> + </entry> + <entry> + <emphasis>데이터베이스 사용자 패스워드</emphasis> (옵션) + </entry> + </row> + </tbody> + </tgroup> + </table> + + <para> + 다음은 어플리케이션 서버 제공 JNDI 데이터소스용 예제 <literal>hibernate.properties</literal> 파일이다: + </para> + + <programlisting><![CDATA[hibernate.connection.datasource = java:/comp/env/jdbc/test +hibernate.transaction.factory_class = \ + org.hibernate.transaction.JTATransactionFactory +hibernate.transaction.manager_lookup_class = \ + org.hibernate.transaction.JBossTransactionManagerLookup +hibernate.dialect = org.hibernate.dialect.PostgreSQLDialect]]></programlisting> + + <para> + JNDI datasource로부터 얻어진 JDBC 커넥션들은 어플리케이션 서버의 컨테이너에 의해 관리되는 트랜잭션들에 자동적으로 참여할 것이다. + </para> + + <para> + 임의의 커넥션 프로퍼티들은 프로퍼티 이름 앞에 "<literal>hibernate.connnection</literal>"을 첨가하여 부여될 수 있다. 예를 들어 + 당신은 <literal>hibernate.connection.charSet</literal>을 사용하여 <literal>charSet</literal>을 지정할 수도 있다. + </para> + + <para> + 당신은 <literal>org.hibernate.connection.ConnectionProvider</literal> 인터페이스를 구현함으로써 JDBC 커넥션들을 + 얻는 당신 자신의 플러그인 방도를 정의할수도 있다. 당신은 <literal>hibernate.connection.provider_class</literal>를 + 설정하여 맞춤형 구현을 선택할 수도 있다. + </para> + + </sect1> + + <sect1 id="configuration-optional" revision="1"> + <title>선택적인 구성 프로퍼티들</title> + + <para> + 실행 시에 Hibernate의 행위를 제어하는 많은 다른 프로퍼티들이 존재한다. 모든 것이 옵션이지만 합당한 디폴트 값들을 갖는다. + </para> + + <para> + <emphasis>경고: 이들 프로퍼티들 중 몇몇은 "system-level" 전용이다.</emphasis> 시스템 레벨 프로퍼티들은 오직 + <literal>java -Dproperty=value</literal> 또는 <literal>hibernate.properties</literal>를 통해서만 설정될 수 + 있다. 그것들은 위에 설명된 다른 기법들에 의해 설정될 수 <emphasis>없다</emphasis>. + </para> + + <table frame="topbot" id="configuration-optional-properties" revision="8"> + <title>Hibernate 구성 프로퍼티들</title> + <tgroup cols="2"> + <colspec colname="c1" colwidth="1*"/> + <colspec colname="c2" colwidth="1*"/> + <thead> + <row> + <entry>프로퍼티 이름</entry> + <entry>용도</entry> + </row> + </thead> + <tbody> + <row> + <entry> + <literal>hibernate.dialect</literal> + </entry> + <entry> + 특정 관계형 데이터베이스에 최적화 된 SQL을 생성시키는 것을 Hibernate에게 허용해주는 + Hibernate <literal>Dialect</literal>의 클래스명. + <para> + <emphasis role="strong">예.</emphasis> + <literal>full.classname.of.Dialect</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.show_sql</literal> + </entry> + <entry> + 모든 SQL 문장들을 콘솔에 기록한다. 이것은 로그 카테고리 <literal>org.hibernate.SQL</literal>를 + <literal>debug</literal>로 설정하는 것에 대한 하나의 다른 방법이다. + <para> + <emphasis role="strong">예.</emphasis> + <literal>true</literal> | <literal>false</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.format_sql</literal> + </entry> + <entry> + 로그와 콘솔 속에 SQL을 깔끔하게 프린트한다. + <para> + <emphasis role="strong">예.</emphasis> + <literal>true</literal> | <literal>false</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.default_schema</literal> + </entry> + <entry> + 생성된 SQL 내에 주어진 schema/tablespace로서 수식이 없는 테이블이름들을 수식한다. + <para> + <emphasis role="strong">예.</emphasis> + <literal>SCHEMA_NAME</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.default_catalog</literal> + </entry> + <entry> + 주어진 SQL 내에 주어진 카타록으로서 수식이 없는 테이블이름들을 수식한다. + <para> + <emphasis role="strong">예.</emphasis> + <literal>CATALOG_NAME</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.session_factory_name</literal> + </entry> + <entry> + <literal>SessionFactory</literal>는 그것이 생성된 후에 JNDI 내에서 이 이름에 자동적으로 바인드 + 될 것이다. + <para> + <emphasis role="strong">예.</emphasis> + <literal>jndi/composite/name</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.max_fetch_depth</literal> + </entry> + <entry> + single-ended 연관관계들(one-to-one, many-to-one)의 경우에 outer join fetch 트리의 최대 "깊이"를 + 설정한다. <literal>0</literal>은 디폴트 outer join fetching을 사용불가능하게 만든다. + <para> + <emphasis role="strong">예.</emphasis> + <literal>0</literal>과 + <literal>3</literal> 사이의 값들이권장된다 + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.default_batch_fetch_size</literal> + </entry> + <entry> + 연관들의 Hibernate 배치 페칭에 대한 디폴트 크기를 설정한다. + <para> + <emphasis role="strong">예.</emphasis> + 권장되는 값들은 <literal>4</literal>, <literal>8</literal>, + <literal>16</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.default_entity_mode</literal> + </entry> + <entry> + 이 <literal>SessionFactory</literal>로부터 열려진 모든 세션들에 대해 엔티티 표현을 디폴트 모드로 + 설정한다 + <para> + <literal>dynamic-map</literal>, <literal>dom4j</literal>, + <literal>pojo</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.order_updates</literal> + </entry> + <entry> + 업데이트 중인 항목들의 프라이머리 키 값에 의해 SQL 업데이트들이 순서(ordering)지워지도록 Hibernate에게 + 강제시킨다. 이것은 고도의 동시성 시스템들에서 더 적은 트랜잭션 데드락(deadlock)들로 귀결될 것이다 + <para> + <emphasis role="strong">예.</emphasis> + <literal>true</literal> | <literal>false</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.generate_statistics</literal> + </entry> + <entry> + 이용 가능하게 되면, Hibernate는 퍼포먼스 튜닝에 유용한 통계들을 수집할 것이다. + <para> + <emphasis role="strong">예.</emphasis> + <literal>true</literal> | <literal>false</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.use_identifer_rollback</literal> + </entry> + <entry> + 이용 가능하게 되면, 객체가 삭제될 때 생성된 식별자 프로퍼티들은 디폴트 값들로 재설정될 것이다. + <para> + <emphasis role="strong">예.</emphasis> + <literal>true</literal> | <literal>false</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.use_sql_comments</literal> + </entry> + <entry> + 이용 가능하게 되면, Hibernate는 보다 쉬운 디버깅을 위해 SQL 내에 주석들을 생성시킬 것이다. + 디폴트는 <literal>false</literal>. + <para> + <emphasis role="strong">예.</emphasis> + <literal>true</literal> | <literal>false</literal> + </para> + </entry> + </row> + </tbody> + </tgroup> + </table> + + <table frame="topbot" id="configuration-jdbc-properties" revision="8"> + <title>Hibernate JDBC 및 커넥션 프로퍼티들</title> + <tgroup cols="2"> + <colspec colname="c1" colwidth="1*"/> + <colspec colname="c2" colwidth="1*"/> + <thead> + <row> + <entry>프로퍼티 이름</entry> + <entry>용도</entry> + </row> + </thead> + <tbody> + <row> + <entry> + <literal>hibernate.jdbc.fetch_size</literal> + </entry> + <entry> + 0 아닌 값은 JDBC fetch 사이즈를 결정한다(<literal>Statement.setFetchSize()</literal>을 호출한다 ). + </entry> + </row> + <row> + <entry> + <literal>hibernate.jdbc.batch_size</literal> + </entry> + <entry> + 0 아닌 값은 Hibernate에 의한 JDBC2 배치 업데이트의 사용을 이용 가능하게 한다. + <para> + <emphasis role="strong">예.</emphasis> + <literal>5</literal>와 <literal>30</literal> 사이의 값들이 권장된다 + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.jdbc.batch_versioned_data</literal> + </entry> + <entry> + 당신의 JDBC 드라이버가 <literal>executeBatch()</literal>로부터 정확한 행 카운트들을 반환할 경우에 + 이 프로퍼티를 <literal>true</literal>로 설정하라(대개 이 옵션을 사용 가능하게 하는 것이 안전하다). + 그러면 Hibernate는 자동적으로 버전화 된 데이터에 대해 배치화된(batched) DML을 사용할 것이다. + 디폴트는 <literal>false</literal>. + <para> + <emphasis role="strong">예.</emphasis> + <literal>true</literal> | <literal>false</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.jdbc.factory_class</literal> + </entry> + <entry> + 맞춤형 <literal>Batcher</literal>를 선택한다. 대부분의 어플리케이션들은 이 구성 프로퍼티를 필요로 하지 + 않을 것이다. + <para> + <emphasis role="strong">예.</emphasis> + <literal>classname.of.BatcherFactory</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.jdbc.use_scrollable_resultset</literal> + </entry> + <entry> + Hibernate에 의한 JDBC2 스크롤 가능한 결과셋들의 사용을 가능하게 해준다. 이 프로퍼티는 사용자가 제공한 + JDBC커넥션들을 사용할 때에만 필수적이고, 그 밖의 경우 Hibernate는 커넥션 메타데이터를 사용한다. + <para> + <emphasis role="strong">예.</emphasis> + <literal>true</literal> | <literal>false</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.jdbc.use_streams_for_binary</literal> + </entry> + <entry> + <literal>binary</literal> 또는 <literal>serializable</literal> 타입들을 JDBC로 기록하고 + /JDBC로부터 <literal>binary</literal> 또는 <literal>serializable</literal> 타입들을 읽어들일 때 + 스트림들을 사용한다(시스템-레벨 프로퍼티). + <para> + <emphasis role="strong">예.</emphasis> + <literal>true</literal> | <literal>false</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.jdbc.use_get_generated_keys</literal> + </entry> + <entry> + insert 후에 고유하게 생성된 키들을 검색하는데 JDBC3 <literal>PreparedStatement.getGeneratedKeys()</literal>의 + 사용을 이용 가능하도록 만든다. JDBC3+ 드라이버와 JRE1.4+를 필요로 하고, 당신의 드라이버가 Hibernate + 식별자 생성자들에 문제가 있을 경우에 false로 설정하라. 디폴트로 커넥션 메타 데이터를 사용하여 드라이버 + 가용성들을 결정하려고 시도하라. + <para> + <emphasis role="strong">예.</emphasis> + <literal>true|false</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.connection.provider_class</literal> + </entry> + <entry> + Hibernate에 JDBC 커넥션들을 제공하는 맞춤형 <literal>ConnectionProvider</literal>의 클래스명. + <para> + <emphasis role="strong">예.</emphasis> + <literal>classname.of.ConnectionProvider</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.connection.isolation</literal> + </entry> + <entry> + JDBC transaction isolation 레벨을 설정한다. 의미있는 값들로 <literal>java.sql.Connection</literal>을 + 체크하지만 대부분의 데이터베이스들이 모든 격리(isolate) 레벨들을 지원하지 않음을 노트하라. + <para> + <emphasis role="strong">예.</emphasis> + <literal>1, 2, 4, 8</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.connection.autocommit</literal> + </entry> + <entry> + JDBC 풀링된 커넥션들에 대해 자동커밋을 이용 가능하도록 한다(권장되지 않음). + <para> + <emphasis role="strong">예.</emphasis> + <literal>true</literal> | <literal>false</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.connection.release_mode</literal> + </entry> + <entry> + Hibernate가 JDBC 커넥션들을 해제하게 될 시점을 지정한다. 디폴트로 한 개의 JDBC 커넥션은 그 세션이 명시적으로 + 닫히거나 연결해제되기 전까지 보관된다. 어플리케이션 트랜잭션 서버 JTA 데이터소스의 경우, 당신은 모든 JDBC + 호출 후에 커넥션들을 과감하게 해제시키기 위해 <literal>after_statement</literal>를 사용해야 한다. 비-JTA + 연결의 경우, <literal>after_transaction</literal>을 사용하여 각각의 트랜잭션의 끝에서 커넥션들을 + 해제시키는 것이 종종 의미가 있다. <literal>auto</literal>는 JTA 및 CMT 트랜잭션 방도들의 경우에 + <literal>after_statement</literal>를 선택하고 JDBC 트랜잭션 방도에 대해 <literal>after_transaction</literal>를 + 선택할 것이다. + <para> + <emphasis role="strong">eg.</emphasis> + <literal>auto</literal> (디폴트) | <literal>on_close</literal> | + <literal>after_transaction</literal> | <literal>after_statement</literal> + </para> + <para> + 이 설정이 <literal>SessionFactory.openSession</literal>로부터 반환된 <literal>Session</literal>들에만 + 영향을 준다는 점을 노트하라. <literal>SessionFactory.getCurrentSession</literal>을 통해 얻어진 + <literal>Session</literal>들의 경우, 사용하기 위해 구성된 <literal>CurrentSessionContext</literal> 구현이 + 그들 <literal>Session</literal>들에 대한 연결 해제를 제어한다. <xref linkend="architecture-current-session"/>를 + 보라. + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.connection.<emphasis>&lt;propertyName&gt;</emphasis></literal> + </entry> + <entry> + JDBC 프로퍼티 <literal>propertyName</literal>을 <literal>DriverManager.getConnection()</literal>에 + 전달한다. + </entry> + </row> + <row> + <entry> + <literal>hibernate.jndi.<emphasis>&lt;propertyName&gt;</emphasis></literal> + </entry> + <entry> + <literal>propertyName</literal> 프로퍼티를 JNDI <literal>InitialContextFactory</literal>에 전달한다. + </entry> + </row> + </tbody> + </tgroup> + </table> + + <table frame="topbot" id="configuration-cache-properties" revision="7"> + <title>Hibernate Cache 프로퍼티들</title> + <tgroup cols="2"> + <colspec colname="c1" colwidth="1*"/> + <colspec colname="c2" colwidth="1*"/> + <thead> + <row> + <entry>프로퍼티 이름</entry> + <entry>용도</entry> + </row> + </thead> + <tbody> + <row> + <entry> + <literal>hibernate.cache.provider_class</literal> + </entry> + <entry> + 맞춤형 <literal>CacheProvider</literal>의 클래스명. + <para> + <emphasis role="strong">예.</emphasis> + <literal>classname.of.CacheProvider</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.cache.use_minimal_puts</literal> + </entry> + <entry> + 읽기가 매우 빈번한 경우에, 쓰기를 최소화 시키기 위해 second-level 캐시 연산을 최적화 시킨다. 이 설정은 Hibernate3에서 클러스터링 된 + 캐시들에 가장 유용하고, Hibernate3에서는 클러스터링된 캐시 구현들에 대해 디폴트로 이용 가능하다. + <para> + <emphasis role="strong">예.</emphasis> + <literal>true|false</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.cache.use_query_cache</literal> + </entry> + <entry> + 질의 캐시를 가능하게 만든다. 개별 질의들은 여전히 캐시 가능한 것으로 설정되어야 한다. + <para> + <emphasis role="strong">예.</emphasis> + <literal>true|false</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.cache.use_second_level_cache</literal> + </entry> + <entry> + second-level 캐시를 완전히 사용 불가능하게 하는데 사용될 수 있고, 그것은 <literal>&lt;cache&gt;</literal> 매핑을 + 지정하는 클래스들에 대해 디폴트로 이용 가능이다. + <para> + <emphasis role="strong">예.</emphasis> + <literal>true|false</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.cache.query_cache_factory</literal> + </entry> + <entry> + 맞춤형 <literal>QueryCache</literal> 인터페이스의 클래스명. 디폴트는 미리 빌드된 + <literal>StandardQueryCache</literal>. + <para> + <emphasis role="strong">예.</emphasis> + <literal>classname.of.QueryCache</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.cache.region_prefix</literal> + </entry> + <entry> + second-level 캐시 영역 이름들에 사용할 접두어. + <para> + <emphasis role="strong">예.</emphasis> + <literal>prefix</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.cache.use_structured_entries</literal> + </entry> + <entry> + 인간에게 보다 더 친숙한 형식으로 second-level 캐시 속에 데이터를 저장하도록 Hibernate에게 강제시킨다.. + <para> + <emphasis role="strong">예.</emphasis> + <literal>true|false</literal> + </para> + </entry> + </row> + </tbody> + </tgroup> + </table> + + <table frame="topbot" id="configuration-transaction-properties" revision="9"> + <title>Hibernate 트랜잭션 프로퍼티들</title> + <tgroup cols="2"> + <colspec colname="c1" colwidth="1*"/> + <colspec colname="c2" colwidth="1*"/> + <thead> + <row> + <entry>프로퍼티 이름</entry> + <entry>용도</entry> + </row> + </thead> + <tbody> + <row> + <entry> + <literal>hibernate.transaction.factory_class</literal> + </entry> + <entry> + Hibernate <literal>Transaction</literal> API 에 사용할 <literal>TransactionFactory</literal>의 + 클래스 이름.(디폴트는 <literal>JDBCTransactionFactory</literal>). + <para> + <emphasis role="strong">예.</emphasis> + <literal>classname.of.TransactionFactory</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>jta.UserTransaction</literal> + </entry> + <entry> + 어플리케이션 서버로부터 JTA <literal>UserTransaction</literal>을 얻기 위해 <literal>JTATransactionFactory</literal>에 + 의해 사용되는 JNDI 이름. + <para> + <emphasis role="strong">예.</emphasis> + <literal>jndi/composite/name</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.transaction.manager_lookup_class</literal> + </entry> + <entry> + <literal>TransactionManagerLookup</literal>의 클래스명- JVM 레벨의 캐싱이 이용 가능할 때 또는 JTA 환경에서 + hilo generator를 사용할 때 필요하다. + <para> + <emphasis role="strong">예.</emphasis> + <literal>classname.of.TransactionManagerLookup</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.transaction.flush_before_completion</literal> + </entry> + <entry> + 만일 사용가능하도록 되면, 세션은 트랜잭션의 before completion 단계 동안에 자동적으로 flush 될 것이다. + 빌드되어 있는 자동적인 세션 컨텍스트 관리가 선호되는데, + <xref linkend="architecture-current-session"/>를 보라. + <para> + <emphasis role="strong">예.</emphasis> + <literal>true</literal> | <literal>false</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.transaction.auto_close_session</literal> + </entry> + <entry> + 만일 사용가능토록 하면, after completion 단계 동안에 세션이 자동적으로 닫혀질 것이다. + (CMT에 대해 Hibernate를 사용할 때 매우 유용하다.) + <para> + <emphasis role="strong">예.</emphasis> + <literal>true</literal> | <literal>false</literal> + </para> + </entry> + </row> + </tbody> + </tgroup> + </table> + + <table frame="topbot" id="configuration-misc-properties" revision="10"> + <title>여러가지 프로퍼티들</title> + <tgroup cols="2"> + <colspec colname="c1" colwidth="1*"/> + <colspec colname="c2" colwidth="1*"/> + <thead> + <row> + <entry>프로퍼티 이름</entry> + <entry>용도</entry> + </row> + </thead> + <tbody> + <row> + <entry> + <literal>hibernate.current_session_context_class</literal> + </entry> + <entry> + "현재" <literal>Session</literal>의 영역화를 위한 하나의 (맞춤) 방도를 + 제공한다. 빌드되어 있는 방도들에 대한 추가 정보는 + <xref linkend="architecture-current-session"/>를 보라. + <para> + <emphasis role="strong">예.</emphasis> + <literal>jta</literal> | <literal>thread</literal> | + <literal>managed</literal> | <literal>custom.Class</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.query.factory_class</literal> + </entry> + <entry> + Chooses the HQL 파서 구현을 선택한다. + <para> + <emphasis role="strong">예.</emphasis> + <literal>org.hibernate.hql.ast.ASTQueryTranslatorFactory</literal> or + <literal>org.hibernate.hql.classic.ClassicQueryTranslatorFactory</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.query.substitutions</literal> + </entry> + <entry> + Hibernate 질의들 내의 토큰들로부터 SQL 토큰들로의 매핑 + (예를 들어 토큰들은 함수 이름 또는 리터럴 이름일 수 있다). + <para> + <emphasis role="strong">예.</emphasis> + <literal>hqlLiteral=SQL_LITERAL, hqlFunction=SQLFUNC</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.hbm2ddl.auto</literal> + </entry> + <entry> + <literal>SessionFactory</literal>가 생성될 때, 자동적으로 유효성을 검사하거나 + schema DDL을 데이터베이스로 내보내기 한다. <literal>create-drop</literal>의 경우, + <literal>SessionFactory</literal>가 명시적으로 닫혀질 때 데이터베이스 스키마가 + 드롭될 것이다. + <para> + <emphasis role="strong">예.</emphasis> + <literal>validate</literal> | <literal>update</literal> | + <literal>create</literal> | <literal>create-drop</literal> + </para> + </entry> + </row> + <row> + <entry> + <literal>hibernate.cglib.use_reflection_optimizer</literal> + </entry> + <entry> + 런타임 reflection 대신에 CGLIB의 사용을 가능하도록 만든다(시스템 레벨 프로퍼티). + Reflection은 문제가 발생할 시에 때때로 유용할 수 있고, + 당신이 optimizer를 사용하지 않을 경우조차도 Hibernate는 항상 필요로 함을 유의하라. + 당신은 <literal>hibernate.cfg.xml</literal> + 속에 이 프로퍼티를 설정할수 없다. + <para> + <emphasis role="strong">예.</emphasis> + <literal>true</literal> | <literal>false</literal> + </para> + </entry> + </row> + </tbody> + </tgroup> + </table> + + <sect2 id="configuration-optional-dialects" revision="1"> + <title>SQL Dialects</title> + + <para> + 당신은 항상 당신의 데이터베이스를 위해 <literal>hibernate.dialect</literal> 프로퍼티를 정확한 <literal>org.hibernate.dialect.Dialect</literal> + 서브클래스로 설정해야 한다. 만일 당신이 dialect를 지정할 경우, 당신이 프로퍼티들을 수작업으로 지정하는 노력을 절약하도록 Hibernate는 위에 열거된 다른 프로퍼티들 + 중 몇몇에 대해 의미있는 디폴트들을 사용할 것이다. + </para> + + <table frame="topbot" id="sql-dialects" revision="2"> + <title>Hibernate SQL Dialects (<literal>hibernate.dialect</literal>)</title> + <tgroup cols="2"> + <colspec colwidth="1*"/> + <colspec colwidth="2.5*"/> + <thead> + <row> + <entry>RDBMS</entry> + <entry>Dialect</entry> + </row> + </thead> + <tbody> + <row> + <entry>DB2</entry> <entry><literal>org.hibernate.dialect.DB2Dialect</literal></entry> + </row> + <row> + <entry>DB2 AS/400</entry> <entry><literal>org.hibernate.dialect.DB2400Dialect</literal></entry> + </row> + <row> + <entry>DB2 OS390</entry> <entry><literal>org.hibernate.dialect.DB2390Dialect</literal></entry> + </row> + <row> + <entry>PostgreSQL</entry> <entry><literal>org.hibernate.dialect.PostgreSQLDialect</literal></entry> + </row> + <row> + <entry>MySQL</entry> <entry><literal>org.hibernate.dialect.MySQLDialect</literal></entry> + </row> + <row> + <entry>MySQL with InnoDB</entry> <entry><literal>org.hibernate.dialect.MySQLInnoDBDialect</literal></entry> + </row> + <row> + <entry>MySQL with MyISAM</entry> <entry><literal>org.hibernate.dialect.MySQLMyISAMDialect</literal></entry> + </row> + <row> + <entry>Oracle (any version)</entry> <entry><literal>org.hibernate.dialect.OracleDialect</literal></entry> + </row> + <row> + <entry>Oracle 9i/10g</entry> <entry><literal>org.hibernate.dialect.Oracle9Dialect</literal></entry> + </row> + <row> + <entry>Sybase</entry> <entry><literal>org.hibernate.dialect.SybaseDialect</literal></entry> + </row> + <row> + <entry>Sybase Anywhere</entry> <entry><literal>org.hibernate.dialect.SybaseAnywhereDialect</literal></entry> + </row> + <row> + <entry>Microsoft SQL Server</entry> <entry><literal>org.hibernate.dialect.SQLServerDialect</literal></entry> + </row> + <row> + <entry>SAP DB</entry> <entry><literal>org.hibernate.dialect.SAPDBDialect</literal></entry> + </row> + <row> + <entry>Informix</entry> <entry><literal>org.hibernate.dialect.InformixDialect</literal></entry> + </row> + <row> + <entry>HypersonicSQL</entry> <entry><literal>org.hibernate.dialect.HSQLDialect</literal></entry> + </row> + <row> + <entry>Ingres</entry> <entry><literal>org.hibernate.dialect.IngresDialect</literal></entry> + </row> + <row> + <entry>Progress</entry> <entry><literal>org.hibernate.dialect.ProgressDialect</literal></entry> + </row> + <row> + <entry>Mckoi SQL</entry> <entry><literal>org.hibernate.dialect.MckoiDialect</literal></entry> + </row> + <row> + <entry>Interbase</entry> <entry><literal>org.hibernate.dialect.InterbaseDialect</literal></entry> + </row> + <row> + <entry>Pointbase</entry> <entry><literal>org.hibernate.dialect.PointbaseDialect</literal></entry> + </row> + <row> + <entry>FrontBase</entry> <entry><literal>org.hibernate.dialect.FrontbaseDialect</literal></entry> + </row> + <row> + <entry>Firebird</entry> <entry><literal>org.hibernate.dialect.FirebirdDialect</literal></entry> + </row> + </tbody> + </tgroup> + </table> + + </sect2> + + <sect2 id="configuration-optional-outerjoin" revision="4"> + <title>Outer Join Fetching</title> + + <para> + 만일 당신의 데이터베이스가 ANSI, Oracle, 또는 Sybase 스타일의 outer join들을 지원할 경우, <emphasis>outer join + fetching</emphasis>은 (데이터베이스 그 자체에 의해 보다 더 많은 작업이 수행되는 비용으로) 데이터베이스로의 그리고 + 데이터베이스로부터의 라운드 트립들의 개수를 제한함으로써 종종 퍼포먼스를 증가시킬 것이다. Outer join fetching은 + many-to-one, one-to-many, many-to-many,one-to-one 연관관계들이 에 의해 연결된 객체들의 전체 그래프가 + 하나의 SQL <literal>SELECT</literal> 속에서 검색되게끔 허용해준다. + </para> + + <para> + Outer join fetching은 hibernate.max_fetch_depth 프로퍼티를 <literal>0</literal>으로 설정함으로써 + <emphasis>전역적으로</emphasis> 사용 불가능하게 할 수 있다. <literal>1</literal> 이상의 값을 설정하는 + 것은 <literal>fetch="join"</literal>으로 매핑되었던 모든 one-to-one 및 many-to-one 연관관계들에 대해 + outer join fetching을 사용 가능하도록 만든다. + </para> + + <para> + 추가 정보는 <xref linkend="performance-fetching"/>를 보라. + </para> + + </sect2> + + <sect2 id="configuration-optional-binarystreams" revision="1"> + <title>Binary Streams</title> + + <para> + Oracle은 JDBC 드라이버 로/부터 전달되는 <literal>byte</literal> 배열들의 크기를 제한시킨다. 만일 당신이 + <literal>binary</literal> 또는 <literal>serializable</literal> 타입의 대형 인스턴스를 사용하고자 + 원할 경우에, 당신은 <literal>hibernate.jdbc.use_streams_for_binary</literal>를 사용 가능하게 해야 + 할 것이다. <emphasis>이것은 오직 시스템 레벨 설정이다.</emphasis> + </para> + + </sect2> + + <sect2 id="configuration-optional-cacheprovider" revision="2"> + <title>Second-level 캐시와 query 캐시</title> + + <para> + <literal>hibernate.cache</literal> 접두어가 붙은 프로퍼티들은 Hibernate에 대해 프로세스 또는 + 클러스터 범위의 두 번째 레벨 캐시 시스템을 사용하는 것을 허용해준다. 상세한 것은 + <xref linkend="performance-cache"/>를 보라. + </para> + + </sect2> + + <sect2 id="configuration-optional-querysubstitution"> + <title>Query Language 치환</title> + + <para> + 당신은 <literal>hibernate.query.substitutions</literal>을 사용하여 새로운 Hibernate 질의 토큰들을 + 정의할 수 있다. 예를 들어: + </para> + + <programlisting>hibernate.query.substitutions true=1, false=0</programlisting> + + <para> + 은<literal>true</literal>와 <literal>false</literal> 토큰들이 생성된 SQL 내에서 + 정수 리터럴들로 번역되도록 강제할 것이다. + </para> + + <programlisting>hibernate.query.substitutions toLowercase=LOWER</programlisting> + + <para> + 은 SQL <literal>LOWER</literal> function 함수 이름을 변경하는 것을 당신에게 허용해 줄 것이다 + </para> + + </sect2> + + <sect2 id="configuration-optional-statistics" revision="2"> + <title>Hibernate 통계</title> + + <para> + 만일 당신이 <literal>hibernate.generate_statistics</literal>를 사용 가능하도록 할 경우, Hibernate는 + <literal>SessionFactory.getStatistics()</literal>를 통해 가동 중인 시스템을 튜닝할 때 유용한 많은 통계들을 + 노출시킬 것이다. Hibernate는 심지어 JMX를 통해 이들 통계들을 노출시키도록 구성될 수 있다. 추가 정보는 + <literal>org.hibernate.stats</literal>에 있는 인터페이스들에 관한 Javadoc를 읽어라. + </para> + + </sect2> + </sect1> + + <sect1 id="configuration-logging"> + <title>로깅</title> + + <para> + Hibernate는 Apache commons-logging를 사용하여 다양한 이벤트들을 로그시킨다. + </para> + + <para> + commons-logging 서비스는 (만일 당신이 classpath 내에 <literal>log4j.jar</literal>를 포함할 경우) Apache Log4j로 + 또는 (JDK1.4 이상의 버전에서 실행될 경우) JDK 1.4 로깅으로 직접 출력할 것이다. 당신은 <literal>http://jakarta.apache.org</literal>에서 + Log4j를 다운로드 할 수 있다. Log4j를 사용하기 위해, 당신은 <literal>log4j.properties</literal> 파일을 당신의 classpath + 내에 위치지울 필요가 있을 것이고, 예제 properties 파일은 Hibernate의 <literal>src/</literal> 디렉토리 내에 배포되어 있다. + </para> + + <para> + 우리는 당신이 Hibernate의 로그 메시지들에 익숙해지기를 강력히 권장한다. 읽기 불가능하지 않게끔 가능한 한 상세하게 Hibernate 로그를 + 만들도록 많은 작업이 행해졌다. 그것은 본질적인 문제던지기 장치이다. 가장 흥미로운 로그 카테고리들이 다음에 있다: + </para> + + <table frame="topbot" id="log-categories" revision="2"> + <title>Hibernate 로그 카테고리들</title> + <tgroup cols="2"> + <colspec colwidth="1*"/> + <colspec colwidth="2.5*"/> + <thead> + <row> + <entry>카테고리</entry> + <entry>기능</entry> + </row> + </thead> + <tbody> + <row> + <entry><literal>org.hibernate.SQL</literal></entry> + <entry>SQL DML 문장들이 실행될 때 그것들 모두를 로그 시킨다</entry> + </row> + <row> + <entry><literal>org.hibernate.type</literal></entry> + <entry>모든 JDBC 파라미터들을 로그시킨다</entry> + </row> + <row> + <entry><literal>org.hibernate.tool.hbm2ddl</literal></entry> + <entry>SQL DDL 문장들이 실행될 때 그것들 모두를 로그 시킨다</entry> + </row> + <row> + <entry><literal>org.hibernate.pretty</literal></entry> + <entry> + flush 시점에서 세션과 연관된 모든 엔티티들(최대 20개의 엔티티들)의 상태를 로그 시킨다 + </entry> + </row> + <row> + <entry><literal>org.hibernate.cache</literal></entry> + <entry>모든 second-level 캐시 액티비티를 로그시킨다</entry> + </row> + <row> + <entry><literal>org.hibernate.transaction</literal></entry> + <entry>트랜잭션 관련 액티비티를 로그 시킨다</entry> + </row> + <row> + <entry><literal>org.hibernate.jdbc</literal></entry> + <entry>모든 JDBC 리소스 취득을 로그 시킨다</entry> + </row> + <row> + <entry><literal>org.hibernate.hql.ast.AST</literal></entry> + <entry> + 질의 파싱 동안에 HQL AST와 SQL AST를 로그시킨다 + </entry> + </row> + <row> + <entry><literal>org.hibernate.secure</literal></entry> + <entry>모든 JAAS 허가 요청들을 로그시킨다</entry> + </row> + <row> + <entry><literal>org.hibernate</literal></entry> + <entry> + 모든 것을 로그시킨다(많은 정보이지만, 문제해결에 매우 유용하다) + </entry> + </row> + </tbody> + </tgroup> + </table> + + <para> + Hibernate로 어플리케이션들을 개발할 때, 당신은 거의 항상 <literal>org.hibernate.SQL</literal> 카테고리에 대해 + 이용 가능한 <literal>debug</literal> 모드로 작업하거나, 다른 방법으로 <literal>hibernate.show_sql</literal> + 프로퍼티를 이용가능하게 하여 작업해야 할 것이다. + </para> + + + </sect1> + + <sect1 id="configuration-namingstrategy"> + <title><literal>NamingStrategy</literal> 구현하기</title> + + <para> + <literal>org.hibernate.cfg.NamingStrategy</literal> 인터페이스는 데이터베이스 객체들과 스키마 요소들에 대한 + "네이밍 표준"을 지정하는 것을 당신에게 허용해준다. + </para> + + <para> + 당신은 Java 식별자들로부터 데이터베이스 식별자들을 자동적으로 생성시키거나 매핑 파일에 주어진 "논리적" 컬럼과 테이블 + 이름들을 "물리적" 테이블과 컬럼 이름들로 자동적으로 처리하는 규칙들을 제공할 수 있다. 이 특징은 반복되는 잡음(예를 들어 + <literal>TBL_</literal>접두어들)을 제거함으로써, 매핑 문서의 말많은 장황함을 감소시키도록 도와준다. Hibernate에 + 의해 사용되는 디폴트 방도는 아주 작은 작품이다. + </para> + + <para> + 당신은 매핑들을 추가하기 이전에 <literal>Configuration.setNamingStrategy()</literal>를 호출함으로써 다른 방도를 + 지정할 수 있다: + </para> + + <programlisting><![CDATA[SessionFactory sf = new Configuration() + .setNamingStrategy(ImprovedNamingStrategy.INSTANCE) + .addFile("Item.hbm.xml") + .addFile("Bid.hbm.xml") + .buildSessionFactory();]]></programlisting> + + <para> + <literal>org.hibernate.cfg.ImprovedNamingStrategy</literal>는 어떤 어플리케이션들에 대한 유용한 시작점일 수 있는 + 미리 빌드된 방도이다. + </para> + + </sect1> + + <sect1 id="configuration-xmlconfig" revision="2"> + <title>XML 구성 파일</title> + + <para> + 구성에 대한 다른 접근법은 <literal>hibernate.cfg.xml</literal>로 명명된 파일 속에 전체 구성을 지정하는 것이다. 이 파일은 + <literal>hibernate.properties</literal> 파일에 대한 대용물로서 사용될 수 있거나, 만일 둘 다 존재할 경우에 프로퍼티들을 + 중복정의하는데 사용될 수 있다. + </para> + + <para> + XML 구성 파일은 디폴트로 당신의 <literal>CLASSPATH</literal>의 루트에 존재하는 것이 기대된다. 다음은 예제이다: + </para> + + <programlisting><![CDATA[<?xml version='1.0' encoding='utf-8'?> +<!DOCTYPE hibernate-configuration PUBLIC + "-//Hibernate/Hibernate Configuration DTD//EN" + "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd"> + +<hibernate-configuration> + + <!-- a SessionFactory instance listed as /jndi/name --> + <session-factory + name="java:hibernate/SessionFactory"> + + <!-- properties --> + <property name="connection.datasource">java:/comp/env/jdbc/MyDB</property> + <property name="dialect">org.hibernate.dialect.MySQLDialect</property> + <property name="show_sql">false</property> + <property name="transaction.factory_class"> + org.hibernate.transaction.JTATransactionFactory + </property> + <property name="jta.UserTransaction">java:comp/UserTransaction</property> + + <!-- mapping files --> + <mapping resource="org/hibernate/auction/Item.hbm.xml"/> + <mapping resource="org/hibernate/auction/Bid.hbm.xml"/> + + <!-- cache settings --> + <class-cache class="org.hibernate.auction.Item" usage="read-write"/> + <class-cache class="org.hibernate.auction.Bid" usage="read-only"/> + <collection-cache collection="org.hibernate.auction.Item.bids" usage="read-write"/> + + </session-factory> + +</hibernate-configuration>]]></programlisting> + + <para> + 당신이 볼 수 있듯이, 이 접근법의 장점은 구성에 대한 매핑 파일 이름들을 구체화 시키는 것이다. <literal>hibernate.cfg.xml</literal>은 + 또한 당신이 Hibernate 캐시를 튜닝해야할 때 보다 편리하다. <literal>hibernate.properties</literal> 또는 + <literal>hibernate.cfg.xml</literal> 중 어느 것을 사용하는가는 당신의 선택이다. XML 구문을 사용하는 위에 언급된 + 이점들을 제외하면 둘다 같은 것임을 노트하라. + </para> + + <para> + Hibernate 구성으로, Hibernate를 시작하는 것은 다음과 같이 간단하다 + </para> + + <programlisting><![CDATA[SessionFactory sf = new Configuration().configure().buildSessionFactory();]]></programlisting> + + <para> + 당신은 다음을 사용하여 다른 XML 구성 파일을 찾아낼 수 있다 + </para> + + <programlisting><![CDATA[SessionFactory sf = new Configuration() + .configure("catdb.cfg.xml") + .buildSessionFactory();]]></programlisting> + + </sect1> + + <sect1 id="configuration-j2ee" revision="1"> + <title>J2EE 어플리케이션 서버 통합</title> + + <para> + Hibernate는 J2EE 인프라스트럭처에 대한 다음 통합 점들을 갖고 있다: + </para> + + <itemizedlist> + <listitem> + <para> + <emphasis>Container-managed datasources</emphasis>: Hibernate는 컨테이너에 의해 관리되는 JDBC 커넥션들을 + 사용할 수 있고 JNDI를 통해 제공된다. 대개 JTA 호환 <literal>TransactionManager</literal>와 <literal>ResourceManager</literal>는 + 트랜잭션 관리(CMT), 특히 몇몇 데이터소스들을 가로질러 분산된 트랜잭션 핸들링을 처리한다. 물론 당신은 또한 프로그램 상으로 + 트랜잭션 경계들을 한정할 수도 있거나(BMT) 당신은 당신의 코드가 이식성을 유지하도록 이것에 대한 선택적인 Hibernate + <literal>Transaction</literal> API를 사용하고자 원할 수도 있다. + </para> + </listitem> + </itemizedlist> + + <itemizedlist> + <listitem> + <para> + <emphasis>자동적인 JNDI 바인딩</emphasis>: Hibernate는 시작 후에 그것의 <literal>SessionFactory</literal>를 + JNDI에 바인드 시킬 수 있다. + </para> + </listitem> + </itemizedlist> + + <itemizedlist> + <listitem> + <para> + <emphasis>JTA Session 바인딩</emphasis>: Hibernate <literal>Session</literal>은 + JTA 트랜잭션들의 영역(scope)에 자동적으로 바인드 시킬 수도 있다. 간단하게 JNDI로부터 <literal>SessionFactory</literal>를 + 룩업하고 현재 <literal>Session</literal>을 얻어라. Hibernate로 하여금 당신의 JTA 트랜잭션이 완료될 때 <literal>Session</literal>을 + flush시키고 닫는 것을 처리하도록 하라. 트랜잭션 경계 구분은 선언적(CMT)이거나 프로그래밍적((BMT/UserTransaction))이다. + </para> + </listitem> + </itemizedlist> + + <itemizedlist> + <listitem> + <para> + <emphasis>JMX 배치</emphasis>: 만일 당신이 JMX 가용성이 있는 어플리케이션 서버(예를 들면 JBoss AS)를 갖고 있다면, + 당신은 Hibernate를 하나의 managed MBean으로서 배치하는 것을 선택할 수 있다. 이것은 <literal>Configuration</literal>으로부터 + 당신의 <literal>SessionFactory</literal>를 빌드 시키는 한 줄의 시작 코드를 절약해준다. 컨테이너는 당신의 <literal>HibernateService</literal>를 + 시작할 것이고, 또한 이상적으로 서비스 의존성들을 처리할 것이다(데이터소스는 Hibernate가 시작되기 전에 이용 가능해야 한다). + </para> + </listitem> + </itemizedlist> + + <para> + 당신의 환경에 따라, 당신은 당신의 어플리케이션 서버가 "connection containment(연결 봉쇄)" 예외상황들을 보일 경우에 구성 옵션 + <literal>hibernate.connection.aggressive_release</literal>를 true로 설정해야 될 수도 있다. + </para> + + <sect2 id="configuration-optional-transactionstrategy" revision="3"> + <title>트랜잭션 방도 구성</title> + + <para> + Hibernate <literal>Session</literal> API는 당신의 아카텍처 내에서 임의의 트랜잭션 관할 시스템에 독립적이다. 만일 + 당신이 Hibernate로 하여금 커넥션 풀을 통해 직접 JDBC를 사용하도록 강제할 경우, 당신은 JDBC API를 호출하여 당신의 트랜잭션을 + 시작하고 끝낼 수 있다. 만일 당신이 J2EE 어플리케이션 서버를 실행 중이라면, 당신은 필요할 때 bean-managed 트랜잭션들을 사용하고 + JTA API와 <literal>UserTransaction</literal>을 호출하고자 원할 수 있다. + </para> + + <para> + 이들 두 개의 (그리고 다른) 환경들에서 당신의 코드에 이식성을 유지하기 위해 우리는 기본 시스템을 포장하고 은폐시키는 선택적인 + Hibernate <literal>Transaction</literal> API를 권장한다. 당신은 Hibernate 구성 프로퍼티 <literal>hibernate.transaction.factory_class</literal>를 + 사용하여 <literal>Transaction</literal> 인스턴스들에 대한 팩토리 클래스를 지정해야 한다. + </para> + + <para> + 세 개의 표준(미리 만들어진) 선택들이 존재한다: + </para> + + <variablelist spacing="compact"> + <varlistentry> + <term><literal>org.hibernate.transaction.JDBCTransactionFactory</literal></term> + <listitem> + <para>데이터베이스 (JDBC) 트랜잭션들에게 위임시킨다(디폴트)</para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>org.hibernate.transaction.JTATransactionFactory</literal></term> + <listitem> + <para> + 기존의 트랜잭션이 이 컨텍스트(예를 들면 EJB session bean 메소드) 내에서 진행 중일 경우에 + container-managed transaction에게 위임시키고, 그 밖의 경우 새로운 트랜잭션이 시작되고 + bean-managed transaction이 사용된다. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>org.hibernate.transaction.CMTTransactionFactory</literal></term> + <listitem> + <para>container-managed JTA 트랜잭션들에게 위임시킨다</para> + </listitem> + </varlistentry> + </variablelist> + + <para> + 당신은 또한 당신 자신의 트랜잭션 방도들(예를 들면 CORBA 트랜잭션 서비스)을 정의할 수도 있다. + </para> + + <para> + Hibernate에 있는 몇몇 특징들(예를 들면. second level 캐시, JTA를 가진 컨텍스트 상의 세션들, 기타.)은 관리되는 환경에서 + JTA <literal>TransactionManager</literal>에 대한 접근을 필요로 한다. 어플리케이션 서버에서 당신은 Hibernate가 + <literal>TransactionManager</literal>에 대한 참조를 획득하는 방법을 지정해야 한다. 왜냐하면 J2EE가 한 개의 메커니즘을 + 표준화 시키고 있지 않기 때문이다: + </para> + + <table frame="topbot" id="jtamanagerlookup" revision="1"> + <title>JTA TransactionManagers</title> + <tgroup cols="2"> + <colspec colwidth="2.5*"/> + <colspec colwidth="1*"/> + <thead> + <row> + <entry>트랜잭션 팩토리</entry> + <entry align="center">어플리케이션 서버</entry> + </row> + </thead> + <tbody> + <row> + <entry><literal>org.hibernate.transaction.JBossTransactionManagerLookup</literal></entry> + <entry align="center">JBoss</entry> + </row> + <row> + <entry><literal>org.hibernate.transaction.WeblogicTransactionManagerLookup</literal></entry> + <entry align="center">Weblogic</entry> + </row> + <row> + <entry><literal>org.hibernate.transaction.WebSphereTransactionManagerLookup</literal></entry> + <entry align="center">WebSphere</entry> + </row> + <row> + <entry><literal>org.hibernate.transaction.WebSphereExtendedJTATransactionLookup</literal></entry> + <entry align="center">WebSphere 6</entry> + </row> + <row> + <entry><literal>org.hibernate.transaction.OrionTransactionManagerLookup</literal></entry> + <entry align="center">Orion</entry> + </row> + <row> + <entry><literal>org.hibernate.transaction.ResinTransactionManagerLookup</literal></entry> + <entry align="center">Resin</entry> + </row> + <row> + <entry><literal>org.hibernate.transaction.JOTMTransactionManagerLookup</literal></entry> + <entry align="center">JOTM</entry> + </row> + <row> + <entry><literal>org.hibernate.transaction.JOnASTransactionManagerLookup</literal></entry> + <entry align="center">JOnAS</entry> + </row> + <row> + <entry><literal>org.hibernate.transaction.JRun4TransactionManagerLookup</literal></entry> + <entry align="center">JRun4</entry> + </row> + <row> + <entry><literal>org.hibernate.transaction.BESTransactionManagerLookup</literal></entry> + <entry align="center">Borland ES</entry> + </row> + </tbody> + </tgroup> + </table> + + </sect2> + + <sect2 id="configuration-optional-jndi" revision="3"> + <title>JNDI-bound <literal>SessionFactory</literal></title> + + <para> + 하나의 JNDI 바인드된 Hibernate <literal>SessionFactory</literal>는 그 팩토리에 대한 룩업과 새로운 + <literal>Session</literal>들의 생성을 단순화 시킬 수 있다. 이것은 JNDI 바인드된 <literal>Datasource</literal>에 + 관련되어 있지 않고, 단순하게 둘 다 동일한 레지스트리를 사용한다는 점을 노트하라! + </para> + + <para> + 만일 당신이 <literal>SessionFactory</literal>를 하나의 JNDI namespace에 바인드 시키고자 원할 경우, + <literal>hibernate.session_factory_name</literal> 프로퍼티를 사용하여 한 개의 이름(예를 들면. + <literal>java:hibernate/SessionFactory</literal>)을 지정하라. 만일 이 프로퍼티가 생략될 경우, + <literal>SessionFactory</literal>는 JNDI에 바인드 되지 않을 것이다. (이것은 읽기-전용 JNDI 디폴트 + 구현을 가진 환경들, 예를 들면 Tomcat에서 특히 유용하다.) + </para> + + <para> + <literal>SessionFactory</literal>를 JNDI에 바인드 시킬 때, Hibernate는 초기 컨텍스트를 초기화 시키기 위해 + <literal>hibernate.jndi.url</literal>, <literal>hibernate.jndi.class</literal>의 값들을 사용할 것이다. + 만일 그것들이 지정되어 있지 않을 경우, 디폴트 <literal>InitialContext</literal>가 사용될 것이다. + </para> + + <para> + Hibernate는 당신이 <literal>cfg.buildSessionFactory()</literal>를 호출한 후에 <literal>SessionFactory</literal>를 JNDI 내에 + 자동적으로 위치지울 것이다. 이것은 당신이 (나중에 논의되는) <literal>HibernateService</literal>를 가진 JMX 배치를 + 사용하지 않는 한, 당신이 적어도 당신의 어플리케이션 내에 있는 어떤 시작 코드 (또는 유틸리티 클래스) 내에서 이것을 호출할 것임을 + 의미한다. + </para> + + <para> + 만일 당신이 하나의 JNDI <literal>SessionFactory</literal>를 사용할 경우, 하나의 EJB 또는 어떤 다른 클래스는 JNDI + 룩업을 사용하여 <literal>SessionFactory</literal>를 얻을 수 있다. + </para> + + <para> + 우리는 관리되는 환경들에서 <literal>SessionFactory</literal>를 JNDI에 바인드 시키고 그 밖의 경우에는 + 하나의 <literal>static</literal> 싱글톤을 사용하는 것을 권장한다. 이들 상세로부터 당신의 어플리케이션 코드를 + 은폐시키기 위해, 우리는 또한 <literal>HibernateUtil.getSessionFactory()</literal>과 같은 하나의 + helper 클래스 내에서 <literal>SessionFactory</literal>에 대한 실제 룩업 코드를 은폐시키기를 권장한다. + 그런 클래스는 또한 Hibernate를 시작하는 편리한 방법임을 노트하라&mdash; 1장을 보라. + </para> + + </sect2> + + <sect2 id="configuration-j2ee-currentsession" revision="4"> + <title>Current Session context management with JTA</title> + + <para> + 당신 자신의 <literal>ThreadLocal</literal> 유틸리티를 작동시키는 대신에, 우리는 또한 Hibernate <literal>Session</literal>를 + 얻기 위해 <literal>SessionFactory</literal> 상의 <literal>getCurrentSession()</literal> 메소드 사용을 + 권장한다. <xref linkend="architecture-current-session">현재 세션들</xref>에 관한 논의를 보라. <literal>"jta"</literal> + 세션 컨텍스트를 사용하고 있는 경우에, 현재의 JTA 트랜잭션으로 시작되고 연관된 Hibernate <literal>Session</literal>이 + 존재하지 않을 경우, 우리는 JTA 트랜잭션으로 시작되고 연관될 것이다. <literal>"jta"</literal> 컨텍스트에서 + <literal>getCurrentSession()</literal>를 통해 검색된 <literal>Session</literal>들은 그 트랜잭션이 완료되기 전에 + 자동적으로 flush될 것이고 트랜잭션 완료 후에 닫혀질 것이고, 그리고 각각의 문장 뒤에 JDBC 커넥션들을 적극적으로 해제할 것이다. + 이것은 그런 관리 사항들에 대해 사용자 코드를 명료하게 유지시켜서, 연관되어 있는 JTA 트랜잭션의 생명주기에 의해 <literal>Session</literal>들이 + 관리되도록 허용해준다. 이것은 그런 관리 사항들에 대해 사용자 코드를 명료하게 유지시켜서, 세션이 연관되어 있는 JTA 트랜잭션의 + 생명주기에 의해 관리되는 것을 <literal>Session</literal>들에게 허용해준다. 당신의 코드는 + + <literal>Session</literal>들과 트랜잭션들을 처리하는 가장 손쉬운 방법은 Hibernate의 자동적인 "현재" + <literal>Session</literal>이다. + <xref linkend="architecture-current-session">current sessions</xref>에 관한 논의를 보라. + <literal>"jta"</literal> 세션 컨텍스트를 사용하는 경우, 현재의 JTA 트랜잭션으로 시작되고 연관된 + Hibernate <literal>Session</literal>들이 존재하지 않을 경우, 당신이 + <literal>sessionFactory.getCurrentSession()</literal>을 처음 호출할 때 하나의 세션이 현재의 JTA 트랜잭션에 대해 + 시작되고 연관될 것이다. <literal>"jta"</literal> 컨텍스트에서 <literal>getCurrentSession()</literal>을 + 통해 검색된 <literal>Session</literal>들은 그 트랜잭션이 완료되기 전에 자동적으로 flush될 것이고 + 그 트랜잭션 완료들 후에 닫혀질 것이고 각각의 문장 후에 JDBC 커넥션들을 적극적으로 해제할 것이다. + 이것은 그런 관리 사항들에 대해 사용자 코드를 명료하게 유지시켜서, 연관되어 있는 JTA 트랜잭션의 생명주기에 의해 <literal>Session</literal>들이 + 관리되도록 허용해준다. 이것은 그런 관리 사항들에 대해 사용자 코드를 명료하게 유지시켜서, 세션이 연관되어 있는 JTA 트랜잭션의 + 생명주기에 의해 관리되는 것을 <literal>Session</literal>들에게 허용해준다. 당신의 코드는 트랜잭션 경계들을 설정하는데 + <literal>UserTransaction</literal>을 통해 프로그램 상으로 JTA를 사용하거나, Hibernate <literal>Transaction</literal> API를 (이식성을 위한 코드로 권장됨) + 사용할 수 있다. 만일 당신이 하나의 EJB 컨테이너에서 실행하고 있을 경우, CMT의 경우에 선언적인 트랜잭션 경계설정이 선호된다. + </para> + + </sect2> + + <sect2 id="configuration-j2ee-jmx" revision="1"> + <title>JMX 배치</title> + + <para> + <literal>cfg.buildSessionFactory()</literal> 줄은 여전히 JNDI에 붙은 하나의 <literal>SessionFactory</literal>를 얻기 위해 + 어딘가에서 실행되어야 한다. 당신은 (<literal>HibernateUtil</literal> 내에 있는 것처럼) <literal>static</literal> initializer + 블록 속에서 이것을 행할 수 있거나 당신은 Hibernate를 <emphasis>managed service</emphasis>로서 배치할 수 있다. + </para> + + <para> + Hibernate는 JBoss AS와 같은 JMX 가용성들을 가진 어플리케이션 서버 상의 배치를 위해 <literal>org.hibernate.jmx.HibernateService</literal>를 + 배포하고 있다. 실제 배치와 구성은 벤더 지정적이다. 다음은 JBoss 4.0.x를 위한 <literal>jboss-service.xml</literal> 예제이다: + </para> + + <programlisting><![CDATA[<?xml version="1.0"?> +<server> + +<mbean code="org.hibernate.jmx.HibernateService" + name="jboss.jca:service=HibernateFactory,name=HibernateFactory"> + + <!-- Required services --> + <depends>jboss.jca:service=RARDeployer</depends> + <depends>jboss.jca:service=LocalTxCM,name=HsqlDS</depends> + + <!-- Bind the Hibernate service to JNDI --> + <attribute name="JndiName">java:/hibernate/SessionFactory</attribute> + + <!-- Datasource settings --> + <attribute name="Datasource">java:HsqlDS</attribute> + <attribute name="Dialect">org.hibernate.dialect.HSQLDialect</attribute> + + <!-- Transaction integration --> + <attribute name="TransactionStrategy"> + org.hibernate.transaction.JTATransactionFactory</attribute> + <attribute name="TransactionManagerLookupStrategy"> + org.hibernate.transaction.JBossTransactionManagerLookup</attribute> + <attribute name="FlushBeforeCompletionEnabled">true</attribute> + <attribute name="AutoCloseSessionEnabled">true</attribute> + + <!-- Fetching options --> + <attribute name="MaximumFetchDepth">5</attribute> + + <!-- Second-level caching --> + <attribute name="SecondLevelCacheEnabled">true</attribute> + <attribute name="CacheProviderClass">org.hibernate.cache.EhCacheProvider</attribute> + <attribute name="QueryCacheEnabled">true</attribute> + + <!-- Logging --> + <attribute name="ShowSqlEnabled">true</attribute> + + <!-- Mapping files --> + <attribute name="MapResources">auction/Item.hbm.xml,auction/Category.hbm.xml</attribute> + +</mbean> + +</server>]]></programlisting> + + <para> + 이 파일은 <literal>META-INF</literal>로 명명된 디렉토리 속에 배치되고 확장자 <literal>.sar</literal> + (service archive)를 가진 한 개의 JAR 파일 속에 패키징된다. 당신은 또한 Hibernate, 그것의 필요한 제 3의 라이브러리들, 당신의 컴파일된 + 영속 클래스들 뿐만 아니라 당신의 매핑 파일들을 동일한 아카이브 속에 패키징할 필요가 있다. 당신의 엔터프라이즈 빈즈(대개 session beans)는 + 그것들 자신의 JAR 파일 속에 유지될 수 있지만, 당신은 한 개의 (hot-)배치 가능한 단위를 얻기 위해 메인 서비스 아카이브 속에 이 EJB JAR 파일을 + 포함시킬 수도 있다. JMX 서비스와 EJB 배치에 관한 추가 정보는 JBoss AS 문서를 참조하라. + </para> + + </sect2> + + </sect1> + +</chapter> + Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/events.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/events.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/events.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/events.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,255 @@ +<chapter id="events"> + <title>인터셉터들과 이벤트들</title> + + <para> + 어플리케이션이 Hibernate 내부에서 발생하는 어떤 이벤트들에 대해 반응하는 것에 흔히 유용하다. 이것은 어떤 종류의 일반적인 기능, + 그리고 Hibernate의 확장 기능의 구현을 허용해준다. + </para> + + <sect1 id="objectstate-interceptors" revision="3"> + <title>인터셉터들</title> + + <para> + <literal>Interceptor</literal> 인터페이스는 영속 객체가 저장되고, 업데이트되고, 삭제되거나 로드되기 전에 영속 객체의 + 프로퍼티들을 조사하고/하거나 처리하는 것을 어플리케이션에 허용해줌으로써 세션으로부터 어플리케이션으로의 콜백들을 제공한다. + 이것에 대한 한 가지 가능한 사용은 감사 정보를 추적하는 것이다. 예를 들어, 다음 <literal>Interceptor</literal>는 + <literal>Auditable</literal>이 생성될 때 <literal>createTimestamp</literal>를 자동적으로 설정하고 + <literal>Auditable</literal>이 업데이트될 때 <literal>lastUpdateTimestamp</literal> 프로퍼티를 업데이트 한다. + </para> + + <para> + 당신은 <literal>Interceptor</literal>를 직접 구현해야 하거나 (더 좋게는) + <literal>EmptyInterceptor</literal>를 확장(extend)해야 한다. + </para> + + <programlisting><![CDATA[package org.hibernate.test; + +import java.io.Serializable; +import java.util.Date; +import java.util.Iterator; + +import org.hibernate.EmptyInterceptor; +import org.hibernate.Transaction; +import org.hibernate.type.Type; + +public class AuditInterceptor extends EmptyInterceptor { + + private int updates; + private int creates; + private int loads; + + public void onDelete(Object entity, + Serializable id, + Object[] state, + String[] propertyNames, + Type[] types) { + // do nothing + } + + public boolean onFlushDirty(Object entity, + Serializable id, + Object[] currentState, + Object[] previousState, + String[] propertyNames, + Type[] types) { + + if ( entity instanceof Auditable ) { + updates++; + for ( int i=0; i < propertyNames.length; i++ ) { + if ( "lastUpdateTimestamp".equals( propertyNames[i] ) ) { + currentState[i] = new Date(); + return true; + } + } + } + return false; + } + + public boolean onLoad(Object entity, + Serializable id, + Object[] state, + String[] propertyNames, + Type[] types) { + if ( entity instanceof Auditable ) { + loads++; + } + return false; + } + + public boolean onSave(Object entity, + Serializable id, + Object[] state, + String[] propertyNames, + Type[] types) { + + if ( entity instanceof Auditable ) { + creates++; + for ( int i=0; i<propertyNames.length; i++ ) { + if ( "createTimestamp".equals( propertyNames[i] ) ) { + state[i] = new Date(); + return true; + } + } + } + return false; + } + + public void afterTransactionCompletion(Transaction tx) { + if ( tx.wasCommitted() ) { + System.out.println("Creations: " + creates + ", Updates: " + updates, "Loads: " + loads); + } + updates=0; + creates=0; + loads=0; + } + +}]]></programlisting> + + <para> + 인터셉터들은 다음 두 개의 특징들로 나타난다: <literal>Session</literal>-영역화 그리고 + <literal>SessionFactory</literal>-영역화. + </para> + + <para> + <literal>Session</literal>-영역의 인터셉터는 세션이 하나의 <literal>Interceptor</literal>를 수용하는 + 오버로드된 SessionFactory.openSession() 메소드들 중 하나를 사용하여 열릴 때 + 지정된다. + </para> + + <programlisting><![CDATA[Session session = sf.openSession( new AuditInterceptor() );]]></programlisting> + + <para> + 당신은 또한 <literal>Configuration</literal>을 사용하여 인터셉터를 전역 레벨 상에 설정할 수도 있다. + 이 경우에, 인터셉터는 threadsafe이어야 한다. + </para> + + <programlisting><![CDATA[Session session = sf.openSession( new AuditInterceptor() );]]></programlisting> + + <para> + <literal>SessionFactory</literal>-영역의 인터셉터는 <literal>SessionFactory</literal>을 빌드하기에 앞서 + <literal>Configuration</literal> 객체에 등록된다. 이 경우에, 공급되는 인터셉터는 그 <literal>SessionFactory</literal>로부터 + 열려진 모든 세션들에 적용될 것이다; 하나의 세션이 사용할 인터셉터를 명시적으로 지정하여 열리지 않는 한 이것은 참이다. + <literal>SessionFactory</literal>-영역의 인터셉터들은 세션-지정적인 상태를 저장하지 않도록 주의하여 쓰레드-안전해야 한다. + 왜냐하면 다중 세션들은 (잠정적으로) 이 인터셉터를 동시적으로 사용할 것이기 때문이다. + </para> + + <programlisting><![CDATA[new Configuration().setInterceptor( new AuditInterceptor() );]]></programlisting> + + </sect1> + + <sect1 id="objectstate-events" revision="4"> + <title>이벤트 시스템</title> + + <para> + 만일 당신이 당신의 영속 계층에서 특정 이벤트들에 대해 반응해야 한다면, 당신은 또한 Hibernate3 <emphasis>event</emphasis> + 아키텍처를 사용할 수도 있다. 이벤트 시스템은 부가물로 사용될 수 있거나 인터셉터들에 대한 대체물로 사용될 수 있다. + </para> + + <para> + 본질적으로 <literal>Session</literal> 인터페이스의 모든 메소드들은 이벤트와 서로 관련되어 있다. + 당신은 <literal>LoadEvent</literal>, + <literal>FlushEvent</literal>, 등을 갖는다 (정의된 이벤트 타입들의 전체 리스트에 대해서는 XML 구성 파일 DTD 또는 + <literal>org.hibernate.event</literal> 패키지를 참조하라). 하나의 요청이 이들 메소드들 중 하나에 의해 만들어질 때, + Hibernate <literal>Session</literal>은 적절한 이벤트를 생성시키고 그것을 그 타입의 구성된 이벤트 리스너에게 전달한다. + 박싱없이, 이들 리스너들은 그들 메소드들이 항상 귀결되었던 동일한 프로세싱을 구현한다. 하지만 당신이 리스너 인터페이스들 중 하나의 맞춤을 + 구현하는 것이 자유롭고(예를 들어 <literal>LoadEvent</literal>는 <literal>LoadEventListener</literal> 인터페이스의 + 등록된 구현에 의해 처리된다), 그 경우에 그들 구현은 <literal>Session</literal>에 대해 행해진 임의의 <literal>load()</literal> + 요청들을 처리할 책임이 있을 것이다. + </para> + + <para> + 리스너들은 효율적이게끔 싱글톤(singleton)들로 간주되어야 할 것이다; 이것은 그것들이 요청들 사이에서 공유되고, 따라서 임의의 상태를 + 인스턴스 변수들로서 저장하지 말아야 함을 의미한다. + </para> + + <para> + 맞춤형 리스너는 그것이 편의적인 기저 클래스들(또는 리스너들이 이 용도로 final이 아닌 것으로 선언되므로 Hibernate + out-of-the-box에 의해 사용된 디폴트 이벤트 리스너들) 중 하나를 처리하고/하거나 확장하고자 원하는 이벤트들에 대해 + 적절한 인터페이스를 구현해야 한다. 맞춤형 리스너들은 <literal>Configuration</literal> 객체를 통해 프로그램 상으로 + 등록될 수 있거나, Hibernate 구성 XML 속에 지정될 수 있다 (properties 파일을 통한 선언적인 구성은 지원되지 않는다). + 다음은 맞춤형 load 이벤트 리스너에 대한 예제이다: + </para> + + <programlisting><![CDATA[public class MyLoadListener implements LoadEventListener { + // this is the single method defined by the LoadEventListener interface + public void onLoad(LoadEvent event, LoadEventListener.LoadType loadType) + throws HibernateException { + if ( !MySecurity.isAuthorized( event.getEntityClassName(), event.getEntityId() ) ) { + throw MySecurityException("Unauthorized access"); + } + } +}]]></programlisting> + + <para> + 당신은 또한 디폴트 리스너에 덧붙여 그 리스너를 사용하도록 Hibernate에게 알려주는 구성 엔트리를 필요로 한다: + </para> + +<programlisting><![CDATA[<hibernate-configuration> + <session-factory> + ... + <event type="load"> + <listener class="com.eg.MyLoadListener"/> + <listener class="org.hibernate.event.def.DefaultLoadEventListener"/> + </event> + </session-factory> +</hibernate-configuration>]]></programlisting> + + <para> + 대신에 당신은 그것을 프로그래밍 방식으로 등록할 수도 있다: + </para> + + <programlisting><![CDATA[Configuration cfg = new Configuration(); +LoadEventListener[] stack = { new MyLoadListener(), new DefaultLoadEventListener() }; +cfg.EventListeners().setLoadEventListeners(stack);]]></programlisting> + + <para> + 선언적으로 등록된 리스너들은 인스턴스들을 공유할 수 없다. 만일 동일한 클래스 이름이 여러 개의 <literal>&lt;listener/&gt;</literal> + 요소들에서 사용될 경우, 각각의 참조는 그 클래스에 대한 별도의 인스턴스로 귀결될 것이다. 만일 당신이 리스너 타입들 사이에서 리스너 인스턴스들을 + 공유할 가용성을 필요로 할 경우 당신은 프로그래밍 방식의 등록 접근법을 사용해야 한다. + </para> + + <para> + 구성 동안에 왜 인터페이스를 구현하고 특정 타입을 지정하는가? 물론 리스너 구현은 여러 개의 이벤트 리스너 인터페이스들을 + 구현할 수 있다. 등록 동안에 추가적으로 타입을 정의하는 것은 컨피그레이션 동안에 맞춤형 리스너들의 사용 여부를 전환시키는 것을 + 더 쉽게 해준다. + </para> + + </sect1> + + <sect1 id="objectstate-decl-security" revision="2"> + <title>Hibernate 선언적인 보안</title> + <para> + 대개 Hibernate 어플리케이션들에서 선언적인 보안은 session facade 계층 내에서 관리된다. 이제, Hibernate3는 어떤 액션들이 + JACC를 통해 퍼미션을 주어지고, JAAS를 통해 인가되는 것을 허용해준다. 이것은 모든 아키텍처의 상단에 빌드된 옵션 기능이다. + </para> + + <para> + 먼저, 당신은 JAAS authorization 사용을 이용 가능하도록 하기 위해 적절한 이벤트 리스터들을 구성해야 한다. + </para> + + <programlisting><![CDATA[<listener type="pre-delete" class="org.hibernate.secure.JACCPreDeleteEventListener"/> +<listener type="pre-update" class="org.hibernate.secure.JACCPreUpdateEventListener"/> +<listener type="pre-insert" class="org.hibernate.secure.JACCPreInsertEventListener"/> +<listener type="pre-load" class="org.hibernate.secure.JACCPreLoadEventListener"/>]]></programlisting> + + <para> + <literal>&lt;listener type="..." class="..."/&gt;</literal>는 특정 이벤트 타입에 대해 정확히 한 개의 + 리스너가 존재할 때 단지 <literal>&lt;event type="..."&gt;&lt;listener class="..."/&gt;&lt;/event&gt;</literal>의 + 단축형임을 노트하라. + </para> + + <para> + 다음으로, 여전히 <literal>hibernate.cfg.xml</literal> 내에서 퍼미션들을 role들에 바인드 시킨다 : + </para> + + <programlisting><![CDATA[<grant role="admin" entity-name="User" actions="insert,update,read"/> +<grant role="su" entity-name="User" actions="*"/>]]></programlisting> + + <para> + 역할(role) 이름들은 당신의 JACC 프로바이더에 의해 인지된 역할(role)들이다. + </para> + + </sect1> + +</chapter> + Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/example_mappings.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/example_mappings.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/example_mappings.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/example_mappings.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,667 @@ +<!-- + ~ Copyright (c) 2007, Red Hat Middleware, LLC. All rights reserved. + ~ + ~ This copyrighted material is made available to anyone wishing to use, modify, + ~ copy, or redistribute it subject to the terms and conditions of the GNU + ~ Lesser General Public License, v. 2.1. This program is distributed in the + ~ hope that it will be useful, but WITHOUT A WARRANTY; without even the implied + ~ warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + ~ Lesser General Public License for more details. You should have received a + ~ copy of the GNU Lesser General Public License, v.2.1 along with this + ~ distribution; if not, write to the Free Software Foundation, Inc., + ~ 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + ~ + ~ Red Hat Author(s): Steve Ebersole + --> +<chapter id="example-mappings"> + <title>예제: 여러 가지 매핑들</title> + + <para> + 이 장은 몇몇 보다 복잡한 연관 매핑들을 보여준다. + </para> + + <sect1 id="example-mappings-emp"> + <title>Employer/Employee</title> + + <para> + <literal>Employer</literal>와 <literal>Employee</literal> 사이의 관계에 대한 다음 모형은 그 연관를 표현하는 데 + 실제 엔티티 클래스(<literal>Employment</literal>)를 사용한다. 동일한 두 부분들에 대해 하나 이상의 채용 주기가 존재할 수 있기 + 때문에 이것이 행해진다. 컴포넌트들이 화폐 값들과 종업원 이름들을 모형화 시키는데 사용된다. + </para> + + <mediaobject> + <imageobject role="fo"> + <imagedata fileref="../images/EmployerEmployee.png" format="PNG" align="center"/> + </imageobject> + <imageobject role="html"> + <imagedata fileref="../images/EmployerEmployee.png" format="PNG" align="center"/> + </imageobject> + </mediaobject> + + <para> + 다음은 가능한 매핑 문서이다: + </para> + + <programlisting><![CDATA[<hibernate-mapping> + + <class name="Employer" table="employers"> + <id name="id"> + <generator class="sequence"> + <param name="sequence">employer_id_seq</param> + </generator> + </id> + <property name="name"/> + </class> + + <class name="Employment" table="employment_periods"> + + <id name="id"> + <generator class="sequence"> + <param name="sequence">employment_id_seq</param> + </generator> + </id> + <property name="startDate" column="start_date"/> + <property name="endDate" column="end_date"/> + + <component name="hourlyRate" class="MonetaryAmount"> + <property name="amount"> + <column name="hourly_rate" sql-type="NUMERIC(12, 2)"/> + </property> + <property name="currency" length="12"/> + </component> + + <many-to-one name="employer" column="employer_id" not-null="true"/> + <many-to-one name="employee" column="employee_id" not-null="true"/> + + </class> + + <class name="Employee" table="employees"> + <id name="id"> + <generator class="sequence"> + <param name="sequence">employee_id_seq</param> + </generator> + </id> + <property name="taxfileNumber"/> + <component name="name" class="Name"> + <property name="firstName"/> + <property name="initial"/> + <property name="lastName"/> + </component> + </class> + +</hibernate-mapping>]]></programlisting> + + <para> + 그리고 다음은 <literal>SchemaExport</literal>에 의해 생성된 테이블 스키마이다. + </para> + + <programlisting><![CDATA[create table employers ( + id BIGINT not null, + name VARCHAR(255), + primary key (id) +) + +create table employment_periods ( + id BIGINT not null, + hourly_rate NUMERIC(12, 2), + currency VARCHAR(12), + employee_id BIGINT not null, + employer_id BIGINT not null, + end_date TIMESTAMP, + start_date TIMESTAMP, + primary key (id) +) + +create table employees ( + id BIGINT not null, + firstName VARCHAR(255), + initial CHAR(1), + lastName VARCHAR(255), + taxfileNumber VARCHAR(255), + primary key (id) +) + +alter table employment_periods + add constraint employment_periodsFK0 foreign key (employer_id) references employers +alter table employment_periods + add constraint employment_periodsFK1 foreign key (employee_id) references employees +create sequence employee_id_seq +create sequence employment_id_seq +create sequence employer_id_seq]]></programlisting> + + </sect1> + + <sect1 id="example-mappings-authorwork"> + <title>Author/Work</title> + + <para> + <literal>Work</literal>, <literal>Author</literal> 그리고 <literal>Person</literal> 사이의 관계들에 대한 + 다음 모형을 검토하자. 우리는 <literal>Work</literal>과 <literal>Author</literal> 사이의 관계를 many-to-many + 연관으로 표현한다. 우리는 <literal>Author</literal>와 <literal>Person</literal> 사이의 관계를 one-to-one + 연관으로 표현하고자 선택한다. 또 다른 가능성은 <literal>Author</literal>가 <literal>Person</literal>을 확장하도록 + 하는 것일 것이다. + </para> + + <mediaobject> + <imageobject role="fo"> + <imagedata fileref="../images/AuthorWork.png" format="PNG" align="center"/> + </imageobject> + <imageobject role="html"> + <imagedata fileref="../images/AuthorWork.png" format="PNG" align="center"/> + </imageobject> + </mediaobject> + + <para> + 다음 매핑 문서는 이들 관계들을 정확하게 표현한다: + </para> + + <programlisting><![CDATA[<hibernate-mapping> + + <class name="Work" table="works" discriminator-value="W"> + + <id name="id" column="id"> + <generator class="native"/> + </id> + <discriminator column="type" type="character"/> + + <property name="title"/> + <set name="authors" table="author_work"> + <key column name="work_id"/> + <many-to-many class="Author" column name="author_id"/> + </set> + + <subclass name="Book" discriminator-value="B"> + <property name="text"/> + </subclass> + + <subclass name="Song" discriminator-value="S"> + <property name="tempo"/> + <property name="genre"/> + </subclass> + + </class> + + <class name="Author" table="authors"> + + <id name="id" column="id"> + <!-- The Author must have the same identifier as the Person --> + <generator class="assigned"/> + </id> + + <property name="alias"/> + <one-to-one name="person" constrained="true"/> + + <set name="works" table="author_work" inverse="true"> + <key column="author_id"/> + <many-to-many class="Work" column="work_id"/> + </set> + + </class> + + <class name="Person" table="persons"> + <id name="id" column="id"> + <generator class="native"/> + </id> + <property name="name"/> + </class> + +</hibernate-mapping>]]></programlisting> + + <para> + 이 매핑에는 네 개의 테이블들이 존재한다. <literal>works</literal>, <literal>authors</literal>와 + <literal>persons</literal>은 각각 작업 데이터, 저자 데이터, 개인 데이터를 보관한다. <literal>author_work</literal>는 + 저자들을 작업들에 연결시키는 연관 테이블이다. 다음은 <literal>SchemaExport</literal>에 의해 생성된 테이블 + 스키마이다. + </para> + + <programlisting><![CDATA[create table works ( + id BIGINT not null generated by default as identity, + tempo FLOAT, + genre VARCHAR(255), + text INTEGER, + title VARCHAR(255), + type CHAR(1) not null, + primary key (id) +) + +create table author_work ( + author_id BIGINT not null, + work_id BIGINT not null, + primary key (work_id, author_id) +) + +create table authors ( + id BIGINT not null generated by default as identity, + alias VARCHAR(255), + primary key (id) +) + +create table persons ( + id BIGINT not null generated by default as identity, + name VARCHAR(255), + primary key (id) +) + +alter table authors + add constraint authorsFK0 foreign key (id) references persons +alter table author_work + add constraint author_workFK0 foreign key (author_id) references authors +alter table author_work + add constraint author_workFK1 foreign key (work_id) references works]]></programlisting> + + </sect1> + + <sect1 id="example-mappings-customerorderproduct"> + <title>Customer/Order/Product</title> + + <para> + 이제 <literal>Customer</literal>, <literal>Order</literal>와 <literal>LineItem</literal> + 그리고 <literal>Product</literal> 사이의 관계들에 관한 모형을 검토하자. <literal>Customer</literal>와 + <literal>Order</literal> 사이의 one-to-many 연관이 존재하지만, 우리는 어떻게 + <literal>Order</literal> / <literal>LineItem</literal> / <literal>Product</literal>를 + 표현할 것인가? 나는 <literal>Order</literal>와 <literal>Product</literal> 사이의 many-to-many + 연관를 나타내는 하나의 연관 클래스로서 <literal>LineItem</literal>을 매핑하기로 선택했다. Hibernate에서 + 이것은 composite 요소로 명명된다. + </para> + + <mediaobject> + <imageobject role="fo"> + <imagedata fileref="../images/CustomerOrderProduct.png" format="PNG" align="center"/> + </imageobject> + <imageobject role="html"> + <imagedata fileref="../images/CustomerOrderProduct.png" format="PNG" align="center"/> + </imageobject> + </mediaobject> + + <para> + 매핑 문서: + </para> + + <programlisting><![CDATA[<hibernate-mapping> + + <class name="Customer" table="customers"> + <id name="id"> + <generator class="native"/> + </id> + <property name="name"/> + <set name="orders" inverse="true"> + <key column="customer_id"/> + <one-to-many class="Order"/> + </set> + </class> + + <class name="Order" table="orders"> + <id name="id"> + <generator class="native"/> + </id> + <property name="date"/> + <many-to-one name="customer" column="customer_id"/> + <list name="lineItems" table="line_items"> + <key column="order_id"/> + <list-index column="line_number"/> + <composite-element class="LineItem"> + <property name="quantity"/> + <many-to-one name="product" column="product_id"/> + </composite-element> + </list> + </class> + + <class name="Product" table="products"> + <id name="id"> + <generator class="native"/> + </id> + <property name="serialNumber"/> + </class> + +</hibernate-mapping>]]></programlisting> + + <para> + <literal>customers</literal>, <literal>orders</literal>, <literal>line_items</literal> 그리고 + <literal>products</literal>는 각각 고객 데이터, 주문 데이터, 주문 라인 아이템 데이터, 그리고 제품 데이터를 + 보관한다. <literal>line_items</literal>는 또한 주문들을 제품들과 연결시키는 연관 테이블로서 동작한다. + </para> + + <programlisting><![CDATA[create table customers ( + id BIGINT not null generated by default as identity, + name VARCHAR(255), + primary key (id) +) + +create table orders ( + id BIGINT not null generated by default as identity, + customer_id BIGINT, + date TIMESTAMP, + primary key (id) +) + +create table line_items ( + line_number INTEGER not null, + order_id BIGINT not null, + product_id BIGINT, + quantity INTEGER, + primary key (order_id, line_number) +) + +create table products ( + id BIGINT not null generated by default as identity, + serialNumber VARCHAR(255), + primary key (id) +) + +alter table orders + add constraint ordersFK0 foreign key (customer_id) references customers +alter table line_items + add constraint line_itemsFK0 foreign key (product_id) references products +alter table line_items + add constraint line_itemsFK1 foreign key (order_id) references orders]]></programlisting> + + </sect1> + + <sect1 id="misc"> + <title>기타 예제 매핑들</title> + + <para> + 이들 예제들은 모두 Hiberante test suite로부터 취했다. 당신은 거기서 많은 + 다른 유용한 예제 매핑들을 발견할 것이다. Hibernate 배포본의 <literal>test</literal> + 폴더를 살펴보라. + </para> + + <para>TODO: 이 내용을 둘러싼 말들을 집어넣을 것.</para> + + <sect2 id="example-mappings-typed-onetone"> + <title>"형식화된(Typed)" one-to-one 연관</title> +<programlisting><![CDATA[<class name="Person"> + <id name="name"/> + <one-to-one name="address" + cascade="all"> + <formula>name</formula> + <formula>'HOME'</formula> + </one-to-one> + <one-to-one name="mailingAddress" + cascade="all"> + <formula>name</formula> + <formula>'MAILING'</formula> + </one-to-one> +</class> + +<class name="Address" batch-size="2" + check="addressType in ('MAILING', 'HOME', 'BUSINESS')"> + <composite-id> + <key-many-to-one name="person" + column="personName"/> + <key-property name="type" + column="addressType"/> + </composite-id> + <property name="street" type="text"/> + <property name="state"/> + <property name="zip"/> +</class>]]></programlisting> + </sect2> + + <sect2 id="example-mappings-composite-key"> + <title>Composite 키 예제</title> +<programlisting><![CDATA[<class name="Customer"> + + <id name="customerId" + length="10"> + <generator class="assigned"/> + </id> + + <property name="name" not-null="true" length="100"/> + <property name="address" not-null="true" length="200"/> + + <list name="orders" + inverse="true" + cascade="save-update"> + <key column="customerId"/> + <index column="orderNumber"/> + <one-to-many class="Order"/> + </list> + +</class> + +<class name="Order" table="CustomerOrder" lazy="true"> + <synchronize table="LineItem"/> + <synchronize table="Product"/> + + <composite-id name="id" + class="Order$Id"> + <key-property name="customerId" length="10"/> + <key-property name="orderNumber"/> + </composite-id> + + <property name="orderDate" + type="calendar_date" + not-null="true"/> + + <property name="total"> + <formula> + ( select sum(li.quantity*p.price) + from LineItem li, Product p + where li.productId = p.productId + and li.customerId = customerId + and li.orderNumber = orderNumber ) + </formula> + </property> + + <many-to-one name="customer" + column="customerId" + insert="false" + update="false" + not-null="true"/> + + <bag name="lineItems" + fetch="join" + inverse="true" + cascade="save-update"> + <key> + <column name="customerId"/> + <column name="orderNumber"/> + </key> + <one-to-many class="LineItem"/> + </bag> + +</class> + +<class name="LineItem"> + + <composite-id name="id" + class="LineItem$Id"> + <key-property name="customerId" length="10"/> + <key-property name="orderNumber"/> + <key-property name="productId" length="10"/> + </composite-id> + + <property name="quantity"/> + + <many-to-one name="order" + insert="false" + update="false" + not-null="true"> + <column name="customerId"/> + <column name="orderNumber"/> + </many-to-one> + + <many-to-one name="product" + insert="false" + update="false" + not-null="true" + column="productId"/> + +</class> + +<class name="Product"> + <synchronize table="LineItem"/> + + <id name="productId" + length="10"> + <generator class="assigned"/> + </id> + + <property name="description" + not-null="true" + length="200"/> + <property name="price" length="3"/> + <property name="numberAvailable"/> + + <property name="numberOrdered"> + <formula> + ( select sum(li.quantity) + from LineItem li + where li.productId = productId ) + </formula> + </property> + +</class>]]></programlisting> + </sect2> + + <sect2 id="example-mappings-composite-key-manytomany"> + <title>공유된 합성 키 속성을 가진 Many-to-many</title> +<programlisting><![CDATA[<class name="User" table="`User`"> + <composite-id> + <key-property name="name"/> + <key-property name="org"/> + </composite-id> + <set name="groups" table="UserGroup"> + <key> + <column name="userName"/> + <column name="org"/> + </key> + <many-to-many class="Group"> + <column name="groupName"/> + <formula>org</formula> + </many-to-many> + </set> +</class> + +<class name="Group" table="`Group`"> + <composite-id> + <key-property name="name"/> + <key-property name="org"/> + </composite-id> + <property name="description"/> + <set name="users" table="UserGroup" inverse="true"> + <key> + <column name="groupName"/> + <column name="org"/> + </key> + <many-to-many class="User"> + <column name="userName"/> + <formula>org</formula> + </many-to-many> + </set> +</class> +]]></programlisting> + </sect2> + + <sect2 id="example-mappings-content-discrimination"> + <title>내용 기반 판별</title> +<programlisting><![CDATA[<class name="Person" + discriminator-value="P"> + + <id name="id" + column="person_id" + unsaved-value="0"> + <generator class="native"/> + </id> + + + <discriminator + type="character"> + <formula> + case + when title is not null then 'E' + when salesperson is not null then 'C' + else 'P' + end + </formula> + </discriminator> + + <property name="name" + not-null="true" + length="80"/> + + <property name="sex" + not-null="true" + update="false"/> + + <component name="address"> + <property name="address"/> + <property name="zip"/> + <property name="country"/> + </component> + + <subclass name="Employee" + discriminator-value="E"> + <property name="title" + length="20"/> + <property name="salary"/> + <many-to-one name="manager"/> + </subclass> + + <subclass name="Customer" + discriminator-value="C"> + <property name="comments"/> + <many-to-one name="salesperson"/> + </subclass> + +</class>]]></programlisting> + </sect2> + + <sect2 id="example-mappings-association-alternatekeys" revision="2"> + <title>대체 키들에 대한 연관들</title> +<programlisting><![CDATA[<class name="Person"> + + <id name="id"> + <generator class="hilo"/> + </id> + + <property name="name" length="100"/> + + <one-to-one name="address" + property-ref="person" + cascade="all" + fetch="join"/> + + <set name="accounts" + inverse="true"> + <key column="userId" + property-ref="userId"/> + <one-to-many class="Account"/> + </set> + + <property name="userId" length="8"/> + +</class> + +<class name="Address"> + + <id name="id"> + <generator class="hilo"/> + </id> + + <property name="address" length="300"/> + <property name="zip" length="5"/> + <property name="country" length="25"/> + <many-to-one name="person" unique="true" not-null="true"/> + +</class> + +<class name="Account"> + <id name="accountId" length="32"> + <generator class="uuid"/> + </id> + + <many-to-one name="user" + column="userId" + property-ref="userId"/> + + <property name="type" not-null="true"/> + +</class>]]></programlisting> + </sect2> + + </sect1> + +</chapter> + Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/example_parentchild.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/example_parentchild.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/example_parentchild.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/example_parentchild.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,343 @@ +<chapter id="example-parentchild"> + <title>예제: 부모/자식</title> + + <para> + 새로운 사용자들이 Hibernate로 행하고자 시도하는 바로 첫 번째 것들 중 하나는 부모/자식 타입의 관계를 모형화 시키는 것이다. 이것에 대한 + 두 가지 다른 접근법들이 존재한다. 여러가지 이유들로 인해 특히 새로운 사용자들에게 가장 편한 접근법은 <literal>Parent</literal>로부터 + <literal>Child</literal>로의 <literal>&lt;one-to-many&gt;</literal> 연관을 가진 엔티티 클래스들로서 <literal>Parent</literal>와 + <literal>Child</literal> 양자를 모형화 시키는 것이다. (다른 접근법은 <literal>Child</literal>를 + <literal>&lt;composite-element&gt;</literal>로 선언하는 것이다.) 이제, (Hibernate에서) one to many 연관에 대한 디폴트 + 의미는 composite 요소 매핑의 의미보다 부모/자식 관계의 통상적인 의미에 훨씬 덜 가깝다는 것이 판명된다. 우리는 부모/자식 관계를 효율적이고 + 강력하게 모형화 시키기 위해 <emphasis>케스케이드들을 가진 양방향 one to many 연관</emphasis>을 사용하는 방법을 설명할 것이다. + 그것은 전혀 어렵지 않다! + </para> + + <sect1 id="example-parentchild-collections"> + <title>콜렉션들에 관한 노트</title> + + <para> + Hibernate 콜렉션들은 그것들의 소유하고 있는 엔티티의 논리적 부분으로 간주된다; 결코 포함된 엔티티들의 부분이 아니다. 이것은 + 중대한 구분점이다! 그것은 다음은 다음 결과들을 갖는다: + </para> + + <itemizedlist> + <listitem> + <para> + 콜렉션으로부터 객체를 제거하고/콜렉션에 객체를 추가 시킬 때, 콜렉션 소유자의 버전 번호가 증가된다. + </para> + </listitem> + <listitem> + <para> + 만일 콜렉션으로부터 제거되었던 객체가 하나의 값 타입의 인스턴스(예를 들어 composite 요소)이면, 그 객체는 영속상태를 끝내고 + 그것의 상태가 데이터베이스로부터 완전히 제거될 것이다. 마찬가지로 하나의 값 타입의 인스턴스를 콜렉션에 추가시키는 것은 그것의 + 상태가 즉시 영속화 되도록 강제시킬 것이다. + </para> + </listitem> + <listitem> + <para> + 반면에, 만일 엔티티가 콜렉션으로부터 제거될 경우(one-to-many 또는 many-to-many 연관), 그것은 디폴트로 삭제되지 않을 + 것이다. 이 특징은 완전하게 일관적이다 - 다른 엔티티의 내부 상태에 대한 변경은 연관된 엔티티를 사라지도록 강제하지 않을 것이다! + 마찬가지로 콜렉션에 엔티티를 추가시키는 것은 디폴트로 그 엔티티가 영속화 되도록 강제시키지 않는다. + </para> + </listitem> + </itemizedlist> + + <para> + 대신에 콜렉션으로의 엔티티 추가가 두 엔티티들 사이에 단지 하나의 링크를 생성시키는 반면에, 그것을 제거하는 것은 링크를 제거한다는 점이 + 디폴트 특징이다. 이것은 모든 종류의 경우들에 대해 매우 적절하다. 그것이 전혀 적절하지 않은 곳은 부모/자식 관계인 경우이고, 여기서 + 자식의 생애는 부모의 생명주기에 묶여져 있다. + </para> + + </sect1> + + <sect1 id="example-parentchild-bidir"> + <title>양방향 one-to-many</title> + + <para> + <literal>Parent</literal>로부터 <literal>Child</literal>로의 간단한 <literal>&lt;one-to-many&gt;</literal> + 연관관계로 시작한다고 가정하자. + </para> + + <programlisting><![CDATA[<set name="children"> + <key column="parent_id"/> + <one-to-many class="Child"/> +</set>]]></programlisting> + + <para> + 우리가 다음 코드를 실행시켰다면 + </para> + + <programlisting><![CDATA[Parent p = .....; +Child c = new Child(); +p.getChildren().add(c); +session.save(c); +session.flush();]]></programlisting> + + <para> + Hibernate는 두 개의 SQL 문장들을 실행할 것이다: + </para> + + <itemizedlist> + <listitem> + <para><literal>c</literal>에 대한 레코드를 생성시키는 <literal>INSERT</literal></para> + </listitem> + <listitem> + <para><literal>p</literal>로부터 <literal>c</literal>로의 링크를 생성시키는 <literal>UPDATE</literal></para> + </listitem> + </itemizedlist> + + <para> + 이것은 비효율적일 뿐만 아니라, 또한 <literal>parent_id</literal> 컬럼 상의 임의의 <literal>NOT NULL</literal> + 컨스트레인트에 위배된다. 우리는 콜렉션 매핑에서 <literal>not-null="true"</literal>를 지정함으로써 null 허용 가능 + 컨스트레인트 위반을 정정할 수 있다: + </para> + + <programlisting><![CDATA[<set name="children"> + <key column="parent_id" not-null="true"/> + <one-to-many class="Child"/> +</set>]]></programlisting> + + <para> + 하지만 이것은 권장되는 해결책이 아니다. + </para> + <para> + 이 행위의 기본 원인은 <literal>p</literal>로부터 <literal>c</literal>로의 링크(foreign key <literal>parent_id</literal>)가 + <literal>Child</literal> 객체의 상태의 부분으로 간주되지 않고 그러므로 <literal>INSERT</literal>로 생성되지 않는다는 + 점이다. 따라서 해결책은 <literal>Child</literal> 매핑의 링크 부분을 만드는 것이다. + </para> + + <programlisting><![CDATA[<many-to-one name="parent" column="parent_id" not-null="true"/>]]></programlisting> + + <para> + (우리는 또한 <literal>parent</literal> 프로퍼티를 <literal>Child</literal> 클래스에 추가시킬 필요가 있다.) + </para> + + <para> + 이제 <literal>Child</literal> 엔티티가 링크의 상태를 관리한다는 점을 노트하고, 우리는 링크를 업데이트 시키지 말도록 콜렉션에게 + 통보한다. 우리는 <literal>inverse</literal> 속성을 사용한다. + </para> + + <programlisting><![CDATA[<set name="children" inverse="true"> + <key column="parent_id"/> + <one-to-many class="Child"/> +</set>]]></programlisting> + + <para> + 다음 코드는 새로운 <literal>Child</literal>를 추가시키는데 사용될 것이다 + </para> + + <programlisting><![CDATA[Parent p = (Parent) session.load(Parent.class, pid); +Child c = new Child(); +c.setParent(p); +p.getChildren().add(c); +session.save(c); +session.flush();]]></programlisting> + + <para> + 그리고 이제, 유일하게 한 개의 SQL <literal>INSERT</literal>가 실행될 것이다! + </para> + + <para> + 약간 거칠게, 우리는 <literal>Parent</literal>의 <literal>addChild()</literal> 메소드를 생성시킬 수 있다. + </para> + + <programlisting><![CDATA[public void addChild(Child c) { + c.setParent(this); + children.add(c); +}]]></programlisting> + + <para> + 이제, <literal>Child</literal>를 추가하는 코드는 다음과 같다 + </para> + + <programlisting><![CDATA[Parent p = (Parent) session.load(Parent.class, pid); +Child c = new Child(); +p.addChild(c); +session.save(c); +session.flush();]]></programlisting> + + </sect1> + + <sect1 id="example-parentchild-cascades"> + <title>케스케이딩 생명주기</title> + + <para> + <literal>save()</literal>에 대한 명시적인 호출은 여전히 성가시다. 우리는 케스케이딩을 사용하여 이것을 얘기할 것이다. + </para> + + <programlisting><![CDATA[<set name="children" inverse="true" cascade="all"> + <key column="parent_id"/> + <one-to-many class="Child"/> +</set>]]></programlisting> + + <para> + 다음은 위의 코드를 단순화 시킨다 + </para> + + <programlisting><![CDATA[Parent p = (Parent) session.load(Parent.class, pid); +Child c = new Child(); +p.addChild(c); +session.flush();]]></programlisting> + + <para> + 유사하게, 우리는 <literal>Parent</literal>를 저장하거나 삭제할 때 자식들에 대해 반복하는 것을 필요로 하지 않는다. 다음은 + 데이터베이스로부터 <literal>p</literal>와 모든 그것의 자식들을 제거시킨다. + </para> + + <programlisting><![CDATA[Parent p = (Parent) session.load(Parent.class, pid); +session.delete(p); +session.flush();]]></programlisting> + + <para> + 하지만, 다음 코드 + </para> + + <programlisting><![CDATA[Parent p = (Parent) session.load(Parent.class, pid); +Child c = (Child) p.getChildren().iterator().next(); +p.getChildren().remove(c); +c.setParent(null); +session.flush();]]></programlisting> + + <para> + 는 데이터베이스로부터 <literal>c</literal>를 제거하지 않을 것이다; 그것은 오직 <literal>p</literal>에 대한 링크만을 제거할 + 것이다(그리고 이 경우에 <literal>NOT NULL</literal> 컨스트레인트 위반을 일으킬 것이다 ). 당신은 명시적으로 + <literal>Child</literal>를 <literal>delete()</literal> 시킬 필요가 있다. + </para> + + <programlisting><![CDATA[Parent p = (Parent) session.load(Parent.class, pid); +Child c = (Child) p.getChildren().iterator().next(); +p.getChildren().remove(c); +session.delete(c); +session.flush();]]></programlisting> + + <para> + 이제 우리의 경우에 <literal>Child</literal>는 그것의 부모 없이는 진정으로 존재할 수 없다. 따라서 만일 우리가 콜렉션으로부터 + 하나의 <literal>Child</literal>를 제거할 경우, 우리는 그것이 정말로 삭제되기를 원한다. 이를 위해 우리는 + <literal>cascade="all-delete-orphan"</literal>을 사용해야 한다. + </para> + + <programlisting><![CDATA[<set name="children" inverse="true" cascade="all-delete-orphan"> + <key column="parent_id"/> + <one-to-many class="Child"/> +</set>]]></programlisting> + + <para> + 노트: 비록 콜렉션 매핑이 <literal>inverse="true"</literal>를 지정할 지라도, 케스케이드들은 여전히 콜렉션 요소들을 + 반복함으로써 처리된다. 따라서 객체가 케스케이드에 의해 저장되고, 삭제되거나 업데이트 되는 것을 당신이 필요로 할 경우, 당신은 + 그것을 그 콜렉션에 추가해야 한다. 단순히 <literal>setParent()</literal>를 호출하는 것으로는 충분하지 않다. + </para> + + </sect1> + + <sect1 id="example-parentchild-update"> + <title>케스케이드들과 <literal>unsaved-value</literal></title> + + <para> + 우리가 하나의 <literal>Session</literal> 속에 <literal>Parent</literal>를 로드시켰고 UI 액션에서 어떤 변경들을 행했고, + <literal>update()</literal>를 호출하여 새로운 세션에서 이들 변경들을 영속화 시키는 것을 원한다고 가정하자. <literal>Parent</literal>는 + 자식들을 가진 콜렉션을 포함할 것이고, 케스케이딩 업데이트가 사용 가능하기 때문에, Hibernate는 어느 자식들이 새로이 초기화 되는지 + 그리고 어느 것이 데이터베이스에서 현재 행들을 표현하는지를 알 필요가 있다. <literal>Parent</literal>와 <literal>Child</literal> + 모두 <literal>Long</literal> 타입의 식별자 프로퍼티들을 생성시켰다고 가정하자. Hibernate는 어느 자식들이 새로운 것인지를 + 결정하는데 식별자와 version/timestamp 프로퍼티 값을 사용할 것이다.(<xref linkend="objectstate-saveorupdate"/>을 보라.) + <emphasis>Hibernate3에서는<literal>unsaved-value</literal>를 더이상 명시적으로 지정할 필요가 없다.</emphasis> + </para> + + <para> + 다음 코드는 <literal>parent</literal>와 <literal>child</literal>를 업데이트하고 <literal>newChild</literal>를 + 삽입시킬 것이다. + </para> + + <programlisting><![CDATA[//parent and child were both loaded in a previous session +parent.addChild(child); +Child newChild = new Child(); +parent.addChild(newChild); +session.update(parent); +session.flush();]]></programlisting> + + <para> + 물론 그것은 생성되는 식별자의 경우에는 모두 매우 좋지만, 할당되는 식별자들과 composite 식별자들에 대해서는 어떠한가? 이것은 보다 + 어렵다. 왜냐하면 Hibernate는 (사용자에 의해 할당된 식별자를 가진) 새로이 초기화 된 객체와 이전 세션에서 로드되었던 객체 사이를 + 구별짓는데 식별자 프로퍼티를 사용할 수 없기 때문이다. 이 경우에, Hibernate는 timestamp 프로퍼티 또는 version 프로퍼티를 + 사용하거나 실제로 second-level 캐시를 질의하거나 가장 나쁜 경우에는 행이 존재하는지를 알기 위해 데이터베이스를 질의할 것이다. + </para> + + <!-- undocumenting + <para> + There is one further possibility. The <literal>Interceptor</literal> method named + <literal>isUnsaved()</literal> lets the application implement its own strategy for distinguishing + newly instantiated objects. For example, you could define a base class for your persistent classes. + </para> + + <programlisting><![CDATA[public class Persistent { + private boolean _saved = false; + public void onSave() { + _saved=true; + } + public void onLoad() { + _saved=true; + } + ...... + public boolean isSaved() { + return _saved; + } +}]]></programlisting> + + <para> + (The <literal>saved</literal> property is non-persistent.) + Now implement <literal>isUnsaved()</literal>, along with <literal>onLoad()</literal> + and <literal>onSave()</literal> as follows. + </para> + + <programlisting><![CDATA[public Boolean isUnsaved(Object entity) { + if (entity instanceof Persistent) { + return new Boolean( !( (Persistent) entity ).isSaved() ); + } + else { + return null; + } +} + +public boolean onLoad(Object entity, + Serializable id, + Object[] state, + String[] propertyNames, + Type[] types) { + + if (entity instanceof Persistent) ( (Persistent) entity ).onLoad(); + return false; +} + +public boolean onSave(Object entity, + Serializable id, + Object[] state, + String[] propertyNames, + Type[] types) { + + if (entity instanceof Persistent) ( (Persistent) entity ).onSave(); + return false; +}]]></programlisting> + + <para> + Don't worry; in Hibernate3 you don't need to write any of this kind of code if you don't want to. + </para> + --> + </sect1> + + <sect1 id="example-parentchild-conclusion"> + <title>결론</title> + + <para> + 여기에 숙지할 것이 약간 있고 그것은 처음에는 혼동스러운 것처럼 보일 수 있다. 하지만 실제로 그것은 모두 매우 좋게 동작한다. 대부분의 + Hibernate 어플리케이션들은 많은 장소들에서 부모/자식 패턴을 사용한다. + </para> + + <para> + 우리는 첫 번째 단락에서 대안을 언급했다. 위의 쟁점들 중 어느 것도 정확하게 부모/자식 관계의 의미를 가진, + <literal>&lt;composite-element&gt;</literal> 매핑들의 경우에는 존재하지 않는다. 불행히도, composite 요소 클래스들에 + 대한 두 개의 커다란 제약들이 존재한다: composite 요소들은 콜렉션들을 소유하지 않고, 그것들은 유일한 부모가 아닌 다른 어떤 + 엔티티의 자식일 수는 없다. + </para> + + </sect1> + +</chapter> \ No newline at end of file Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/example_weblog.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/example_weblog.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/example_weblog.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/example_weblog.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,428 @@ +<chapter id="example-weblog"> + <title>예제: Weblog 어플리케이션</title> + + <sect1 id="example-weblog-classes"> + <title>영속 클래스들</title> + + <para> + 영속 클래스들은 웹로그, 그리고 웹 로그 내에 게시된 항목을 표현한다.그것들은 + 표준 부모/자식 관계로 모형화 될 것이지만, 우리는 set 대신에 순서지워진 bag를 사용할 것이다. + </para> + + <programlisting><![CDATA[package eg; + +import java.util.List; + +public class Blog { + private Long _id; + private String _name; + private List _items; + + public Long getId() { + return _id; + } + public List getItems() { + return _items; + } + public String getName() { + return _name; + } + public void setId(Long long1) { + _id = long1; + } + public void setItems(List list) { + _items = list; + } + public void setName(String string) { + _name = string; + } +}]]></programlisting> + + <programlisting><![CDATA[package eg; + +import java.text.DateFormat; +import java.util.Calendar; + +public class BlogItem { + private Long _id; + private Calendar _datetime; + private String _text; + private String _title; + private Blog _blog; + + public Blog getBlog() { + return _blog; + } + public Calendar getDatetime() { + return _datetime; + } + public Long getId() { + return _id; + } + public String getText() { + return _text; + } + public String getTitle() { + return _title; + } + public void setBlog(Blog blog) { + _blog = blog; + } + public void setDatetime(Calendar calendar) { + _datetime = calendar; + } + public void setId(Long long1) { + _id = long1; + } + public void setText(String string) { + _text = string; + } + public void setTitle(String string) { + _title = string; + } +}]]></programlisting> + + </sect1> + + <sect1 id="example-weblog-mappings"> + <title>Hibernate 매핑들</title> + + <para> + XML 매핑들은 이제 매우 간단해질 것이다. + </para> + + <programlisting><![CDATA[<?xml version="1.0"?> +<!DOCTYPE hibernate-mapping PUBLIC + "-//Hibernate/Hibernate Mapping DTD 3.0//EN" + "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> + +<hibernate-mapping package="eg"> + + <class + name="Blog" + table="BLOGS"> + + <id + name="id" + column="BLOG_ID"> + + <generator class="native"/> + + </id> + + <property + name="name" + column="NAME" + not-null="true" + unique="true"/> + + <bag + name="items" + inverse="true" + order-by="DATE_TIME" + cascade="all"> + + <key column="BLOG_ID"/> + <one-to-many class="BlogItem"/> + + </bag> + + </class> + +</hibernate-mapping>]]></programlisting> + + <programlisting><![CDATA[<?xml version="1.0"?> +<!DOCTYPE hibernate-mapping PUBLIC + "-//Hibernate/Hibernate Mapping DTD 3.0//EN" + "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> + +<hibernate-mapping package="eg"> + + <class + name="BlogItem" + table="BLOG_ITEMS" + dynamic-update="true"> + + <id + name="id" + column="BLOG_ITEM_ID"> + + <generator class="native"/> + + </id> + + <property + name="title" + column="TITLE" + not-null="true"/> + + <property + name="text" + column="TEXT" + not-null="true"/> + + <property + name="datetime" + column="DATE_TIME" + not-null="true"/> + + <many-to-one + name="blog" + column="BLOG_ID" + not-null="true"/> + + </class> + +</hibernate-mapping>]]></programlisting> + + </sect1> + + <sect1 id="example-weblog-code"> + <title>Hibernate 코드</title> + + <para> + 다음 클래스는 우리가 Hibernate를 사용하여 이들 클래스들로 행할 수 있는 몇몇 종류의 것들을 설명한다. + </para> + + <programlisting><![CDATA[package eg; + +import java.util.ArrayList; +import java.util.Calendar; +import java.util.Iterator; +import java.util.List; + +import org.hibernate.HibernateException; +import org.hibernate.Query; +import org.hibernate.Session; +import org.hibernate.SessionFactory; +import org.hibernate.Transaction; +import org.hibernate.cfg.Configuration; +import org.hibernate.tool.hbm2ddl.SchemaExport; + +public class BlogMain { + + private SessionFactory _sessions; + + public void configure() throws HibernateException { + _sessions = new Configuration() + .addClass(Blog.class) + .addClass(BlogItem.class) + .buildSessionFactory(); + } + + public void exportTables() throws HibernateException { + Configuration cfg = new Configuration() + .addClass(Blog.class) + .addClass(BlogItem.class); + new SchemaExport(cfg).create(true, true); + } + + public Blog createBlog(String name) throws HibernateException { + + Blog blog = new Blog(); + blog.setName(name); + blog.setItems( new ArrayList() ); + + Session session = _sessions.openSession(); + Transaction tx = null; + try { + tx = session.beginTransaction(); + session.persist(blog); + tx.commit(); + } + catch (HibernateException he) { + if (tx!=null) tx.rollback(); + throw he; + } + finally { + session.close(); + } + return blog; + } + + public BlogItem createBlogItem(Blog blog, String title, String text) + throws HibernateException { + + BlogItem item = new BlogItem(); + item.setTitle(title); + item.setText(text); + item.setBlog(blog); + item.setDatetime( Calendar.getInstance() ); + blog.getItems().add(item); + + Session session = _sessions.openSession(); + Transaction tx = null; + try { + tx = session.beginTransaction(); + session.update(blog); + tx.commit(); + } + catch (HibernateException he) { + if (tx!=null) tx.rollback(); + throw he; + } + finally { + session.close(); + } + return item; + } + + public BlogItem createBlogItem(Long blogid, String title, String text) + throws HibernateException { + + BlogItem item = new BlogItem(); + item.setTitle(title); + item.setText(text); + item.setDatetime( Calendar.getInstance() ); + + Session session = _sessions.openSession(); + Transaction tx = null; + try { + tx = session.beginTransaction(); + Blog blog = (Blog) session.load(Blog.class, blogid); + item.setBlog(blog); + blog.getItems().add(item); + tx.commit(); + } + catch (HibernateException he) { + if (tx!=null) tx.rollback(); + throw he; + } + finally { + session.close(); + } + return item; + } + + public void updateBlogItem(BlogItem item, String text) + throws HibernateException { + + item.setText(text); + + Session session = _sessions.openSession(); + Transaction tx = null; + try { + tx = session.beginTransaction(); + session.update(item); + tx.commit(); + } + catch (HibernateException he) { + if (tx!=null) tx.rollback(); + throw he; + } + finally { + session.close(); + } + } + + public void updateBlogItem(Long itemid, String text) + throws HibernateException { + + Session session = _sessions.openSession(); + Transaction tx = null; + try { + tx = session.beginTransaction(); + BlogItem item = (BlogItem) session.load(BlogItem.class, itemid); + item.setText(text); + tx.commit(); + } + catch (HibernateException he) { + if (tx!=null) tx.rollback(); + throw he; + } + finally { + session.close(); + } + } + + public List listAllBlogNamesAndItemCounts(int max) + throws HibernateException { + + Session session = _sessions.openSession(); + Transaction tx = null; + List result = null; + try { + tx = session.beginTransaction(); + Query q = session.createQuery( + "select blog.id, blog.name, count(blogItem) " + + "from Blog as blog " + + "left outer join blog.items as blogItem " + + "group by blog.name, blog.id " + + "order by max(blogItem.datetime)" + ); + q.setMaxResults(max); + result = q.list(); + tx.commit(); + } + catch (HibernateException he) { + if (tx!=null) tx.rollback(); + throw he; + } + finally { + session.close(); + } + return result; + } + + public Blog getBlogAndAllItems(Long blogid) + throws HibernateException { + + Session session = _sessions.openSession(); + Transaction tx = null; + Blog blog = null; + try { + tx = session.beginTransaction(); + Query q = session.createQuery( + "from Blog as blog " + + "left outer join fetch blog.items " + + "where blog.id = :blogid" + ); + q.setParameter("blogid", blogid); + blog = (Blog) q.uniqueResult(); + tx.commit(); + } + catch (HibernateException he) { + if (tx!=null) tx.rollback(); + throw he; + } + finally { + session.close(); + } + return blog; + } + + public List listBlogsAndRecentItems() throws HibernateException { + + Session session = _sessions.openSession(); + Transaction tx = null; + List result = null; + try { + tx = session.beginTransaction(); + Query q = session.createQuery( + "from Blog as blog " + + "inner join blog.items as blogItem " + + "where blogItem.datetime > :minDate" + ); + + Calendar cal = Calendar.getInstance(); + cal.roll(Calendar.MONTH, false); + q.setCalendar("minDate", cal); + + result = q.list(); + tx.commit(); + } + catch (HibernateException he) { + if (tx!=null) tx.rollback(); + throw he; + } + finally { + session.close(); + } + return result; + } +}]]></programlisting> + + </sect1> + +</chapter> + Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/filters.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/filters.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/filters.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/filters.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,138 @@ +<chapter id="filters"> + <title>데이터 필터링하기</title> + + <para> + Hibernate3은 혁신적인 "가시성(visibility)" 규칙들로서 데이터를 처리하는 새로운 접근법을 제공한다. <emphasis>Hibernate + 필터</emphasis>는 특정 Hibernate 세션에 대해 이용 가능하게 되거나 이용 불가능하게 될 수도 있는 전역, 명명된 파라미터화 된 필터이다. + </para> + + <sect1 id="objectstate-filters" revision="1"> + <title>Hibernate 필터들</title> + + <para> + Hibernate3은 필터 기준(criteria)을 미리 정의하고 클래스 레벨과 콜렉션 레벨 양자에서 그들 필터들을 첨부할 능력을 추가시킨다. + 필터 기준(criteria)은 클래스 요소와 다양한 콜렉션 요소들에 대해 이용 가능한 기존의 "where" 속성과 매우 유사한 하나의 제한 절을 + 정의하는 능력이다. 이것들을 제외하면 필터 조건들은 파라미터화 될 수 있다. 그때 어플리케이션은 주어진 필터들이 이용 가능한지 여부 + 그리고 그들 파라미터 값들이 무엇이어야 하는지를 실행 시에 결정할 수 있다. 필터들은 데이터베이스 뷰들 처럼 사용될 수 있지만, + 어플리케이션 내부에 파라미터화 된다. + </para> + + <para> + 필터들을 사용하기 위해서, 그것들은 먼저 정의되고 나서 적절한 매핑 요소들에 첨가되어야 한다. 필터를 정의하기 위해, + <literal>&lt;hibernate-mapping/&gt;</literal> 요소 내부에 <literal>&lt;filter-def/&gt;</literal> 요소를 + 사용하라: + </para> + + <programlisting><![CDATA[<filter-def name="myFilter"> + <filter-param name="myFilterParam" type="string"/> +</filter-def>]]></programlisting> + + <para> + 그때 이 필터는 클래스에 첨가될 수 있다: + </para> + + <programlisting><![CDATA[<class name="myClass" ...> + ... + <filter name="myFilter" condition=":myFilterParam = MY_FILTERED_COLUMN"/> +</class>]]></programlisting> + + <para> + 또는 콜렉션에 첨가될 수 있다: + </para> + + <programlisting><![CDATA[<set ...> + <filter name="myFilter" condition=":myFilterParam = MY_FILTERED_COLUMN"/> +</set>]]></programlisting> + + <para> + 또는 동시에 양자에(또는 각각의 여러번) 첨가될 수 있다. + </para> + + <para> + <literal>Session</literal> 상의 메소드들은 다음과 같다: <literal>enableFilter(String filterName)</literal>, + <literal>getEnabledFilter(String filterName)</literal>, <literal>disableFilter(String filterName)</literal>. + 디폴트로, 필터들은 주어진 세션에 대해 이용 가능하지 <emphasis>않다</emphasis>; 그것들은 <literal>Session.enabledFilter()</literal> + 메소드의 사용을 통해 명시적으로 이용 가능하게 되어야 한다. <literal>Session.enabledFilter()</literal>는 + <literal>Filter</literal> 인터페이스의 인스턴스를 반환한다. 위에 정의된 간단한 필터를 사용하면, 이것은 다음과 같을 것이다: + </para> + + <programlisting><![CDATA[session.enableFilter("myFilter").setParameter("myFilterParam", "some-value");]]></programlisting> + + <para> + org.hibernate.Filter 인터페이스 상의 메소드들은 Hibernate에 매우 공통된 method-chaining을 허용한다는 점을 노트하라. + </para> + + <para> + 유효한 기록 날짜 패턴을 가진 시간 데이터를 사용하는 전체 예제 : + </para> + + <programlisting><![CDATA[<filter-def name="effectiveDate"> + <filter-param name="asOfDate" type="date"/> +</filter-def> + +<class name="Employee" ...> +... + <many-to-one name="department" column="dept_id" class="Department"/> + <property name="effectiveStartDate" type="date" column="eff_start_dt"/> + <property name="effectiveEndDate" type="date" column="eff_end_dt"/> +... + <!-- + Note that this assumes non-terminal records have an eff_end_dt set to + a max db date for simplicity-sake + --> + <filter name="effectiveDate" + condition=":asOfDate BETWEEN eff_start_dt and eff_end_dt"/> +</class> + +<class name="Department" ...> +... + <set name="employees" lazy="true"> + <key column="dept_id"/> + <one-to-many class="Employee"/> + <filter name="effectiveDate" + condition=":asOfDate BETWEEN eff_start_dt and eff_end_dt"/> + </set> +</class>]]></programlisting> + + <para> + 그때 당신이 현재 유효한 레코드들을 항상 얻는 것을 확실히 하기 위해, employee 데이터를 검색하기 전에 세션 상에 필터를 + 간단하게 이용 가능하게 하라: + </para> + +<programlisting><![CDATA[Session session = ...; +session.enabledFilter("effectiveDate").setParameter("asOfDate", new Date()); +List results = session.createQuery("from Employee as e where e.salary > :targetSalary") + .setLong("targetSalary", new Long(1000000)) + .list(); +]]></programlisting> + + <para> + 위의 HQL 에서, 심지어 비록 우리가 결과들에 대한 봉급 컨스트레인트를 명시적으로 언급만 했을지라도, 이용 가능한 필터 때문에 + 그 질의는 봉급이 백만달러 이상인 현재 채용중인 직원들만을 반환할 것이다. + </para> + + <para> + 노트: 만일 당신이 outer 조인에 대해 필터들을 사용할 계획이라면 (HQL이든 로드 페칭이든) 조건 표현식의 방향을 주의하라. + 이것을 left outer join으로 설정하는 것이 가장 안전하다; 일반적으로 오퍼레이터 뒤에 있는 컬럼 이름(들)이 뒤따르는 첫번째에 + 파라미터를 위치지워라. + </para> + + </sect1> + + <para> + 필터가 정의된 후에는 그것 자신의 조건에 대해 각각 여러 개의 엔티티들 그리고/또는 콜렉션들에 첨가될 수 있다. + 조건들이 매번 동일할 때 그것은 지루할 수 있다. 따라서 <literal>&lt;filter-def/&gt;</literal>은 + attribute 든 CDATA 든 어느것이든 디폴트 조건을 정의하는 것을 허용해준다: + </para> + + <programlisting><![CDATA[<filter-def name="myFilter" condition="abc > xyz">...</filter-def> +<filter-def name="myOtherFilter">abc=xyz</filter-def>]]></programlisting> + + <para> + 그때 이 디폴트 조건은 그 필터가 어떤 조건을 지정함이 없이 어떤 것에 첨가될때마다 사용될 수 있다. + 이것은 당신이 특정한 경우에 디폴트 조건을 오버라이드 시키는 필터의 첨가 부분으로서 특정 조건을 + 부여할 수 있음을 의미함을 노트하라. + </para> + +</chapter> + Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/inheritance_mapping.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/inheritance_mapping.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/inheritance_mapping.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/inheritance_mapping.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,459 @@ +<chapter id="inheritance"> + <title>상속 매핑</title> + + <sect1 id="inheritance-strategies" revision="3"> + <title>세 가지 방도들</title> + + <para> + Hibernate는 세 가지 기본적인 상속 매핑 방도들을 지원한다: + </para> + + <itemizedlist> + <listitem> + <para> + table per class hierarchy + </para> + </listitem> + <listitem> + <para> + table per subclass + </para> + </listitem> + <listitem> + <para> + table per concrete class + </para> + </listitem> + </itemizedlist> + + <para> + 게다가 Hibernate는 네 번째의 약간 다른 종류의 다형성을 지원한다: + </para> + + <itemizedlist> + <listitem> + <para> + implicit polymorphism(함축적인 다형성) + </para> + </listitem> + </itemizedlist> + + <para> + 동일한 상속 계층구조의 다른 가지들에 대해 다른 매핑 방도들을 사용하는 것이 가능하고, 그런 다음 전체 계층 구조를 가로질러 + 다형성을 성취하는데 함축적인 다형성을 사용하라. 하지만 Hibernate는 동일한 루트 <literal>&lt;class&gt;</literal> 요소 + 하에서 <literal>&lt;subclass&gt;</literal> 그리고 <literal>&lt;joined-subclass&gt;</literal> 그리고 + <literal>&lt;union-subclass&gt;</literal> 매핑들을 혼합하는 것을 지원하지 않는다. 동일한 <literal>&lt;class&gt;</literal> + 요소 하에서 <literal>&lt;subclass&gt;</literal> 요소와 <literal>&lt;join&gt;</literal> 요소를 결합시킴으로써 + table per hierarchy 방도와 table per subclass 방도를 함께 혼합시키는 것이 가능하다(아래를 보라). + </para> + + <para> + 별도의 매핑 문서 내에, <literal>hibernate-mapping</literal> 바로 밑에 <literal>subclass</literal>, + <literal>union-subclass</literal>, 그리고 <literal>joined-subclass</literal> 매핑들을 정의하는 것이 + 가능하다. 이것은 단지 하나의 새로운 매핑 파일을 추가시켜서 하나의 class 계층구조를 확장하는 것을 당신에게 허용해준다. + 당신은 subclass 매핑 내에 앞서 매핑된 슈퍼클래스를 명명하여 <literal>extends</literal> 속성을 지정해야 한다. + 노트 : 명백하게 이 특징은 매핑 문서들의 순서를 중요하게끔 만들었다. Hibernate3 이후로, 매핑 파일들의 순서는 extends 키워드를 + 사용할 때 상관없다. 하나의 매핑 파일 내의 순서는 여전히 서브클래스들에 앞서 슈퍼클래스들을 정의하는데 여전히 필요하다. + </para> + + <programlisting><![CDATA[ + <hibernate-mapping> + <subclass name="DomesticCat" extends="Cat" discriminator-value="D"> + <property name="name" type="string"/> + </subclass> + </hibernate-mapping>]]></programlisting> + + + <sect2 id="inheritance-tableperclass" > + <title>Table per class hierarchy</title> + + <para> + 우리가 <literal>CreditCardPayment</literal>, <literal>CashPayment</literal>, <literal>ChequePayment</literal> + 구현자들을 가진 하나의 인터페이스 <literal>Payment</literal>를 갖고 있다고 가정하자. table per hierarchy 매핑은 + 다음과 같을 것이다: + </para> + + <programlisting><![CDATA[<class name="Payment" table="PAYMENT"> + <id name="id" type="long" column="PAYMENT_ID"> + <generator class="native"/> + </id> + <discriminator column="PAYMENT_TYPE" type="string"/> + <property name="amount" column="AMOUNT"/> + ... + <subclass name="CreditCardPayment" discriminator-value="CREDIT"> + <property name="creditCardType" column="CCTYPE"/> + ... + </subclass> + <subclass name="CashPayment" discriminator-value="CASH"> + ... + </subclass> + <subclass name="ChequePayment" discriminator-value="CHEQUE"> + ... + </subclass> +</class>]]></programlisting> + + <para> + 정확히 하나의 테이블이 필요하다. 이 매핑 방도에는 다음의 하나의 큰 제약이 존재한다: <literal>CCTYPE</literal>과 같이, + 서브 클래스들에 의해 선언된 컬럼들은 <literal>NOT NULL</literal> 컨스트레인트들을 가질 수 없다. + </para> + + </sect2> + + <sect2 id="inheritance-tablepersubclass"> + <title>Table per subclass</title> + + <para> + table per subclass 매핑은 다음과 같을 것이다: + </para> + + <programlisting><![CDATA[<class name="Payment" table="PAYMENT"> + <id name="id" type="long" column="PAYMENT_ID"> + <generator class="native"/> + </id> + <property name="amount" column="AMOUNT"/> + ... + <joined-subclass name="CreditCardPayment" table="CREDIT_PAYMENT"> + <key column="PAYMENT_ID"/> + <property name="creditCardType" column="CCTYPE"/> + ... + </joined-subclass> + <joined-subclass name="CashPayment" table="CASH_PAYMENT"> + <key column="PAYMENT_ID"/> + ... + </joined-subclass> + <joined-subclass name="ChequePayment" table="CHEQUE_PAYMENT"> + <key column="PAYMENT_ID"/> + ... + </joined-subclass> +</class>]]></programlisting> + + <para> + 네 개의 테이블들이 필요하다. 세 개의 서브클래스 테이블들은 슈퍼클래스 테이블에 대한 프라이머리 키 연관들을 갖는다 + (따라서 그 관계형 모형은 실제로 one-to-one 연관이다). + </para> + + </sect2> + + <sect2 id="inheritance-tablepersubclass-discriminator" revision="2"> + <title>discriminator를 사용하는, table per subclass</title> + + <para> + table-per-subclass에 대한 Hibernate의 구현은 discriminator(판별자) 컬럼을 필요로 하지 않음을 노트하라. + 다른 객체/관계형 매핑기들은 슈퍼클래스 테이블 속에 하나의 타입 판별자 컬럼을 필요로 하는 table-per-subclass에 대한 다른 구현을 + 사용한다. Hibernate에 의해 채택된 접근법은 구현하기가 훨씬 더 어렵지만 관계형 관점에서는 아마 틀림없이 보다 더 정확하다. + 만일 당신이 table per subclass 방도에 대해 하나의 판별자 컬럼을 사용하고 싶다면, 당신은 다음과 같이 + <literal>&lt;subclass&gt;</literal>와 <literal>&lt;join&gt;</literal>의 사용을 결합시킬 수도 있다: + </para> + + <programlisting><![CDATA[<class name="Payment" table="PAYMENT"> + <id name="id" type="long" column="PAYMENT_ID"> + <generator class="native"/> + </id> + <discriminator column="PAYMENT_TYPE" type="string"/> + <property name="amount" column="AMOUNT"/> + ... + <subclass name="CreditCardPayment" discriminator-value="CREDIT"> + <join table="CREDIT_PAYMENT"> + <key column="PAYMENT_ID"/> + <property name="creditCardType" column="CCTYPE"/> + ... + </join> + </subclass> + <subclass name="CashPayment" discriminator-value="CASH"> + <join table="CASH_PAYMENT"> + <key column="PAYMENT_ID"/> + ... + </join> + </subclass> + <subclass name="ChequePayment" discriminator-value="CHEQUE"> + <join table="CHEQUE_PAYMENT" fetch="select"> + <key column="PAYMENT_ID"/> + ... + </join> + </subclass> +</class>]]></programlisting> + + <para> + 선택적인 <literal>fetch="select"</literal> 선언은 슈퍼클래스를 질의할 때 outer join을 사용하여 + <literal>ChequePayment</literal> 서브클래스 데이터를 페치시키지 않도록 Hibernate에게 알려준다. + </para> + + </sect2> + + <sect2 id="inheritance-mixing-tableperclass-tablepersubclass"> + <title>table per class hierarchy와 table per subclass를 혼합하기</title> + + <para> + 당신은 이 접근법을 사용하여 table per hierarchy 방도와 table per subclass 방도를 혼합시킬 수 있다: + </para> + + <programlisting><![CDATA[<class name="Payment" table="PAYMENT"> + <id name="id" type="long" column="PAYMENT_ID"> + <generator class="native"/> + </id> + <discriminator column="PAYMENT_TYPE" type="string"/> + <property name="amount" column="AMOUNT"/> + ... + <subclass name="CreditCardPayment" discriminator-value="CREDIT"> + <join table="CREDIT_PAYMENT"> + <property name="creditCardType" column="CCTYPE"/> + ... + </join> + </subclass> + <subclass name="CashPayment" discriminator-value="CASH"> + ... + </subclass> + <subclass name="ChequePayment" discriminator-value="CHEQUE"> + ... + </subclass> +</class>]]></programlisting> + + <para> + 이들 매핑 방도들 중 어떤 것에 대해, 루트 <literal>Payment</literal> 클래스에 대한 하나의 다형성 연관은 + <literal>&lt;many-to-one&gt;</literal>을 사용하여 매핑된다. + </para> + + <programlisting><![CDATA[<many-to-one name="payment" column="PAYMENT_ID" class="Payment"/>]]></programlisting> + + </sect2> + + <sect2 id="inheritance-tableperconcrete" revision="2"> + <title>Table per concrete class</title> + + <para> + 우리가 table per concrete class 방도 매핑에 대해 취할 수 있는 두 가지 방법들이 존재한다. 첫 번째는 + <literal>&lt;union-subclass&gt;</literal>를 사용하는 것이다. + </para> + + <programlisting><![CDATA[<class name="Payment"> + <id name="id" type="long" column="PAYMENT_ID"> + <generator class="sequence"/> + </id> + <property name="amount" column="AMOUNT"/> + ... + <union-subclass name="CreditCardPayment" table="CREDIT_PAYMENT"> + <property name="creditCardType" column="CCTYPE"/> + ... + </union-subclass> + <union-subclass name="CashPayment" table="CASH_PAYMENT"> + ... + </union-subclass> + <union-subclass name="ChequePayment" table="CHEQUE_PAYMENT"> + ... + </union-subclass> +</class>]]></programlisting> + + <para> + 세 개의 테이블들이 슈퍼클래스들에 대해 수반된다. 각각의 테이블은 상속된 프로퍼티들을 포함하여, 그 클래스의 모든 프로퍼티들에 대한 컬럼들을 정의한다. + </para> + + <para> + 이 접근법의 제약은 만일 하나의 프로퍼티가 슈퍼클래스 상으로 매핑될 경우, 그 컬럼 이름이 모든 서브클래스 테이블들 상에서 같아야 한다는 + 점이다.(장래의 Hibernate 배포본에서 우리는 이 제약을 풀 수도 있다.) identity 생성기 방도는 union 서브클래스 상속에서 허용되지 + 않으며, 진정 프라이머리 키 시드는 하나의 계층구조의 모든 unioned 서브클래스들을 가로질러 공유되어야 한다. + </para> + + <para> + 만일 당신의 슈퍼클래스가 abstract일 경우에, 그것을 <literal>abstract="true"</literal>로 매핑하라. + 물론 만일 그것이 abstract가 아닐 경우, 추가적인 테이블(위의 예제에서는 디폴트로 <literal>PAYMENT</literal>)이 + 슈퍼클래스의 인스턴스들을 소유하는데 필요하다. + </para> + + </sect2> + + <sect2 id="inheritance-tableperconcreate-polymorphism"> + <title>함축적인 다형성을 사용하는, table per concrete class</title> + + <para> + 대안적인 접근법은 함축적인 다형성을 사용하는 것이다: + </para> + + <programlisting><![CDATA[<class name="CreditCardPayment" table="CREDIT_PAYMENT"> + <id name="id" type="long" column="CREDIT_PAYMENT_ID"> + <generator class="native"/> + </id> + <property name="amount" column="CREDIT_AMOUNT"/> + ... +</class> + +<class name="CashPayment" table="CASH_PAYMENT"> + <id name="id" type="long" column="CASH_PAYMENT_ID"> + <generator class="native"/> + </id> + <property name="amount" column="CASH_AMOUNT"/> + ... +</class> + +<class name="ChequePayment" table="CHEQUE_PAYMENT"> + <id name="id" type="long" column="CHEQUE_PAYMENT_ID"> + <generator class="native"/> + </id> + <property name="amount" column="CHEQUE_AMOUNT"/> + ... +</class>]]></programlisting> + + <para> + 어느 곳에서도 우리가 명시적으로 <literal>Payment</literal> 인터페이스를 언급하지 않음을 주목하라. + 또한 <literal>Payment</literal>의 프로퍼티들이 서브클래스들 각각에서 매핑된다는 점을 주목하라. + 만일 당신이 중복을 피하고자 원한다면, XML 엔티티들을 사용하는 것을 고려하라(예를 들어 매핑에서 + <literal>DOCTYPE</literal> 선언과 <literal>&amp;allproperties;</literal>에서 + <literal>[ &lt;!ENTITY allproperties SYSTEM "allproperties.xml"&gt; ]</literal>). + </para> + + <para> + 이 접근법의 단점은 다형성 질의들을 수행할 때 Hibernate가 생성된 SQl <literal>UNION</literal>들을 생성시키는 + 않는다는 점이다. + </para> + + <para> + 이 매핑 방도의 경우, <literal>Payment</literal>에 대한 하나의 다형성 연관은 대개 <literal>&lt;any&gt;</literal>를 + 사용하여 매핑된다. + </para> + + <programlisting><![CDATA[<any name="payment" meta-type="string" id-type="long"> + <meta-value value="CREDIT" class="CreditCardPayment"/> + <meta-value value="CASH" class="CashPayment"/> + <meta-value value="CHEQUE" class="ChequePayment"/> + <column name="PAYMENT_CLASS"/> + <column name="PAYMENT_ID"/> +</any>]]></programlisting> + + </sect2> + + <sect2 id="inheritace-mixingpolymorphism"> + <title>함축적인 다형성을 다른 상속 매핑들과 혼합하기</title> + + <para> + 이 매핑에 대해 주목할 하나 이상의 것이 존재한다. 서브클래스들이 그것들 자신의<literal>&lt;class&gt;</literal> 요소 내에 + 각각 매핑되므로(그리고 <literal>Payment</literal>가 단지 인터페이스이므로), 서브클래스들 각각은 쉽게 또 다른 상속 계층구조의 + 부분일 수 있다! (그리고 당신은 <literal>Payment</literal> 인터페이스에 대해 여전히 다형성 질의들을 사용할 수 있다.) + </para> + + <programlisting><![CDATA[<class name="CreditCardPayment" table="CREDIT_PAYMENT"> + <id name="id" type="long" column="CREDIT_PAYMENT_ID"> + <generator class="native"/> + </id> + <discriminator column="CREDIT_CARD" type="string"/> + <property name="amount" column="CREDIT_AMOUNT"/> + ... + <subclass name="MasterCardPayment" discriminator-value="MDC"/> + <subclass name="VisaPayment" discriminator-value="VISA"/> +</class> + +<class name="NonelectronicTransaction" table="NONELECTRONIC_TXN"> + <id name="id" type="long" column="TXN_ID"> + <generator class="native"/> + </id> + ... + <joined-subclass name="CashPayment" table="CASH_PAYMENT"> + <key column="PAYMENT_ID"/> + <property name="amount" column="CASH_AMOUNT"/> + ... + </joined-subclass> + <joined-subclass name="ChequePayment" table="CHEQUE_PAYMENT"> + <key column="PAYMENT_ID"/> + <property name="amount" column="CHEQUE_AMOUNT"/> + ... + </joined-subclass> +</class>]]></programlisting> + + <para> + 다시 한번, 우리는 <literal>Payment</literal>를 명시적으로 언급하지 않는다. 만일 우리가 <literal>Payment</literal> + 인터페이스에 대해 하나의 질의를 실행할 경우-예를 들어, from Payment-, Hibernate는 <literal>CreditCardPayment</literal> + (와 그것의 서브클래스들, 왜냐하면 그것들 또한 <literal>Payment</literal>를 구현하므로), <literal>CashPayment</literal> + 그리고 <literal>ChequePayment</literal> 인스턴스들을 자동적으로 반환할 것이지만 + <literal>NonelectronicTransaction</literal>의 인스턴스들을 반환하지 않는다. + </para> + + </sect2> + + </sect1> + + <sect1 id="inheritance-limitations"> + <title>제약들</title> + + <para> + table per concrete-class 매핑 방도에 대한 "함축적인 다형성" 접근법에는 어떤 제약들이 존재한다. + <literal>&lt;union-subclass&gt;</literal> 매핑들에 대해서는 다소 덜 제한적인 제약들이 존재한다: + </para> + + <para> + 다음 표는 Hibernate에서 table per concrete-class 매핑들에 대한 제약들, 그리고 함축적인 다형성에 대한 제약들을 보여준다. + </para> + + <table frame="topbot"> + <title>상속 매핑들의 특징들</title> + <tgroup cols='8' align='left' colsep='1' rowsep='1'> + <colspec colname='c1' colwidth="1*"/> + <colspec colname='c2' colwidth="1*"/> + <colspec colname='c3' colwidth="1*"/> + <colspec colname='c4' colwidth="1*"/> + <colspec colname='c5' colwidth="1*"/> + <colspec colname='c6' colwidth="1*"/> + <colspec colname='c7' colwidth="1*"/> + <colspec colname='c8' colwidth="1*"/> + <thead> + <row> + <entry>상속 방도</entry> + <entry>다형성 다대일</entry> + <entry>다형성 일대일</entry> + <entry>다형성 일대다</entry> + <entry>다형성 다대다</entry> + <entry>다형성 <literal>load()/get()</literal></entry> + <entry>다형성 질의들</entry> + <entry>다형성 조인들</entry> + <entry>Outer 조인 페칭</entry> + </row> + </thead> + <tbody> + <row> + <entry>table per class-hierarchy</entry> + <entry><literal>&lt;many-to-one&gt;</literal></entry> + <entry><literal>&lt;one-to-one&gt;</literal></entry> + <entry><literal>&lt;one-to-many&gt;</literal></entry> + <entry><literal>&lt;many-to-many&gt;</literal></entry> + <entry><literal>s.get(Payment.class, id)</literal></entry> + <entry><literal>from Payment p</literal></entry> + <entry><literal>from Order o join o.payment p</literal></entry> + <entry><emphasis>지원됨</emphasis></entry> + </row> + <row> + <entry>table per subclass</entry> + <entry><literal>&lt;many-to-one&gt;</literal></entry> + <entry><literal>&lt;one-to-one&gt;</literal></entry> + <entry><literal>&lt;one-to-many&gt;</literal></entry> + <entry><literal>&lt;many-to-many&gt;</literal></entry> + <entry><literal>s.get(Payment.class, id)</literal></entry> + <entry><literal>from Payment p</literal></entry> + <entry><literal>from Order o join o.payment p</literal></entry> + <entry><emphasis>지원됨</emphasis></entry> + </row> + <row> + <entry>table per concrete-class (union-subclass)</entry> + <entry><literal>&lt;many-to-one&gt;</literal></entry> + <entry><literal>&lt;one-to-one&gt;</literal></entry> + <entry><literal>&lt;one-to-many&gt;</literal> (for <literal>inverse="true"</literal> only)</entry> + <entry><literal>&lt;many-to-many&gt;</literal></entry> + <entry><literal>s.get(Payment.class, id)</literal></entry> + <entry><literal>from Payment p</literal></entry> + <entry><literal>from Order o join o.payment p</literal></entry> + <entry><emphasis>지원됨</emphasis></entry> + </row> + <row> + <entry>table per concrete class (implicit polymorphism)</entry> + <entry><literal>&lt;any&gt;</literal></entry> + <entry><emphasis>지원되지 않음</emphasis></entry> + <entry><emphasis>지원되지 않음</emphasis></entry> + <entry><literal>&lt;many-to-any&gt;</literal></entry> + <entry><literal>s.createCriteria(Payment.class).add( Restrictions.idEq(id) ).uniqueResult()</literal></entry> + <entry><literal>from Payment p</literal></entry> + <entry><emphasis>지원되지 않음</emphasis></entry> + <entry><emphasis>지원되지 않음</emphasis></entry> + </row> + </tbody> + </tgroup> + </table> + + </sect1> + +</chapter> Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/performance.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/performance.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/performance.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/performance.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,1293 @@ +<chapter id="performance"> + <title>퍼포먼스 개선하기</title> + + <sect1 id="performance-fetching" revision="2"> + <title>페칭 방도들</title> + + <para> + <emphasis>페칭 방도</emphasis>는 어플리케이션이 연관을 네비게이트할 필요가 있을 때 Hibernate가 연관된 객체들을 검색하는데 + 사용하게 될 방도이다.페치 방도들은 O/R 매핑 메타데이터 내에서 선언될 수 있거나 하나의 특정 HQL 또는 <literal>Criteria</literal> + 질의에 의해 오버라이드 될 수도 있다. + </para> + + <para> + Hibernate3는 다음 페칭 방도들을 정의한다: + </para> + + <itemizedlist> + <listitem> + <para> + <emphasis>Join 페칭</emphasis> - Hibernate는 <literal>OUTER JOIN</literal>을 사용하여 연관된 인스턴스 + 또는 동일한 <literal>SELECT</literal> 내에서 콜렉션을 검색한다. + </para> + </listitem> + <listitem> + <para> + <emphasis>Select 페칭</emphasis> - 두 번째 <literal>SELECT</literal>는 연과된 엔티티 또는 콜렉션을 검색하는데 + 사용된다. 당신이 <literal>lazy="false"</literal>를 지정함으로써 명시적으로 lazy 페칭을 사용 불가능하게 하지 않는 + 한, 이 두 번째 select는 당신이 그 연관에 실제로 액세스할 때 오직 실행될 것이다. + </para> + </listitem> + <listitem> + <para> + <emphasis>Subselect 페칭</emphasis> - 두 번째 <literal>SELECT</literal>는 이전 질의 또는 페치에서 검색된 + 모든 엔티티들에 대해 연관된 콜렉션들을 검색하는데 사용된다. 당신이 <literal>lazy="false"</literal>를 지정하여 + 명시적으로 lazy 페칭을 사용 불가능하게 하지 않는 한, 이 두 번째 select는 당신이 실제로 그 연관에 접근할 때 오직 실행될 + 것이다. + </para> + </listitem> + <listitem> + <para> + <emphasis>Batch 페칭</emphasis> - select 페칭을 위한 최적화 방도 - Hibernate는 프라이머리 키들이나 foreign + 키들의 리스트를 지정함으로써 하나의<literal>SELECT</literal> 내에서 엔티티 인스턴스들이나 콜렉션들에 대한 batch를 + 검색한다. + </para> + </listitem> + </itemizedlist> + + <para> + Hibernate는 또한 다음 사이를 구별 짓는다: + </para> + + <itemizedlist> + <listitem> + <para> + <emphasis>즉각적인 페칭</emphasis> - 소유자가 로드될 때, 연관, 콜렉션 또는 속성이 즉시 페치된다. + </para> + </listitem> + <listitem> + <para> + <emphasis>Lazy 콜렉션 페칭</emphasis> - 어플리케이션이 그 콜렉션에 대해 하나의 오퍼레이션을 호출할 때 + 콜렉션이 페치된다.(이것은 콜렉션들에 대해 디폴트이다.) + </para> + </listitem> + <listitem> + <para> + <emphasis>"Extra-lazy" 콜렉션 페칭</emphasis> - 콜렉션의 개별 요소들은 필요할 때 + 데이터베이스로부터 접근된다. Hibernate는 절대적으로 필요하지 않은 한 전체 콜렉션을 메모리 내로 + 페치하려고 시도하지 않는다(매우 큰 콜렉션에 적합함) + </para> + </listitem> + <listitem> + <para> + <emphasis>프락시 페칭</emphasis> - 식별자 getter가 아닌 다른 메소드가 연관된 객체에 대해 호출될 때 + 단일 값 연관이 페치된다. + </para> + </listitem> + <listitem> + <para> + <emphasis>"No-proxy" 페칭</emphasis> - 인스턴스 변수가 접근될 때 단일 값 연관이 페치된다. + 프락시 페칭과 비교할 때, 이 접근법은 다소 덜 lazy하지만(그 연관은 심지어 유일하게 식별자가 접근될 때에도 + 페치된다)보다 투명하다. 왜냐하면 프락시는 어플리케이션에 가시적이지 않기 때문이다. 이 접근법은 빌드 시 + 바이트코드 수단을 필요로 하며 드물게 필요하다. + </para> + </listitem> + <listitem> + <para> + <emphasis>Lazy 속성 페칭</emphasis> - 인스턴스 변수가 접근될 때 속성 또는 단일 값 연관이 페치된다 + 이 접근법은 빌드시 바이트코드 수단을 필요로 하며 드물게 필요하다. + </para> + </listitem> + </itemizedlist> + + <para> + 우리는 여기서 두 개의 직교하는 개념들을 갖는다: 연관이 페치될 <emphasis>때</emphasis>, 그리고 그것이 페치되는 + <emphasis>방법</emphasis>(사용되는 SQL). 그것들을 혼동하지 말라! 우리는 퍼포먼스를 튜팅하는데 + <literal>페치</literal>를 사용한다. 우리는 특정 클래스의 어떤 detached 인스턴스 내에서 항상 이용 가능한 + 데이터가 무엇인지에 대한 계약을 정의하는데 <literal>lazy</literal>를 사용할 수 있다. + </para> + + <sect2 id="performance-fetching-lazy"> + <title>lazy 연관들로 작업하기</title> + + <para> + 디폴트로 Hibernate3는 콜렉션들에 대해 lazy select 페칭을 사용하고, 단일 값 연관들에 대해 lazy + 프락시 페칭을 사용한다. 이들 디폴트들은 거의 모든 어플리케이션들에서 거의 모든 연관들에 대해 유의미하다. + </para> + + <para> + <emphasis>노트:</emphasis> 만일 당신이 <literal>hibernate.default_batch_fetch_size</literal>를 설정하는 + 경우, Hibernate는 lazy 페칭을 위한 batch 페치 최적화를 사용할 것이다(이 최적화는 또한 더 많은 과립상의 레벨에서 이용 가능할 + 수 있다). + </para> + + <para> + 하지만, lazy 페칭은 당신이 알고 있어야 하는 한 가지 문제를 제기한다. 열려진 Hibernate 세션 컨텍스트 외부에서 lazy 연관에 + 대한 접근은 예외상황으로 귀결될 것이다. 예를 들면 : + </para> + + <programlisting><![CDATA[s = sessions.openSession(); +Transaction tx = s.beginTransaction(); + +User u = (User) s.createQuery("from User u where u.name=:userName") + .setString("userName", userName).uniqueResult(); +Map permissions = u.getPermissions(); + +tx.commit(); +s.close(); + +Integer accessLevel = (Integer) permissions.get("accounts"); // Error!]]></programlisting> + + <para> + <literal>Session</literal>이 닫혔을 때 permissions 콜렉션이 초기화 되지 않았으므로, 그 콜렉션은 그것의 상태를 로드시킬 + 수가 없을 것이다. <emphasis>Hibernate 는 detached 객체들에 대한 lazy 초기화를 지원하지 않는다.</emphasis> 정정은 + 콜렉션으로부터 읽어들이는 코드를 커밋 바로 직전으로 이동시키는 것이다. + </para> + + <para> + 다른 방법으로 연관 매핑에 대해 <literal>lazy="false"</literal>를 지정함으로써, non-lazy 콜렉션 또는 + non-lazy 연관을 사용할 수 있다. 하지만 lazy 초기화는 거의 모든 콜렉션들과 연관들에 대해 사용되도록 고안되어 있다. + 만일 당신이 당신의 객체 모형 내에 너무 많은 non-lazy 연관들을 정의할 경우, Hibernate는 모든 트랜잭션에서 전체 + 데이터베이스를 메모리 속으로 페치하는 필요성을 끝내게 될 것이다! + </para> + + <para> + 다른 한편으로, 우리는 특정 트랜잭션 내에서 select 페칭 대신에 (고유하게 non-lazy인) join 페칭을 선택하기를 자주 원한다. + 우리는 이제 페칭 방도를 맞춤화 시키는 방법을 알게 될 것이다. Hibernate3에서, 페치 방도를 선택하는 메커니즘은 단일 값 연관들과 + 콜렉션들에 대해 동일하다. + </para> + + </sect2> + + <sect2 id="performance-fetching-custom" revision="4"> + <title>페치 방도들을 튜닝하기</title> + + <para> + select 페칭(디폴트)은 N+1 selects 문제점들에 매우 취약해서, 우리는 매핑 문서에서 join 페칭을 사용 가능하게 하기를 원할 + 수도 있다: + </para> + + <programlisting><![CDATA[<set name="permissions" + fetch="join"> + <key column="userId"/> + <one-to-many class="Permission"/> +</set]]></programlisting> + + <programlisting><![CDATA[<many-to-one name="mother" class="Cat" fetch="join"/>]]></programlisting> + + <para> + 매핑 문서 내에 정의된 <literal>fetch</literal> 방도는 다음에 영향을 준다: + </para> + + <itemizedlist> + <listitem> + <para> + <literal>get()</literal> 또는 <literal>load()</literal>를 통한 검색 + </para> + </listitem> + <listitem> + <para> + 연관이 네비게이트될 때 함축적으로 발생하는 검색 + </para> + </listitem> + <listitem> + <para> + <literal>Criteria</literal> 질의들 + </para> + </listitem> + <listitem> + <para> + <literal>subselect</literal> 페칭이 사용될 경우에 HQL 질의들 + </para> + </listitem> + </itemizedlist> + + <para> + 당신이 사용하는 페칭 방도가 무엇인가에 상관없이, 정의된 비-lazy 그래프가 메모리 내로 로드되는 것이 보장된다. + 이것은 하나의 특별한 HQL 질의를 실행시키는데 사용되는 몇몇 즉시적인 select들로 귀결될 수 있음을 노트하라. + </para> + + <para> + 대개, 우리는 페칭을 맞춤화 시키는데 매핑 문서를 사용하지 않는다. 대신에, 우리는 디폴트 특징을 유지하고, HQL에서 + <literal>left join fetch</literal>를 사용하여, 특정 트랜잭션에 대해 그것을 오버라이드 시킨다. 이것은 + outer join을 사용하여 첫 번째 select에서 초기에 그 연관을 eagerly 페치시킬 것을 Hibernate에게 알려준다. + <literal>Criteria</literal> query API에서, 우리는 <literal>setFetchMode(FetchMode.JOIN)</literal>을 + 사용한다. + </para> + + <para> + 만일 당신이 <literal>get()</literal> 또는 <literal>load()</literal>에 의해 사용된 페칭 방도를 변경시킬 수 있기를 + 당신이 원한다고 느낄 경우, 단순하게 <literal>Criteria</literal> 질의를 사용하라. 예를 들면: + </para> + + <programlisting><![CDATA[User user = (User) session.createCriteria(User.class) + .setFetchMode("permissions", FetchMode.JOIN) + .add( Restrictions.idEq(userId) ) + .uniqueResult();]]></programlisting> + + <para> + (이것은 몇몇 ORM 솔루션들이 "페치 계획"이라고 부르는 것에 대한 Hibernate의 등가물이다.) + </para> + + <para> + N+1 개의 select들을 가진 문제점들을 피하는 완전히 다른 방법은 second-level 캐시를 사용하는 것이다. + </para> + + </sect2> + + <sect2 id="performance-fetching-proxies" revision="2"> + <title>Single-ended 연관 프락시</title> + + <para> + 콜렉션들에 대한 Lazy 페칭은 영속 콜렉션들에 대한 Hibernate 자신의 구현을 사용하여 구현된다. 하지만 다른 메커니즘은 + single-ended 연관들에서 lazy 특징에 필요하다. 연관의 대상 엔티티는 프락시 되어야 한다. Hibernate는 + (훌륭한 CGLIB 라이브러리를 통해) 런타임 바이트코드 증진을 사용하여 영속 객체들에 대한 lazy 초기화 프락시들을 구현한다. + </para> + + <para> + 디폴트로, Hibernate3는 모든 영속 클래스들에 대해 (시작 시에) 프락시들을 생성시키고 <literal>many-to-one</literal> + 연관과 <literal>one-to-one</literal> 연관에 대해 lazy 페칭을 이용 가능하게 하는데 그것들을 사용한다. + </para> + + <para> + 매핑 파일은 그 클래스에 대한 프락시 인터페이스로서 사용할, <literal>proxy</literal> 속성을 가진, 인터페이스를 선언할 + 수도 있다. 디폴트로 Hibernate는 그 클래스의 서브클래스를 사용한다. <emphasis>프락시된 클래스는 최소한의 패키지 가시성 + (visibility)을 가진 디폴트 생성자를 구현해야 함을 노트하라. 우리는 모든 영속 클래스들에 대해 이 생성자를 권장한다!</emphasis> + </para> + + <para> + 다형성 클래스들에 대해 이 접근법을 확장할 때 의식해야 하는 몇몇 난처함들이 존재한다. 예를 들면. + </para> + + <programlisting><![CDATA[<class name="Cat" proxy="Cat"> + ...... + <subclass name="DomesticCat"> + ..... + </subclass> +</class>]]></programlisting> + + <para> + 첫 번째로, 심지어 기본 인스턴스가 <literal>DomesticCat</literal>의 인스턴스인 경우조차도, + <literal>Cat</literal>의 인스턴스들은 결코 <literal>DomesticCat</literal>으로 타입캐스트가 가능하지 않을 것이다: + </para> + + <programlisting><![CDATA[Cat cat = (Cat) session.load(Cat.class, id); // instantiate a proxy (does not hit the db) +if ( cat.isDomesticCat() ) { // hit the db to initialize the proxy + DomesticCat dc = (DomesticCat) cat; // Error! + .... +}]]></programlisting> + + <para> + 두번째로, 프락시 <literal>==</literal>를 파기할 가능성이 있다. + </para> + + <programlisting><![CDATA[Cat cat = (Cat) session.load(Cat.class, id); // instantiate a Cat proxy +DomesticCat dc = + (DomesticCat) session.load(DomesticCat.class, id); // acquire new DomesticCat proxy! +System.out.println(cat==dc); // false]]></programlisting> + + <para> + 하지만, 그 경우는 보이는 만큼 그렇게 나쁘지는 않다. 심지어 우리가 이제 다른 프락시 객체들에 대한 두 개의 참조를 가질지라도, + 기본 인스턴스는 여전히 동일한 객체들일 것이다: + </para> + + <programlisting><![CDATA[cat.setWeight(11.0); // hit the db to initialize the proxy +System.out.println( dc.getWeight() ); // 11.0]]></programlisting> + + <para> + 세번째로, 당신은 <literal>final</literal> 클래스 또는 임의의 <literal>final</literal> 메소드들을 가진 클래스에 + 대해 CGLIB 프락시를 사용하지 않을 수 있다. + </para> + + <para> + 마지막으로, 만일 당신의 영속 객체가 초기화 시에 어떤 리소스들을 필요로 할 경우(예를 들어, initializer들 또는 디폴트 생성자 + 내에서), 그때 그들 리소스들이 또한 프락시에 의해 획득될 것이다. 프락시 클래스는 영속 클래스에 대한 실제 서브클래스이다. + </para> + + <para> + 이들 문제점들은 모두 자바의 단일 상속 모형의 기본적인 제약 때문이다. 만일 당신이 이들 문제점들을 피하고자 원할 경우 당신의 영속 + 클래스들은 각각 그것의 비지니스 메소드들을 선언하는 인터페이스를 구현해야 한다. 당신은 매핑 파일 속에 이들 인터페이스들을 + 지정해야 한다. 예를 들면. + </para> + + <programlisting><![CDATA[<class name="CatImpl" proxy="Cat"> + ...... + <subclass name="DomesticCatImpl" proxy="DomesticCat"> + ..... + </subclass> +</class>]]></programlisting> + + <para> + 여기서 <literal>CatImpl</literal>은 <literal>Cat</literal> 인터페이스를 구현하고 <literal>DomesticCatImpl</literal>은 + <literal>DomesticCat</literal> 인터페이스를 구현한다. 그때 <literal>Cat</literal>과 <literal>DomesticCat</literal>의 + 인스턴스들에 대한 프락시들은 <literal>load()</literal> 또는 <literal>iterate()</literal>에 의해 반환될 수 있다. + (<literal>list()</literal>가 대개 프락시들을 반환하지 않음을 노트하라.) + </para> + + <programlisting><![CDATA[Cat cat = (Cat) session.load(CatImpl.class, catid); +Iterator iter = session.createQuery("from CatImpl as cat where cat.name='fritz'").iterate(); +Cat fritz = (Cat) iter.next();]]></programlisting> + + <para> + 관계들은 또한 lazy 초기화 된다. 이것은 당신이 임의의 프로퍼티들을 <literal>CatImpl</literal> 타입이 아닌 + <literal>Cat</literal> 타입으로 선언해야 함을 의미한다. + </para> + + <para> + 어떤 오퍼레이션들은 프락시 초기화를 필요로 하지 <emphasis>않는다</emphasis> + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + <literal>equals()</literal>, 만일 영속 클래스가 <literal>equals()</literal>를 오버라이드 시키지 않는 경우 + </para> + </listitem> + <listitem> + <para> + <literal>hashCode()</literal>, 만일 영속 클래스가<literal>hashCode()</literal>를 오버라이드 시키지 + 않는 경우 + </para> + </listitem> + <listitem> + <para> + 식별자 getter 메소드 + </para> + </listitem> + </itemizedlist> + + <para> + Hibernate는 <literal>equals()</literal> 또는 <literal>hashCode()</literal>를 오버라이드 시키는 영속 클래스들을 + 검출할 것이다. + </para> + + <para> + 디폴트 <literal>lazy="proxy"</literal> 대신에 <literal>lazy="no-proxy"</literal>를 선택하여, + 우리는 타입캐스팅과 연관된 문제점들을 피할 수 있다. 하지만 우리는 빌드 시 바이트코드 수단을 필요로 할 것이고, + 모든 연산들은 즉각적인 프락시 초기화로 귀결될 것이다. + </para> + + </sect2> + + <sect2 id="performance-fetching-initialization" revision="1"> + <title>콜렉션들과 프락시들을 초기화 시키기</title> + + <para> + 만일 초기화 되지 않은 콜렉션이나 프락시가 <literal>Session</literal> 영역의 외부에서 접근될 경우에, 예를 들어 콜렉션을 + 소유하거나 프락시에 대한 참조를 가진 엔티티가 detached 상태에 있을 때, <literal>LazyInitializationException</literal>이 + Hibernate에 의해 던져질 것이다. + </para> + + <para> + 때때로 우리는<literal>Session</literal>을 닫기 전에 프락시 또는 콜렉션이 초기화 됨을 확실히 할 필요가 있다. 물론 우리는 + 예를 들어 <literal>cat.getSex()</literal> 또는 <literal>cat.getKittens().size()</literal>를 호출하여 항상 + 초기화를 강제시킬 수 있다. 그러나 그것은 코드의 독자들에게는 혼동스럽고 일반적인 코드로 편의적이지 않다. + </para> + + <para> + static 메소드들 <literal>Hibernate.initialize()</literal>와 <literal>Hibernate.isInitialized()</literal>는 + lazy 초기화 된 콜렉션들이나 프락시들에 대해 작업하는 편리한 방법을 어플리케이션에 제공한다. <literal>Hibernate.initialize(cat)</literal>은 + 그것의 <literal>Session</literal>이 여전히 열려져 있는 한 프락시 <literal>cat</literal>의 초기화를 강제할 것이다. + <literal>Hibernate.initialize( cat.getKittens())</literal>는 kittens의 콜렉션에 대해 유사한 효과를 갖는다. + </para> + + <para> + 또 다른 옵션은 모든 필요한 콜렉션들과 프락시들이 로드되기 전까지 <literal>Session</literal>을 열린 채로 유지하는 것이다. + 몇몇 어플리케이션 아키텍처들, 특히 Hibernate를 사용하여 데이터에 접근하는 코드, 그리고 다른 어플리케이션 계층들이나 다른 + 물리적 프로세스들 내에서 그것을 사용하는 코드에서, 그것은 콜렉션이 초기화 될 때 <literal>Session</literal>이 열려져 + 있음을 확실히 하는 문제일 수 있다. 이 쟁점을 다루는 두 가지 기본 방법들이 존재한다: + </para> + + <itemizedlist> + <listitem> + <para> + 웹 기반 어플리케이션에서, 서블릿 필터는 뷰 렌더링이 완료되는, 사용자 요청의 바로 끝에서만 <literal>Session</literal>을 + 닫는데 사용될 수 있다(<emphasis>Open Session in View</emphasis> 패턴). 물론 이것은 당신의 어플리케이션 + 인프라스트럭처의 예외상황 처리의 정정에 관한 무거운 요구를 부과한다. + 뷰 렌더링 동안에 하나의 예외상황이 발생할때에도 사용자에게 반환되기 전에 <literal>Session</literal>이 닫혀지고 + 트랜잭션이 종료되는 것은 지극히 중요하다. 이 "Open Session in View" 패턴에 관한 예제들은 Hibernate 위키를 보라. + </para> + </listitem> + <listitem> + <para> + 별도의 비지니스 티어를 가진 어플리케이션에서, 비지니스 로직은 반환 전에 웹 티어에 필요한 모든 콜렉션들을 + "준비"해야 한다. 이것은 비지니스 티어가 모든 데이터를 로드시키고 이미 초기화된 모든 데이터를 특정 쓰임새에 + 필요한 프리젠테이션/웹 티어로 반환해야 함을 의미한다. 대개 어플리케이션은 웹 티어에 필요하게 될 각각의 콜렉션에 + 대해 <literal>Hibernate.initialize()</literal>를 호출하거나(이 호출은 세션이 닫히기 전에 발생해야 한다) + 또는 <literal>FETCH</literal> 절을 갖거나 또는 <literal>Criteria</literal> 내에 + <literal>FetchMode.JOIN</literal>을 가진 Hibernate 질의를 사용하여 콜렉션을 열심히 검색한다. 이것은 + 대개 당신이 <emphasis>Session Facade</emphasis> 대신 <emphasis>Command</emphasis> 패턴을 채택할 + 경우에 더 쉽다. + </para> + </listitem> + <listitem> + <para> + 당신은 또한 초기화 되지 않은 콜렉션들(또는 다른 프락시들)에 접근하기 전에 <literal>merge()</literal> 또는 + <literal>lock()</literal>으로 앞서 로드된 객체를 새로운 <literal>Session</literal>n에 첨부할 수도 있다. + 아니다. Hibernate는 이것을 자동적으로 행하지 않고, 확실히 자동적으로 행하지 <emphasis>않을 것이다</emphasis>. + 왜냐하면 그것은 특별한 목적을 위한 트랜잭션 의미를 도입할 것이기 때문이다! + </para> + </listitem> + </itemizedlist> + + <para> + 때때로 당신은 거대한 콜렉션을 초기화 시키는 것을 원하지 않지만, 여전히 (그것의 사이즈와 같은) 그것에 대한 어떤 정보 또는 + 데이터의 부분집합을 필요로 한다. + </para> + + <para> + 당신은 그것을 초기화 시키지 않고서 콜렉션의 사이즈를 얻는데 콜렉션 필터를 사용할 수 있다: + </para> + + <programlisting><![CDATA[( (Integer) s.createFilter( collection, "select count(*)" ).list().get(0) ).intValue()]]></programlisting> + + <para> + <literal>createFilter()</literal> 메소드는 또한 전체 콜렉션을 초기화 시킬 필요 없이 콜렉션의 부분집합들을 효율적으로 + 검색하는데 사용된다: + </para> + + <programlisting><![CDATA[s.createFilter( lazyCollection, "").setFirstResult(0).setMaxResults(10).list();]]></programlisting> + + </sect2> + + <sect2 id="performance-fetching-batch"> + <title>batch 페칭 사용하기</title> + + <para> + Hibernate는 배치 페칭을 효율적으로 사용할 수 있다. 즉 하나의 프락시가 액세스 될 경우에 Hibernate는 몇몇 초기화 되지 않은 + 프락시들을 로드시킬 수 있다(또는 콜렉션들). batch 페칭은 lazy select 페칭 방도에 대한 최적화이다. 당신이 batch + 페칭을 튜닝시킬 수 있는 두 가지 방법들이 존재한다: 클래스 레벨에서 그리고 콜렉션 레벨에서. + </para> + + <para> + 클래스들/엔티티들에 대한 batch 페칭은 이해하기가 더 쉽다. 당신이 실행 시에 다음 상황에 처한다고 상상하라: 당신은 하나의 + <literal>Session</literal> 속에 로드된 25개의 <literal>Cat</literal> 인스턴스들을 갖고 있고, 각각의 + <literal>Cat</literal>은 그것의 <literal>소유자</literal> 즉, <literal>Person</literal>에 대한 참조를 + 갖고 있다. <literal>Person</literal> 클래스는 프락시 <literal>lazy="true"</literal>로서 매핑된다. 만일 + 당신이 이제 모든 cat들을 통해 반복하고 각각의 cat에 대해 <literal>getOwner()</literal>를 호출할 경우, Hibernate는 + 프락시된 소유자들을 검색하기 위해 25개의 <literal>SELECT</literal> 문장들을 디폴트로 실행시킬 것이다. 당신은 + <literal>Person</literal> 매핑에서 <literal>batch-size</literal>를 지정함으로써 이 동작을 튜닝시킬 수 있다: + </para> + + <programlisting><![CDATA[<class name="Person" batch-size="10">...</class>]]></programlisting> + + <para> + Hibernate는 이제 세 개의 질의들 만을 실행시킬 것이고, 그 패턴은 10,10, 5 이다. + </para> + + <para> + 당신은 또한 콜렉션들에 대해 batch 페칭을 이용 가능하게 할 수도 있다. 예를 들어, 만일 각각의 <literal>Person</literal>이 + <literal>Cat</literal>들을 가진 lazy 콜렉션을 갖고, 10개의 person들이 <literal>Sesssion</literal> 내에 현재 + 로드되어 있을 경우, 모든 person들에 대한 반복은 10개의 <literal>SELECT</literal>들을 생성시킬 것이고, <literal>getCats()</literal>에 + 대한 매번의 호출에 대해 하나의 <literal>SELECT</literal>를 생성시킬 것이다. 만일 당신이 <literal>Person</literal> + 매핑에서 <literal>cats</literal> 콜렉션에 대해 batch 페칭을 사용가능하게 할 경우, Hibernate는 콜렉션들을 미리-페치 + 시킬 수 있다: + </para> + + <programlisting><![CDATA[<class name="Person"> + <set name="cats" batch-size="3"> + ... + </set> +</class>]]></programlisting> + + <para> + <literal>batch-size</literal> 8로서, Hibernate는 4개의 SELECT들에서 3, 3, 3, 1 개의 콜렉션들을 로드시킬 것이다. + 다시 그 속성의 값은 특정 <literal>Session</literal> 내에서 초기화 되지 않은 콜렉션들의 예상되는 개수에 의존한다. + </para> + + <para> + 만일 당신이 항목들의 포개진 트리를 가질 경우, 예를 들어 전형적인 bill-of-materials 패턴인 경우, (비록 + <emphasis>내포된 set</emphasis> 또는 <emphasis>실체화된 경로(materialized path)</emphasis>가 + 주로-읽기-트리들에 대해 더 좋은 옵션일 수 있을지라도) 콜렉션들에 대한 batch 페칭이 특히 유용하다. + </para> + + </sect2> + + <sect2 id="performance-fetching-subselect"> + <title>subselect 페칭 사용하기</title> + + <para> + 만일 한 개의 lazy 콜렉션이나 단일 값 프락시가 페치되어야 한다면, Hibernate는 하나의 subselect 내에서 원래의 + 질의를 다시 실행하여 그것들 모두를 로드시킨다. 이것은 조각난 로딩 없이 batch 페칭과 동일한 방식으로 동작한다. + </para> + + <!-- TODO: 이것에 대해 더 많이 작성할 것 --> + + </sect2> + + <sect2 id="performance-fetching-lazyproperties"> + <title>lazy 프로퍼티 페칭 사용하기</title> + + <para> + Hibernate3은 개별적인 프로퍼티들에 대한 lazy 페칭을 지원한다. 이 최적화 기술은 또한 <emphasis>fetch groups</emphasis> + 으로 알려져 있다. 이것이 대개 마케팅 특징임을 노트하길 바란다. 왜냐하면 실제로 행 읽기를 최적화 시키는 것이 컬럼 읽기에 대한 + 최적화 보다 훨씬 더 중요하기 때문이다. 하지만 리거시 테이블들이 수백 개의 컬럼들을 갖고 데이터 모형이 개선될 수 없을 때, + 오직 클래스의 몇몇 프로퍼티들을 로드시키는 것 만이 유용할 수도 있다. + </para> + + <para> + lazy 프로퍼티 로딩을 이용가능하게 하려면, 당신의 특정 property 매핑들에 대해 <literal>lazy</literal> 속성을 설정하라: + </para> + + <programlisting><![CDATA[<class name="Document"> + <id name="id"> + <generator class="native"/> + </id> + <property name="name" not-null="true" length="50"/> + <property name="summary" not-null="true" length="200" lazy="true"/> + <property name="text" not-null="true" length="2000" lazy="true"/> +</class>]]></programlisting> + + <para> + Lazy property 로딩은 빌드 시 바이트코드 수단을 필요로 한다! 만일 당신의 영속 클래스들이 개선되지 않을 경우, + Hibernate는 조용하게 lazy 프로퍼티 설정들을 무시하고 즉각적인 페칭으로 후퇴할 것이다. + </para> + + <para> + bytecode 수단으로, 다음 Ant 태스크를 사용하라: + </para> + + <programlisting><![CDATA[<target name="instrument" depends="compile"> + <taskdef name="instrument" classname="org.hibernate.tool.instrument.InstrumentTask"> + <classpath path="${jar.path}"/> + <classpath path="${classes.dir}"/> + <classpath refid="lib.class.path"/> + </taskdef> + + <instrument verbose="true"> + <fileset dir="${testclasses.dir}/org/hibernate/auction/model"> + <include name="*.class"/> + </fileset> + </instrument> +</target>]]></programlisting> + + <para> + 불필요한 컬럼 읽기를 피하는 다른 (더 좋은?) 방법은 적어도 읽기 전용 트랜잭션의 경우에 HQL 질의 또는 Criteria 질의의 + 투사(projection) 특징들을 사용하는 것이다. 이것은 빌드 시 바이트코드 처리에 대한 필요성을 피하게 해주고 확실히 선호되는 + 해결책이다. + </para> + + <para> + 당신은 HQL에서 <literal>fetch all properties</literal>를 사용하여 프로퍼티들에 대한 통상의 eager 페칭을 + 강제시킬 수 있다. + </para> + + </sect2> + + </sect1> + + <sect1 id="performance-cache" revision="1"> + <title>두번째 레벨 캐시</title> + + <para> + Hibernate <literal>Session</literal>은 영속 데이터에 대한 트랜잭션 레벨 캐시이다. class-by-class와 + collection-by-collection 기반 위에 클러스터 또는 JVM-레벨(<literal>SessionFactory</literal>-레벨) 캐시를 구성하는 + 것이 가능하다. 당신은 클러스터링 된 캐시 속에 플러그인 할 수도 있다. 주의하라. 캐시들은 (비록 그것들이 캐시된 데이터를 정기적으로 + 만료되도록 구성되어 있을지라도) 또 다른 어플리케이션에 의해 영속 저장소에 대해 행해진 변경들을 결코 알지 못한다. + </para> + + <para revision="1"> + 디폴트로, Hibernate는 JVM-레벨의 캐싱에 EHCache를 사용한다. (JCS 지원은 이제 진부하게 되었고 Hibernate의 장래 버전에서 + 제거될 것이다.) 당신은 <literal>hibernate.cache.provider_class</literal> 프로퍼티를 사용하여 + <literal>org.hibernate.cache.CacheProvider</literal>를 구현하는 클래스의 이름을 지정함으로써 다른 구현을 선택할 수도 + 있다. + You have the option to tell Hibernate which caching implementation to use by + specifying the name of a class that implements <literal>org.hibernate.cache.CacheProvider</literal> + using the property <literal>hibernate.cache.provider_class</literal>. Hibernate + comes bundled with a number of built-in integrations with open-source cache providers + (listed below); additionally, you could implement your own and plug it in as + outlined above. Note that versions prior to 3.2 defaulted to use EhCache as the + default cache provider; that is no longer the case as of 3.2. + 당신은 <literal>hibernate.cache.provider_class</literal> 프로퍼티를 사용하여 + <literal>org.hibernate.cache.CacheProvider</literal>를 구현하는 클래스의 이름을 지정함으로써 어느 캐싱 구현을 + 사용할 것인지를 Hibernate에게 알려주는 옵션을 갖는다. Hibernate는 (아래에 열거된) 오픈-소스 프로바이더들을 가진 + 많은 빌드되어 있는 통합들을 번들로 갖고 있다; 추가적으로 당신은 위에서 언급했듯이 그것에 당신 자신의 것을 구현할 수 있고 그것에 + 플러그 시킬 수 있다. 3.2 이번 버전들은 디플트 캐시 프로바이더로서 EhCache를 사용하도록 디포릍로 내장되어 있음을 노트하라; + 버전 3.2의 경우에 그것은 더이상 디폴트 내장이 아니다. + </para> + + <table frame="topbot" id="cacheproviders" revision="1"> + <title>캐시 프로바이더들</title> + <tgroup cols='5' align='left' colsep='1' rowsep='1'> + <colspec colname='c1' colwidth="1*"/> + <colspec colname='c2' colwidth="3*"/> + <colspec colname='c3' colwidth="1*"/> + <colspec colname='c4' colwidth="1*"/> + <colspec colname='c5' colwidth="1*"/> + <thead> + <row> + <entry>캐시</entry> + <entry>프로바이더 클래스</entry> + <entry>타입</entry> + <entry>클러스터 안전</entry> + <entry>질의 캐시 지원</entry> + </row> + </thead> + <tbody> + <row> + <entry>Hashtable (제품 용도로 고안되어 있지 않음)</entry> + <entry><literal>org.hibernate.cache.HashtableCacheProvider</literal></entry> + <entry>memory</entry> + <entry></entry> + <entry>yes</entry> + </row> + <row> + <entry>EHCache</entry> + <entry><literal>org.hibernate.cache.EhCacheProvider</literal></entry> + <entry>memory, disk</entry> + <entry></entry> + <entry>yes</entry> + </row> + <row> + <entry>OSCache</entry> + <entry><literal>org.hibernate.cache.OSCacheProvider</literal></entry> + <entry>memory, disk</entry> + <entry>yes (clustered invalidation)</entry> + <entry>yes</entry> + </row> + <row> + <entry>SwarmCache</entry> + <entry><literal>org.hibernate.cache.SwarmCacheProvider</literal></entry> + <entry>clustered (ip multicast)</entry> + <entry>yes (clustered invalidation)</entry> + <entry></entry> + </row> + <row> + <entry>JBoss TreeCache</entry> + <entry><literal>org.hibernate.cache.TreeCacheProvider</literal></entry> + <entry>clustered (ip multicast), transactional</entry> + <entry>yes (replication)</entry> + <entry>yes (clock sync req.)</entry> + </row> + </tbody> + </tgroup> + </table> + + <sect2 id="performance-cache-mapping" revision="2"> + <title>Cache 매핑들</title> + + <para> + 클래스 또는 콜렉션 매핑의 <literal>&lt;cache&gt;</literal> 요소는 다음 형식을 갖는다: + </para> + + <programlistingco> + <areaspec> + <area id="cache1" coords="2 70"/> + <area id="cache2" coords="3 70"/> + <area id="cache3" coords="4 70"/> + </areaspec> + <programlisting><![CDATA[<cache + usage="transactional|read-write|nonstrict-read-write|read-only" + region="RegionName" + include="all|non-lazy" +/>]]></programlisting> + <calloutlist> + <callout arearefs="cache1"> + <para> + <literal>usage</literal>(필수) 캐싱 방도를 지정한다: + <literal>transactional</literal>, + <literal>read-write</literal>, + <literal>nonstrict-read-write</literal> 또는 + <literal>read-only</literal> + </para> + </callout> + <callout arearefs="cache2"> + <para> + <literal>region</literal> (옵션, 디폴트는 class 또는 콜렉션 role 이름) + second level 캐시 영역의 이름을 지정한다 + </para> + </callout> + <callout arearefs="cache3"> + <para> + <literal>include</literal> (옵션, 디폴트는 <literal>all</literal>) + <literal>non-lazy</literal>는 <literal>lazy="true"</literal>로 매핑된 엔티티의 + 프로퍼티들을 지정하며 속성-레벨 lazy 페칭이 이용 가능할 때 키시될 수 없다 + </para> + </callout> + </calloutlist> + </programlistingco> + + <para> + 다른 방법으로 (선호적으로?), 당신은 <literal>hibernate.cfg.xml</literal> 내에 <literal>&lt;class-cache&gt;</literal>와 + <literal>&lt;collection-cache&gt;</literal> 요소들을 지정할 수도 있다. + </para> + + <para> + <literal>usage</literal> 속성은 <emphasis> 캐시 동시성 방도</emphasis>를 지정한다. + </para> + + </sect2> + + <sect2 id="performance-cache-readonly"> + <title>방도: 읽기 전용</title> + + <para> + 당신의 어플리케이션이 영속 클래스의 인스턴스들을 읽어들일 필요가 있지만 결코 변경할 필요가 없을 경우에 <literal>read-only</literal> + 캐시가 사용될 수 있다. 이것은 가장 간단한 최상의 퍼포먼스를 위한 방도이다. 그것은 클러스터 내 사용에는 완벽하게 안전하다. + </para> + + <programlisting><![CDATA[<class name="eg.Immutable" mutable="false"> + <cache usage="read-only"/> + .... +</class>]]></programlisting> + + </sect2> + + + <sect2 id="performance-cache-readwrite"> + <title>방도: 읽기/쓰기</title> + + <para> + 어플리케이션이 데이터를 업데이트 할 필요가 있을 경우, <literal>read-write</literal> 캐시가 적절하다. 만일 + 직렬화 가능한(serializable) 트랜잭션 격리 레벨이 필요한 경우에는 이 캐시 방도가 결코 사용되지 말아야 한다. 만일 캐시가 JTA + 환경에서 사용될 경우, 당신은 JTA <literal>TransactionManager</literal>를 얻는 방도를 명명하는 + <literal>hibernate.transaction.manager_lookup_class</literal> 프로퍼티를 지정해야 한다. 다른 환경들에서, + 당신은<literal>Session.close()</literal> 또는 <literal>Session.disconnect()</literal>가 호출될 때 + 트랜잭션이 완료되는 것을 확실히 해야 한다. 만일 당신이 클러스터 내에 이 방도를 사용하고자 원할 경우, 당신은 기본 캐시 구현이 + 잠금을 지원하도록 하는 것을 확실히 해야 한다. 미리 만들어진 캐시 프로바이더들은 그렇게 행하지 <emphasis>않는다</emphasis>. + </para> + + <programlisting><![CDATA[<class name="eg.Cat" .... > + <cache usage="read-write"/> + .... + <set name="kittens" ... > + <cache usage="read-write"/> + .... + </set> +</class>]]></programlisting> + + </sect2> + + <sect2 id="performance-cache-nonstrict"> + <title>방도: 엄격하지 않은 읽기/쓰기</title> + + <para> + 만일 어플리케이션이 오직 데이터를 자주 업데이트할 필요가 있고(예를 들어, 만일 두 개의 트랜잭션들이 동시에 동일한 항목을 업데이트 + 하려고 시도하는 정말 있음직하지 않은 경우) 그리고 엄격한 트랜잭션 격리가 필요하지 않은 경우, <literal>nonstrict-read-write</literal> + 캐시가 적절할 수 있다. 만일 그 캐시가 JTA 환경에서 사용될 경우, 당신은 <literal>hibernate.transaction.manager_lookup_class</literal>를 + 지정해야 한다. 다른 환경들에서, 당신은 <literal>Session.close()</literal> 또는 <literal>Session.disconnect()</literal>가 호출될 때 + 트랜잭션이 완료되도록 확실히 해야 한다. + </para> + + </sect2> + + <sect2 id="performance-cache-transactional"> + <title>방도: transactional</title> + + <para> + <literal>transactional</literal> 캐시 방도는 JBoss TreeCache와 같은 전체 트랜잭션적인 캐시 프로바이더들에 대한 + 지원을 제공한다. 그런 캐시는 오직 JTA 환경 내에서 사용될 수 있고 당신은 + <literal>hibernate.transaction.manager_lookup_class</literal>를 지정해야 한다. + </para> + + </sect2> + + <para> + 캐시 프로바이더들 중 어느 것도 모든 캐시 동시성 방도들을 지원하지 않는다. 다음 테이블은 어느 프로바이더들이 어느 동시성 방도들과 + 호환되는지를 보여준다. + </para> + + <table frame="topbot"> + <title>캐시 동시성 방도 지원</title> + <tgroup cols='5' align='left' colsep='1' rowsep='1'> + <colspec colname='c1' colwidth="1*"/> + <colspec colname='c2' colwidth="1*"/> + <colspec colname='c3' colwidth="1*"/> + <colspec colname='c4' colwidth="1*"/> + <colspec colname='c5' colwidth="1*"/> + <thead> + <row> + <entry>캐시</entry> + <entry>읽기 전용</entry> + <entry>엄격하지 않은 읽기-쓰기</entry> + <entry>읽기-쓰기</entry> + <entry>transactional</entry> + </row> + </thead> + <tbody> + <row> + <entry>Hashtable (제품용으로 고안되지 않음)</entry> + <entry>예</entry> + <entry>예</entry> + <entry>예</entry> + <entry></entry> + </row> + <row> + <entry>EHCache</entry> + <entry>예</entry> + <entry>예</entry> + <entry>예</entry> + <entry></entry> + </row> + <row> + <entry>OSCache</entry> + <entry>예</entry> + <entry>예</entry> + <entry>예</entry> + <entry></entry> + </row> + <row> + <entry>SwarmCache</entry> + <entry>예</entry> + <entry>예</entry> + <entry></entry> + <entry></entry> + </row> + <row> + <entry>JBoss TreeCache</entry> + <entry>예</entry> + <entry></entry> + <entry></entry> + <entry>예</entry> + </row> + </tbody> + </tgroup> + </table> + + </sect1> + + <sect1 id="performance-sessioncache" revision="2"> + <title>캐시들을 관리하기</title> + + <para> + 당신이 객체를 <literal>save()</literal>, <literal>update()</literal> 또는 <literal>saveOrUpdate()</literal>에 + 전달할 때마다 그리고 당신이 <literal>load()</literal>, <literal>get()</literal>, <literal>list()</literal>, + <literal>iterate()</literal> 또는 <literal>scroll()</literal>을 사용하여 객체를 검색할 때마다, 그 객체는 + <literal>Session</literal>의 내부 캐시에 추가된다. + </para> + <para> + <literal>flush()</literal>가 차후적으로 호출될 때, 그 객체의 상태는 데이터베이스와 동기화 될 것이다. 만일 당신이 이 동기화가 + 발생되는 것을 원하지 않거나 만일 당신이 대량의 객체들을 처리 중이고 메모리를 효율적으로 관리할 필요가 있을 경우, <literal>evict()</literal> + 메소드는 first-level 캐시로부터 그 객체와 그것의 콜렉션들을 제거하는데 사용될 수 있다. + </para> + + <programlisting><![CDATA[ScrollableResult cats = sess.createQuery("from Cat as cat").scroll(); //a huge result set +while ( cats.next() ) { + Cat cat = (Cat) cats.get(0); + doSomethingWithACat(cat); + sess.evict(cat); +}]]></programlisting> + + <para> + <literal>Session</literal>은 또한 인스턴스가 세션 캐시에 속하는지 여부를 결정하는데 <literal>contains()</literal> + 메소드를 제공한다. + </para> + + <para> + 세션 캐시로부터 모든 객체들을 완전하게 퇴거시키기 위해, <literal>Session.clear()</literal>를 호출하라. + </para> + + <para> + second-level 캐시의 경우, 하나의 인스턴스, 전체 클래스, 콜렉션 인스턴스 또는 전체 콜렉션 role의 캐시된 상태를 퇴거시키는 + <literal>SessionFactory</literal> 상에 정의된 메소드들이 존재한다. + </para> + + <programlisting><![CDATA[sessionFactory.evict(Cat.class, catId); //evict a particular Cat +sessionFactory.evict(Cat.class); //evict all Cats +sessionFactory.evictCollection("Cat.kittens", catId); //evict a particular collection of kittens +sessionFactory.evictCollection("Cat.kittens"); //evict all kitten collections]]></programlisting> + + <para> + <literal>CacheMode</literal>는 특정 세션이 second-level 캐시와 어떻게 상호작용하는지를 제어한다 + </para> + + <itemizedlist> + <listitem> + <para> + <literal>CacheMode.NORMAL</literal> - second-level 캐시로부터 아이템들을 읽어들이고 second-level 캐시로 + 아이템들을 기록한다 + </para> + </listitem> + <listitem> + <para> + <literal>CacheMode.GET</literal> - second-level 캐시로부터 아이템들을 읽어들이지만, 데이터를 업데이트할 때를 제외하면 + second-level 캐시로 기록하지 않는다 + </para> + </listitem> + <listitem> + <para> + <literal>CacheMode.PUT</literal> - 아이템들을 second-level 캐시에 기록하지만, second-level 캐시로부터 읽어들이지 + 않는다 + </para> + </listitem> + <listitem> + <para> + <literal>CacheMode.REFRESH</literal> - 아이템들을 second-level 캐시로기록하지만, second-level 캐시로부터 + 읽어들이지 않고, 데이터베이스로부터 읽어들인 모든 아이템들에 대한 second-level 캐시의 갱신을 강제시켜, + <literal>hibernate.cache.use_minimal_puts</literal>의 효과를 무시한다 + </para> + </listitem> + </itemizedlist> + + <para> + second-level 캐시 또는 질의 캐시 영역의 내용물을 브라우징하려면 <literal>Statistics</literal> API를 사용하라: + </para> + + <programlisting><![CDATA[Map cacheEntries = sessionFactory.getStatistics() + .getSecondLevelCacheStatistics(regionName) + .getEntries();]]></programlisting> + + <para> + 당신은 통계를 이용 가능하게 하고, 선택적으로 Hibernate로 하여금 캐시 엔트리들을 보다 인간에게 이해가능한 형식으로 유지시키도록 + 강제시키는 것이 필요할 것이다: + </para> + + <programlisting><![CDATA[hibernate.generate_statistics true +hibernate.cache.use_structured_entries true]]></programlisting> + + </sect1> + + <sect1 id="performance-querycache" revision="1"> + <title>질의 캐시</title> + + <para> + 질의 결과 셋들이 또한 캐시될 수도 있다. 이것은 동일한 파라미터들을 가지고 자주 실행되는 질의들에만 유용하다. + 질의 캐시를 사용하기 위해 당신은 먼저 그것을 이용 가능하도록 해야 한다: + </para> + + <programlisting><![CDATA[hibernate.cache.use_query_cache true]]></programlisting> + + <para> + 이 설정은 두 개의 새로운 캐시 영역들 - 캐시된 질의 결과 셋들을 보관하는 것 + (<literal>org.hibernate.cache.StandardQueryCache</literal>), 질의 가능한 테이블들에 대한 가장 + 최신 업데이트들에 대한 timestamp들을 보관하는 다른 것 + (<literal>org.hibernate.cache.UpdateTimestampsCache</literal>)-의 생성을 강제한다 . 질의 캐시는 + 결과 셋 내에 실제 엔티티들의 상태를 캐시시키지 않음을 노트하라; 그것은 오직 식별자 값들과 값 타입의 결과들 + 만을 캐시시킨다. 따라서 질의 캐시는 항상 second-level 캐시와 함께 사용되어야 한다. + </para> + + <para> + 대부분의 질의들은 캐싱으로부터 이점이 없기에, 디폴트로 질의들은 캐시되지 않는다. 캐싱을 이용 가능하도록 하려면, + <literal>Query.setCacheable(true)</literal>를 호출하라. 이 호출은 기존 캐시 결과들을 찾는 것을 질의에게 + 허용해주거나 질의가 실행될 때 그것의 결과들을 캐시에 추가하는 것을 허용해준다. + </para> + + <para> + 만일 당신이 질의 캐시 만료 정책들에 대한 세밀한 제어를 필요로 할 경우, 당신은 + <literal>Query.setCacheRegion()</literal>을 호출함으로써 특별한 질의에 대해 명명되니 캐시 영역을 + 지정할 수도 있다. + </para> + + <programlisting><![CDATA[List blogs = sess.createQuery("from Blog blog where blog.blogger = :blogger") + .setEntity("blogger", blogger) + .setMaxResults(15) + .setCacheable(true) + .setCacheRegion("frontpages") + .list();]]></programlisting> + + <para> + 만일 질의가 그것의 질의 캐시 영역의 갱신을 강제시켜야 하는 경우에, 당신은 <literal>Query.setCacheMode(CacheMode.REFRESH)</literal>를 + 호출해야 한다. 이것은 기본 데이터가 별도의 프로세스를 통해 업데이트되었고(예를 들면, Hibernate를 통해 변경되지 않았고) + 특정 질의 결과 셋들을 선택적으로 갱신하는 것을 어플리케이션에게 허용해주는 경우들에서 특별히 유용하다. 이것은 + <literal>SessionFactory.evictQueries()</literal>를 통해 질의 캐시 영역을 퇴거시키는 보다 효과적인 대안이다. + </para> + + </sect1> + + <sect1 id="performance-collections"> + <title>콜렉션 퍼포먼스 이해하기</title> + + <para> + 우리는이미 콜렉션들에 관해 얘기하는데 꽤 많은 시간을 소요했다. 이 절에서 우리는 콜렉션들이 실행 시에 어떻게 행위하는지에 관한 + 한 쌍의 쟁점들을 조명할 것이다. + </para> + + <sect2 id="performance-collections-taxonomy"> + <title>분류</title> + + <para>Hibernate는 세 가지 기본적인 종류의 콜렉션들을 정의한다:</para> + + <itemizedlist> + <listitem> + <para>값들을 가진 콜렉션들</para> + </listitem> + <listitem> + <para>one to many 연관들</para> + </listitem> + <listitem> + <para>many to many 연관들</para> + </listitem> + </itemizedlist> + + <para> + 이 분류는 여러 가지 테이블과 foreign key 관계들을 구별짓지만 우리가 관계형 모형에 대해 알 필요가 있는 모든 것을 우리에게 + 말해주지 않는다. 관계형 구조와 퍼포먼스 특징들을 완전하게 이해하기 위해, 우리는 또한 콜렉션 행들을 업데이트하거나 삭제하기 + 위해 Hibernate에 의해 사용되는 프라이머리 키의 구조를 검토해야 한다. 이것은 다음 분류를 제안한다: + </para> + + <itemizedlist> + <listitem> + <para>인덱싱 된 콜렉션들 </para> + </listitem> + <listitem> + <para>set들</para> + </listitem> + <listitem> + <para>bag들</para> + </listitem> + </itemizedlist> + + <para> + 모든 인덱싱된 콜렉션들(map들, list들, array들)은 <literal>&lt;key&gt;</literal>와 + <literal>&lt;index&gt;</literal> 컬럼들로 이루어진 프라이머리 키를 갖는다. 이 경우에 콜렉션 업데이트들은 대개 + 극히 효율적이다 - Hibernate가 그것을 업데이트나 삭제를 시도할 때 프라이머리 키는 효율적으로 인덱싱될 수 있고 특정 행은 + 효율적으로 위치지워질 수 있다. + </para> + + <para> + Set들은 <literal>&lt;key&gt;</literal>와 요소 컬럼들로 구성된 프라이머리 키를 갖는다. 이것은 몇몇 유형의 콜렉션 요소, + 특히 composite 요소들 또는 대형 텍스트 또는 바이너리 필드들에 대해 덜 효율적일 수 있다; 데이터베이스는 복잡한 프라이머리 + 키를 효율적으로 인덱싱하는 것이 불가능할 수도 있다. 반면에 one to many 또는 many to many 연관들의 경우, 특히 합성 + 식별자들의 경우에는 효율적일 수 있을 것 같다.(부수-노트: 만일 당신이 당신을 위한 <literal>&lt;set&gt;</literal>의 + 프라이머리 키를 실제로 생성시키기 위해 <literal>SchemaExport</literal>를 원한다면 당신은 모든 컬럼들을 + <literal>not-null="true"</literal>로 선언해야 한다.) + </para> + + <para> + <literal>&lt;idbag&gt;</literal> 매핑들은 대용 키를 정의하여서, 그것들은 항상 업데이트에 매우 효율적이다. 사실, + 그것들은 최상의 경우이다. + </para> + + <para> + Bag들은 가장 나쁜 경우이다. 왜냐하면 하나의 bag은 중복 요소 값들을 허용하고 인덱스 컬럼을 갖지 않기 때문에, 프라이머리 키가 + 정의될 수 없다. Hibernate는 중복 행들 사이를 구분 짓는 방법을 갖고 있지 않다. Hibernate는 그것이 변경될 때마다 + (한 개의 DELETE로) 콜렉션을 완전하게 제거하고 다시 생성시킴으로써 이 문제를 해결한다. 이것은 매우 비효율적이다. + </para> + + <para> + one-to-many 연관의 경우, "프라이머리 키"는 데이터베이스 테이블의 물리적인 프라이머리 키가 아닐 수도 있지만- 이 경우에서도 + 위의 분류는 여전히 유용하다. (그것은 여전히 Hibernate가 콜렉션의 개별 행들을 어떻게 "위치지우는"지를 반영한다.) + </para> + + </sect2> + + <sect2 id="performance-collections-mostefficientupdate"> + <title>List, map, idbag, set들은 update에 가장 효율적인 콜렉션들이다</title> + + <para> + 위의 논의에서, 인덱싱된 콜렉션들과 (대개) set들이 요소들을 추가하고, 제거하고 업데이트함에 있어 가장 효율적인 오퍼레이션을 + 허용해준다. + </para> + + <para> + 아마 인덱싱 된 콜렉션들이 many to many 연관들을 위한 또는 값들을 가진 콜렉션들을 위한 set들에 대해 갖고 있는 하나 이상의 + 장점들이 존재한다. <literal>Set</literal>의 구조 때문에, Hibernate는 요소가 "변경"될 때 행을 <literal>UPDATE</literal> + 하지 않는다. <literal>Set</literal>에 대한 변경들은 항상 (개별 행들에 대한) <literal>INSERT</literal>와 + <literal>DELETE</literal>를 통해 동작한다. 다시 이 검토는 one to many 연관들에 적용되지 않는다. + </para> + + <para> + 배열들이 lazy 될 수 없음을 관찰 한 후에, 우리는 list들, map들, 그리고 idbag들이 단독이 아닌 set들을 가진 가장 퍼포먼스가 + 좋은(non-inverse) 콜렉션 타입들임을 결론 지을 것이다. Set들은 Hibernate 어플리케이션들에서 가장 공통된 종류의 콜렉션이 + 될 것이라 예상된다. 이것은 "set" 의미가 관계형 모형에서 가장 고유한 것이기 때문이다. + </para> + + <para> + 하지만, 잘 설계된 Hibernate 도메인 모형들에서, 우리는 대개 대부분의 콜렉션들이 사실 <literal>inverse="true"</literal>를 + 가진 one-to-many 연관들임을 보게 된다. 이들 연관들의 경우, 업데이트는 연관의 many-to-one 엔드에 의해 처리되고, 따라서 + 콜렉션 업데이트 퍼포먼스에 대한 검토들은 단순히 적용되지 않는다. + </para> + + </sect2> + + <sect2 id="performance-collections-mostefficentinverse"> + <title>Bag들과 list들은 가장 효율적인 inverse 콜렉션들이다</title> + + <para> + 단지 당신이 영원히 bag들을 버리기 전에, bag들(과 또한 list들)이 set들보다 훨씬 더 성능이 좋은 특별한 경우들이 존재한다. + <literal>inverse="true"</literal>를 가진 콜렉션들(예를 들어, 표준 양방향 one-to-many 관계 특질)의 경우, 우리는 + bag 요소들을 초기화(페치) 시킬 필요 없이 bag 또는 list에 요소들을 추가시킬 수 있다! 이것은 <literal>Collection.add()</literal> + 또는 <literal>Collection.addAll()</literal>이 (<literal>Set</literal>과는 달리) 항상 bag 또는 + <literal>List</literal>에 대해 true를 반환해야하기 때문이다. 이것은 훨씬 다음 공통적인 코드를 더 빠르게 만들 수 있다. + </para> + + <programlisting><![CDATA[Parent p = (Parent) sess.load(Parent.class, id); +Child c = new Child(); +c.setParent(p); +p.getChildren().add(c); //no need to fetch the collection! +sess.flush();]]></programlisting> + + </sect2> + + <sect2 id="performance-collections-oneshotdelete"> + <title>원 샷 delete</title> + + <para> + 종종 콜렉션 요소들을 하나씩 삭제하는 것은 극히 비효율적일 수 있다! Hibernate는 완전하게 바보가 아니어서, 그것은 새로운 공백의 + 콜렉션의 경우(예를 들어 당신이 <literal>list.clear()</literal>를 호출했을 경우)에 그것을 행하지 않을 것임을 알고 있다. + 이 경우에, Hibernate는 하나의 <literal>DELETE</literal> 명령을 내릴 것이고 우리는 모두 행했다! + </para> + + <para> + 우리가 길이 20인 하나의 콜렉션에 한 개의 요소를 추가하고 그런 다음 두 개의 요소들을 제거한다고 가정하자. Hibernate는 + (콜렉션이 bag가 아닌 한) 한 개의 <literal>INSERT</literal> 문장과 두 개의 <literal>DELETE</literal> 문장을 명령 + 내릴 것이다. 이것은 확실히 마음에 든다. + </para> + + <para> + 하지만, 우리가 두 개의 요소들을 남겨둔채 18 개의 요소들을 제거하고 나서 세 개의 새로운 요소들을 추가한다고 가정하자. + 두 가지 가능한 처리 방법들이 존재한다. + </para> + + <itemizedlist> + <listitem> + <para>하나씩 열 여덟 개의 행들을 삭제한 다음에 세 개의 행들을 삽입시킨다</para> + </listitem> + <listitem> + <para> + (한 개의 SQL <literal>DELETE</literal>로)전체 콜렉션을 삭제하고 모든 다섯개의 현재 요소들을 (하나씩) insert 시킨다 + </para> + </listitem> + </itemizedlist> + + <para> + Hibernate는 두 번째 옵션이 아마 이 경우에 더 빠르다는 점을 알 만큼 충분히 영리하지 않다.(그리고 Hibernate가 그렇게 영리해지는 것을 희망 + 하는 것은 가능하지 않을 것이다; 그런 특징은 데이터베이스 트리거들 등을 혼동스럽게 할 수도 있다.) + </para> + + <para> + 다행히, 당신은 원래의 콜렉션을 폐기시키고(예를 들어 참조 해제하고) 모든 현재 요소들을 가진 새로이 초기화된 콜렉션을 + 반환함으로써 아무때든지 이 특징을 강제시킬 수 있다. 이것은 시간이 흐름에 따라 매우 유용하고 강력해질 수 있다. + </para> + + <para> + 물론 단 한번의 삭제(one-shot-delete)는 <literal>inverse="true"</literal>로 매핑된 콜렉션들에 적용되지 않는다. + </para> + + </sect2> + + </sect1> + + <sect1 id="performance-monitoring" revision="1"> + <title>퍼포먼스 모니터링하기</title> + + <para> + 최적화는 퍼포먼스 관련 숫자들에 대한 모니터링과 접근 없이는 많이 사용되지 않는다. Hibernate는 그것의 내부적인 오퍼레이션들에 대한 + 전체 영역의 특징들을 제공한다. Hibernate에서 Statistics는 <literal>SessionFactory</literal>에 대해 이용 가능하다. + </para> + + <sect2 id="performance-monitoring-sf" revision="2"> + <title>SessionFactory 모니터링 하기</title> + + <para> + 당신은 두 가지 방법들로 <literal>SessionFactory</literal> metrics에 접근할 수 있다. 당신의 첫 번째 옵션은 + <literal>sessionFactory.getStatistics()</literal>를 호출하고 당신 스스로 <literal>Statistics</literal>를 + 읽거나 디스플레이 하는 것이다. + </para> + + <para> + 만일 당신이 <literal>StatisticsService</literal> MBean을 이용 가능하도록 할 경우 Hibernate는 또한 metrics를 + 발표하는데 JMX를 사용할 수 있다. 당신은 모든 당신의<literal>SessionFactory</literal>에 대해 한 개의 MBean 또는 + 팩토리 당 한 개를 이용 가능하게 할 수 있다. 최소한의 구성 예제들은 다음 코드를 보라: + </para> + + <programlisting><![CDATA[// MBean service registration for a specific SessionFactory +Hashtable tb = new Hashtable(); +tb.put("type", "statistics"); +tb.put("sessionFactory", "myFinancialApp"); +ObjectName on = new ObjectName("hibernate", tb); // MBean object name + +StatisticsService stats = new StatisticsService(); // MBean implementation +stats.setSessionFactory(sessionFactory); // Bind the stats to a SessionFactory +server.registerMBean(stats, on); // Register the Mbean on the server]]></programlisting> + + +<programlisting><![CDATA[// MBean service registration for all SessionFactory's +Hashtable tb = new Hashtable(); +tb.put("type", "statistics"); +tb.put("sessionFactory", "all"); +ObjectName on = new ObjectName("hibernate", tb); // MBean object name + +StatisticsService stats = new StatisticsService(); // MBean implementation +server.registerMBean(stats, on); // Register the MBean on the server]]></programlisting> + + <para> + TODO: 이것은 의미가 없다: 첫번째 경우에, 우리는 직접 MBean을 검색하고 사용한다. + 두 번째 경우에 우리는 JNDI 이름을 사용하기 전에 세션 팩토리가 보관하고 있는 JNDI 이름을 부여해야 한다. + <literal>hibernateStatsBean.setSessionFactoryJNDIName("my/JNDI/Name")</literal>을 사용하라. + </para> + <para> + 당신은 <literal>SessionFactory</literal>에 대한 모니터링을 (비)활성화 시킬 수 있다 + </para> + <itemizedlist> + <listitem> + <para> + 구성 시 : <literal>hibernate.generate_statistics</literal>, 디폴트는 <literal>false</literal> + </para> + </listitem> + </itemizedlist> + <itemizedlist> + <listitem> + <para> + 실행 시 : <literal>sf.getStatistics().setStatisticsEnabled(true)</literal> 또는 + <literal>hibernateStatsBean.setStatisticsEnabled(true)</literal> + </para> + </listitem> + </itemizedlist> + + <para> + Statistics(통계량들)은 <literal>clear()</literal> 메소드를 사용하여 프로그래밍 방식으로 재설정 될 수 있다. 요약은 + <literal>logSummary()</literal> 메소드를 사용하여 logger(info 레벨)에게 전송될 수 있다. + </para> + + </sect2> + + <sect2 id="performance-monitoring-metrics" revision="1"> + <title>Metrics</title> + + <para> + Hibernate는 매우 기본적인 것에서부터 어떤 시나리오들에만 관련된 전문 정보에 이르는 많은 metrics를 제공한다. + 모든 이용 가능한 카운터들은 <literal>Statistics</literal> interface API에서 3개의 카테고리로 설명되어 있다: + </para> + <itemizedlist> + <listitem> + <para> + 열려진 세션들의 개수, 검색된 JDBC 커넥션들의 개수 등과 같은 일반적인 <literal>Session</literal> 사용에 + 관련된 metrics. + </para> + </listitem> + <listitem> + <para> + 전체적으로 엔티티들, 콜렉션들, 질의들, 그리고 캐시들에 관련된 metrics(전역 metrics로 알려져 있음), + </para> + </listitem> + <listitem> + <para> + 특정한 엔티티, 콜렉션, 질의 또는 캐시 영역에 관련된 상세 metrics. + </para> + </listitem> + </itemizedlist> + + <para> + 예를 들어 당신은 엔티티, 콜렉션, 질의들의 캐시 성공율 및 실패율, put(역자 주, 캐시 시도, putt) 비율, 콜렉션들과 질의들, + 그리고 평균 질의 요구 시간 등을 찾을 수 있다. 수 밀리초들가 자바에서 근사치에 종속됨을 의식하라. Hibernate는 JVM 정밀도에 + 묶여 있고, 몇몇 플랫폼들에서 이것은 심지어 약 10초가 될 수도 있다. + </para> + + <para> + 간단한 getter들은 (예를 들어 특정 엔티티, 콜렉션, 캐시 영역에 묶이지 않은) 전역 metrics에 접근하는데 사용된다. 당신은 + 그것(특정 엔티티, 콜렉션, 또는 캐시 영역)의 이름을 통해, 그리고 질의들에 대한 그것의 HQL 또는 SQL 표현을 통해 특정 엔티티, + 콜렉션, 또는 캐시 영역의 metrics에 접근할수 있다. 추가 정보는 <literal>Statistics</literal>, <literal>EntityStatistics</literal>, + <literal>CollectionStatistics</literal>, <literal>SecondLevelCacheStatistics</literal>, 그리고 + <literal>QueryStatistics</literal>를 참조하라. 다음 코드는 간단한 예제를 보여준다: + </para> + + <programlisting><![CDATA[Statistics stats = HibernateUtil.sessionFactory.getStatistics(); + +double queryCacheHitCount = stats.getQueryCacheHitCount(); +double queryCacheMissCount = stats.getQueryCacheMissCount(); +double queryCacheHitRatio = + queryCacheHitCount / (queryCacheHitCount + queryCacheMissCount); + +log.info("Query Hit ratio:" + queryCacheHitRatio); + +EntityStatistics entityStats = + stats.getEntityStatistics( Cat.class.getName() ); +long changes = + entityStats.getInsertCount() + + entityStats.getUpdateCount() + + entityStats.getDeleteCount(); +log.info(Cat.class.getName() + " changed " + changes + "times" );]]></programlisting> + + <para> + 모든 엔티티들, 콜렉션들, 콜렉션들,질의들 그리고 영역 캐시들에 대해 작업하기 위해, 당신은 다음 메소드들로서 엔티티들, + 콜렉션들, 질의들, 그리고 영역 캐시들에 대한 이름들의 목록을 검색할 수 있다: <literal>getQueries()</literal>, + <literal>getEntityNames()</literal>, <literal>getCollectionRoleNames()</literal>, 그리고 + <literal>getSecondLevelCacheRegionNames()</literal>. + </para> + + </sect2> + + </sect1> + +</chapter> \ No newline at end of file Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/persistent_classes.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/persistent_classes.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/persistent_classes.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/persistent_classes.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,502 @@ +<chapter id="persistent-classes" revision="2"> + <title>영속 클래스들</title> + + <para> + 영속 클래스들은 비지니스 문제의 엔티티들(예를 들어 E-Commerce 어플리케이션에서 고객이나 주문)을 구현하는 + 어플리케이션 내의 클래스들이다. 영속 클래스들의 인스턴스들은 영속 상태에 있는 것으로 전혀 간주되지 않는다 - + 대신에 하나의 인스턴스는 transient 또는 detached 상태일 수 있다. + </para> + + <para> + Hibernate는 이들 클래스들이 Plain Old Java Object (POJO) 프로그래밍 모형으로서 알려진, 몇몇 간단한 + 규칙들을 따를 경우에 가장 잘 동작한다. 하지만 이들 규칙들 중 어떤 것도 어려운 사양들이 아니다. 진정 Hibernate3는 + 당신의 영속 객체들의 특징에 대해 매우 적은 것을 가정한다. 당신은 다른 방법들로 도메인 모형을 표현할 수 있다 : + 예를 들어 <literal>Map</literal> 인스턴스의 트리들을 사용하기. + </para> + + <sect1 id="persistent-classes-pojo"> + <title>간단한 POJO 예제</title> + + <para> + 대부분의 자바 어플리케이션들은 고양이과들을 표현하는 영속 클래스를 필요로 한다. + </para> + + <programlisting><![CDATA[package eg; +import java.util.Set; +import java.util.Date; + +public class Cat { + private Long id; // identifier + + private Date birthdate; + private Color color; + private char sex; + private float weight; + private int litterId; + + private Cat mother; + private Set kittens = new HashSet(); + + private void setId(Long id) { + this.id=id; + } + public Long getId() { + return id; + } + + void setBirthdate(Date date) { + birthdate = date; + } + public Date getBirthdate() { + return birthdate; + } + + void setWeight(float weight) { + this.weight = weight; + } + public float getWeight() { + return weight; + } + + public Color getColor() { + return color; + } + void setColor(Color color) { + this.color = color; + } + + void setSex(char sex) { + this.sex=sex; + } + public char getSex() { + return sex; + } + + void setLitterId(int id) { + this.litterId = id; + } + public int getLitterId() { + return litterId; + } + + void setMother(Cat mother) { + this.mother = mother; + } + public Cat getMother() { + return mother; + } + void setKittens(Set kittens) { + this.kittens = kittens; + } + public Set getKittens() { + return kittens; + } + + // addKitten not needed by Hibernate + public void addKitten(Cat kitten) { + kitten.setMother(this); + kitten.setLitterId( kittens.size() ); + kittens.add(kitten); + } +}]]></programlisting> + + <para> + 준수할 네 개의 주요 규칙들이 다음에 있다: + </para> + + + <sect2 id="persistent-classes-pojo-constructor" revision="1"> + <title>아규먼트 없는 생성자를 구현하라 </title> + + <para> + <literal>Cat</literal>은 아규먼트 없는 생성자를 갖는다. 모든 영속 클래스들은 Hibernate는 + <literal>Constructor.newInstance()</literal>를 사용하여 그것들을 초기화 시킬 수 있도록 디폴트 생성자 + (public이 아닐 수 있다)를 가져야 한다. 우리는 Hibernate 내에서 런타임 프락시 생성을 위한 최소한의 + <emphasis>패키지</emphasis> 가시성(visibility)를 가진 디폴트 생성자를 가질 것을 강력하게 권장한다. + </para> + </sect2> + + <sect2 id="persistent-classes-pojo-identifier" revision="2"> + <title>identifier 프로퍼티를 제공하라(옵션)</title> + + <para> + <literal>Cat</literal>은 <literal>id</literal>로 명명된 하나의 프로퍼티를 갖는다. 이 프로퍼티는 + 데이터베이스 테이블의 프라이머리 키 컬럼으로 매핑된다. 이 프로퍼티는 어떤 것으로 명명될 수도 있고, 그것의 타입은 + 임의의 원시 타입, 원시 "wrapper" 타입, <literal>java.lang.String</literal> 또는 <literal>java.util.Date</literal>일 + 수 있다. (만일 당신의 리거시 데이터베이스 테이블이 composite 키들을 갖고 있다면, 당신은 이들 타입들을 가진 + 사용자 정의 클래스를 사용할 수도 있다 - 나중에 composite 식별자들에 대한 절을 보라) + </para> + + <para> + identifier 프로퍼티는 엄격하게 옵션이다. 당신은 그것을 생략할 수도 있고, Hibernate로 하여금 내부적으로 + 객체 식별자들을 추적하도록 할 수 있다. 하지만 우리는 이것을 권장하지 않는다. + </para> + + <para> + 사실, 어떤 기능은 identifier 프로퍼티를 선언하는 클래스들에 대해서만 이용 가능하다: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + detached 객체들에 대한 Transitive reattachment(cascade update 또는 cascade merge) + - <xref linkend="objectstate-transitive"/> + </para> + </listitem> + <listitem> + <para> + <literal>Session.saveOrUpdate()</literal> + </para> + </listitem> + <listitem> + <para> + <literal>Session.merge()</literal> + </para> + <para> + 를 보라 + </para> + </listitem> + </itemizedlist> + + <para> + 우리는 당신이 영속 클래스들에 대해 일관되게 명명된 identifier 프로퍼티들을 선언할 것을 권장한다. 게다가 우리는 + 당신이 nullable 타입(예를 들어 non-primitive)을 사용할 것을 권장한다. + </para> + </sect2> + + <sect2 id="persistent-classes-pojo-final"> + <title>final이 아닌 클래스들을 선호하라(옵션)</title> + <para> + Hibernate의 중심 특징인, 프락시(<emphasis>proxies</emphasis>)들은 final이 아닌 영속 클래스들 또는 모두 + public 메소드들로 선언된 인터페이스의 구현인 영속 클래스들에 의존한다. + </para> + <para> + 당신은 Hibernate로 인터페이스를 구현하지 않은 <literal>final</literal> 클래스들을 영속화 시킬 수 있지만 + 당신은 lazy 연관 페칭(lazy association fetching)에 대해 프락시들을 사용할 수 없을 것이다 -그것은 퍼포먼스 + 튜닝을 위한 당신의 옵션들을 제한시킬 것이다. + </para> + <para> + 당신은 또한 non-final 클래스들 상에 <literal>public final</literal> 메소드들을 선언하는 것을 피해야 한다. + 만일 당신이 <literal>public final</literal> 메소드를 가진 클래스를 사용하고자 원할 경우, 당신은 + <literal>lazy="false"</literal>를 설정함으로써 명시적으로 프락싱을 사용 불가능하도록 해야 한다. + </para> + </sect2> + + <sect2 id="persistent-classes-pojo-accessors" revision="2"> + <title>영속 필드들을 위한 accessor들과 mutator들을 선언하라(옵션)</title> + + <para> + <literal>Cat</literal>은 그것의 모든 영속 필드들에 대해 accessor 메소드들을 선언한다. 많은 다른 ORM 도구들은 + 인스턴스 변수들을 직접 영속화 시킨다. 우리는 관계형 스키마와 클래스의 내부적인 데이터 구조들 사이에 간접적인 수단을 + 제공하는 것이 더 좋다고 믿고 있다. 디폴트로 Hibernate는 자바빈즈 스타일 프로퍼티들을 영속화 시키고, <literal>getFoo</literal>, + <literal>isFoo</literal>와 <literal>setFoo</literal> 형식의 메소드 이름들을 인지한다. 당신은 진정으로 + 특정 프로퍼티에 대한 직접적인 필드 접근으로 전환할 수도 있다. + </para> + + <para> + 프로퍼티들은 public으로 선언될 필요가 <emphasis>없다</emphasis> - Hibernate는 디폴트로 + <literal>protected</literal> get/set 쌍 또는 <literal>private</literal> get/set + 쌍을 가진 프로퍼티를 영속화 시킬 수 있다. + </para> + + </sect2> + + </sect1> + + <sect1 id="persistent-classes-inheritance"> + <title>상속 구현하기</title> + + <para> + 서브클래스는 또한 첫 번째 규칙들과 두 번째 규칙들을 주시해야 한다. 그것은 슈퍼클래스 <literal>Cat</literal>으로부터 + 그것의 identifier 프로퍼티를 상속받는다. + </para> + + <programlisting><![CDATA[package eg; + +public class DomesticCat extends Cat { + private String name; + + public String getName() { + return name; + } + protected void setName(String name) { + this.name=name; + } +}]]></programlisting> + </sect1> + + <sect1 id="persistent-classes-equalshashcode" revision="1"> + <title><literal>equals()</literal>와 <literal>hashCode()</literal> 구현하기</title> + + <para> + 만일 당신이 다음의 경우라면, 당신은 <literal>equals()</literal>와 <literal>hashCode()</literal> + 메소드들을 오버라이드 시켜야 한다. + </para> + <itemizedlist spacing="compact"> + <listitem> + <para> + 하나의 <literal>Set</literal> 속에 영속 클래스들의 인스턴스들을 집어넣고자 의도하고 + (many-valued 연관들에 대해 권장되는 방법) + <emphasis>그리고</emphasis> + </para> + </listitem> + <listitem> + <para> + detached 인스턴스들의 reattachment(재첨부)를 사용하고자 의도하는 + </para> + </listitem> + </itemizedlist> + + <para> + Hibernate는 특정 session 범위 내에서만 persistent identity(데이터베이스 행)과 Java identity의 같음을 보장한다. + 따라서 우리가 다른 세션들에서 검색된 인스턴스들을 혼합시키자마자, 우리가 <literal>Set</literal>들에 대해 유의미하게 + 만들고자 원할 경우, 우리는 <literal>equals()</literal>와 <literal>hashCode()</literal>를 구현해야 한다. + </para> + + <para> + 가장 명백한 방법은 두 객체들의 identifier 값을 비교함으로써 <literal>equals()</literal>/<literal>hashCode()</literal>를 + 구현하는 것이다. 만일 그 값이 동일하다면, 둘다 동일한 데이터베이스 행이어야 하고, 그러므로 그것들은 같다(둘다 하나의 + <literal>Set</literal>에 추가되는 경우에, 우리는 <literal>Set</literal> 속에서 하나의 요소만을 갖게 될 것이다). + 불행하게도, 우리는 생성되는 식별자들을 갖는 그 접근법을 사용할 수 없다! Hibernate는 오직 식별자 값들을 영속화 되는 객체들에 + 할당할 것이고, 새로이 생성된 인스턴스는 임의의 identifier 값을 갖지 않을 것이다! 만일 인스턴스가 저장되지 않고 현재 하나의 + <literal>Set</literal> 속에 있을 경우에, 그것을 저장하는것은 하나의 식별자 값을 그 객체에게 할당할 것이다. 만일 + <literal>equals()</literal>와 <literal>hashCode()</literal>가 그 식별자 값에 기초할 경우, hash 코드는 + <literal>Set</literal>의 계약을 파기하여 변경될 것이다. 이 문제에 대한 전체 논의에 대해서는 Hibernate 웹 사이트를 보라. + 이것은 Hibernate 쟁점이 아닌, 객체 identity와 equality에 관한 통상의 자바 의미론임을 노트하라. + </para> + + <para> + 우리는 <emphasis>Business key equality</emphasis>를 사용하여 <literal>equals()</literal>와 <literal>hashCode()</literal>를 + 구현할 것 권장한다. Business key equality는 <literal>equals()</literal> 메소드가 비지니스 키, 즉 실세계에서 우리의 인스턴스를 + 식별하게 될 키(<emphasis>natural</emphasis> 후보 키)를 형성하는 프로퍼티들만을 비교한다는 점을 의미한다 : + </para> + + <programlisting><![CDATA[public class Cat { + + ... + public boolean equals(Object other) { + if (this == other) return true; + if ( !(other instanceof Cat) ) return false; + + final Cat cat = (Cat) other; + + if ( !cat.getLitterId().equals( getLitterId() ) ) return false; + if ( !cat.getMother().equals( getMother() ) ) return false; + + return true; + } + + public int hashCode() { + int result; + result = getMother().hashCode(); + result = 29 * result + getLitterId(); + return result; + } + +}]]></programlisting> + + <para> + 하나의 비지니스 키는 데이터베이스 프라이머리 키 후보 만큼 견고하지 않아야 한다(<xref linkend="transactions-basics-identity"/>를 보라). + 대개 변경할 수 없는 프로퍼티 또는 유일한(unique) 프로퍼티는 대개 비지니스 키에 대한 좋은 후보들이다. + </para> + + </sect1> + + <sect1 id="persistent-classes-dynamicmodels"> + <title>동적인 모형들</title> + + <para> + <emphasis>다음 특징들은 현재 실험적으로 고려되고 있으며 장래에는 변경될 수 있음을 노트하라.</emphasis> + </para> + + <para> + 영속 엔티티들은 반드시 실행시에 POJO 클래스들로 또는 자바빈즈 객체들로 표현되어야할 필요는 없다. Hibernate는 + 또한 (실행 시에 <literal>Map</literal>들을 가진 <literal>Map</literal>들을 사용하여) 동적인 모형들을 지원하고 + DOM4J 트리들로서 엔티티들에 대한 표현을 지원한다. 이 접근법으로, 당신은 영속 클래스들을 작성하지 않고, 오직 매핑 파일들 + 만을 작성한다. + </para> + + <para> + 디폴트로, Hibernate는 통산의 POJO 모드로 동작한다. 당신은 <literal>default_entity_mode</literal> 구성 옵션을 + 사용하여 특별한 <literal>SessionFactory</literal>에 대해 디폴트 엔티티 표현 모드를 설정할 수 있다 + (<xref linkend="configuration-optional-properties"/>을 보라). + </para> + + <para> + 다음 예제들은<literal>Map</literal>들을 사용하는 표현을 설명한다. 먼저 매핑 파일에서, <literal>entity-name</literal>은 + 클래스 이름 대신에(또는 클래스 이름에 덧붙여) 선언되어야 한다: + </para> + + <programlisting><![CDATA[<hibernate-mapping> + + <class entity-name="Customer"> + + <id name="id" + type="long" + column="ID"> + <generator class="sequence"/> + </id> + + <property name="name" + column="NAME" + type="string"/> + + <property name="address" + column="ADDRESS" + type="string"/> + + <many-to-one name="organization" + column="ORGANIZATION_ID" + class="Organization"/> + + <bag name="orders" + inverse="true" + lazy="false" + cascade="all"> + <key column="CUSTOMER_ID"/> + <one-to-many class="Order"/> + </bag> + + </class> + +</hibernate-mapping>]]></programlisting> + + <para> + 심지어 비록 연관들이 대상(target) 클래스 이름들을 사용하여 선언될지라도, 연관들의 대상(target) 타입은 또한 POJO가 아닌 + 동적인 엔티티일 수 있음을 노트하라. + </para> + + <para> + <literal>SessionFactory</literal>에 대한 디폴트 엔티티 모드를 <literal>dynamic-map</literal>으로 설정한 후에, + 우리는 <literal>Map</literal>들을 가진 <literal>Map</literal>들에 대해 실행 시에 작업할 수 있다: + </para> + + <programlisting><![CDATA[Session s = openSession(); +Transaction tx = s.beginTransaction(); +Session s = openSession(); + +// Create a customer +Map david = new HashMap(); +david.put("name", "David"); + +// Create an organization +Map foobar = new HashMap(); +foobar.put("name", "Foobar Inc."); + +// Link both +david.put("organization", foobar); + +// Save both +s.save("Customer", david); +s.save("Organization", foobar); + +tx.commit(); +s.close();]]></programlisting> + + <para> + dynamic 매핑의 장점들은 엔티티 클래스 구현에 대한 필요 없이도 프로토타이핑을 위한 빠른 전환 시간이다. 하지만 당신은 + 컴파일 시 타입 체킹을 잃고 실행 시에 많은 예외상황들을 다루게 될 것이다. Hibernate 매핑 덕분에, + 나중에 고유한 도메인 모형 구현을 상단에 추가하는 것이 허용되어서, 데이터베이스 스키마가 쉽게 정규화 되고 소리가 울려 퍼질 수 있다. + </para> + + <para> + 엔티티 표현 모드들은 또한 하나의 단위 <literal>Session</literal> 기준에 대해 설정될 수 있다: + </para> + + <programlisting><![CDATA[Session dynamicSession = pojoSession.getSession(EntityMode.MAP); + +// Create a customer +Map david = new HashMap(); +david.put("name", "David"); +dynamicSession.save("Customer", david); +... +dynamicSession.flush(); +dynamicSession.close() +... +// Continue on pojoSession +]]></programlisting> + + + <para> + <literal>EntityMode</literal>를 사용하는 <literal>getSession()</literal>에 대한 호출은 + <literal>SessionFactory</literal>가 아닌, <literal>Session</literal> API에 대한 것임을 노트하길 바란다. + 그 방법으로, 새로운 <literal>Session</literal>은 기본 JDBC 커넥션, 트랜잭션, 그리고 다른 컨텍스트 정보를 공유한다. + 이것은 당신이 두 번째 <literal>Session</literal> 상에서 <literal>flush()</literal>와 <literal>close()</literal>를 + 호출하지 말아야 하고, 또한 트랜잭션 및 커넥션 핸들링을 주된 작업 단위에게 맡긴다는 점을 의미한다. + </para> + + <para> + XML 표현 가용성들에 대한 추가 정보는 <xref linkend="xml"/>에서 찾을 수 있다. + </para> + + </sect1> + + <sect1 id="persistent-classes-tuplizers" revision="1"> + <title>Tuplizer들</title> + + <para> + <literal>org.hibernate.tuple.Tuplizer</literal>, 그리고 그것의 서브-인터페이스들은 데이터의 조각에 대한 + 특별한 표현의 <literal>org.hibernate.EntityMode</literal>가 주어지면 그 표현을 관리하는 책임이 있다. 만일 + 주어진 데이터 조각이 하나의 데이터 구조로 간주될 경우, 그때 하나의 tuplizer는 그런 데이터 구조를 생성시키는 방법과 + 그런 데이터 구조로부터 값들을 추출시키는 방법 그리고 그런 데이터구조 속으로 값들을 삽입시키는 방법을 알고 있는 것이다. + 예를 들어, POJO 엔티티 모드의 경우, 대응하는 tuplizer는 그것의 생성자를 통해 POJO를 생성시키는 방법, 그리고 정의된 + 프로퍼티 접근자들을 사용하여 POJO 프로퍼티들에 접근하는 방법을 안다. + <literal>org.hibernate.tuple.entity.EntityTuplizer</literal> 인터페이스와 + <literal>org.hibernate.tuple.component.ComponentTuplizer</literal> 인터페이스에 의해 표현되는 두 가지 고급 유형의 + Tuplizer들이 존재한다. <literal>EntityTuplizer</literal>들은 엔티티들에 관해서는 위에 언급된 계약들을 매핑할 + 책임이 있는 반면에, <literal>ComponentTuplizer</literal>들은 컴포넌트들에 대해서도 동일한 것을 행한다. + </para> + + <para> + 사용자들은 또한 그들 자신의 tuplizer들을 플러그 시킬 수 있다. 아마 당신은 dynamic-map entity-mode 동안에 사용되는 + <literal>java.util.HashMap</literal> 대신에 하나의 <literal>java.util.Map</literal> 구현을 필요로 한다; + 또는 아마 당신은 디폴트로 사용되는 방도 보다는 하나의 다른 다른 프릭시 산출 방도를 필요로 한다. 둘다 하나의 맞춤형 tuplizer를 + 정의함으로써 성취될 것이다. Tuplizer들 정의들은 그것들이 관리할 수단인 엔티티 매핑 또는 컴포넌트 매핑에 첨부된다. 우리의 + 고객 엔티티에 대한 예제로 되돌아가면: + </para> + + <programlisting><![CDATA[<hibernate-mapping> + <class entity-name="Customer"> + <!-- + Override the dynamic-map entity-mode + tuplizer for the customer entity + --> + <tuplizer entity-mode="dynamic-map" + class="CustomMapTuplizerImpl"/> + + <id name="id" type="long" column="ID"> + <generator class="sequence"/> + </id> + + <!-- other properties --> + ... + </class> +</hibernate-mapping> + + +public class CustomMapTuplizerImpl + extends org.hibernate.tuple.entity.DynamicMapEntityTuplizer { + // override the buildInstantiator() method to plug in our custom map... + protected final Instantiator buildInstantiator( + org.hibernate.mapping.PersistentClass mappingInfo) { + return new CustomMapInstantiator( mappingInfo ); + } + + private static final class CustomMapInstantiator + extends org.hibernate.tuple.DynamicMapInstantitor { + // override the generateMap() method to return our custom map... + protected final Map generateMap() { + return new CustomMap(); + } + } +}]]></programlisting> + + + </sect1> + + <para> + TODO: property 패키지와 proxy 패키지 내에 user-extension 프레임웍을 문서화 할 것. + </para> + +</chapter> + Added: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/preface.xml =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/preface.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/preface.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,110 @@ +<?xml version='1.0' encoding="UTF-8"?> + +<!DOCTYPE preface PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> + +<preface id="preface" revision="2"> + <title>머리말</title> + + <para> + 객체 지향 소프트웨어와 관계형 데이터베이스로 작업하는 것은 오늘날의 엔터프라이즈 환경들에서 성가시고 시간이 + 소비될 수 있다. Hibernate는 자바 환경들을 위한 객체/관계형 매핑 도구이다. + object/relational mapping(ORM) 용어는 객체 모형으로부터 SQL-기반의 스키마를 가진 + 관계형 데이터 모형으로의 데이터 표상을 매핑하는 기술을 언급한다. + </para> + + <para> + Hibernate는 자바 클래스들로부터 데이터베이스로의 매핑(그리고 자바 데이터 타입들로부터 SQL 데이터 + 타입들로의 매핑)을 처리할 뿐만 아니라, 또한 데이터 질의와 검색 편의들을 제공하며, SQL과 JDBC로 + 수작업 데이터 핸들링에 소요되는 개발 시간을 현저하게 단축시켜줄 수 있다. + </para> + + <para> + Hibernate의 목적은 공통된 데이터 영속화 관련 프로그래밍 작업들의 95%를 덜어주는 것이다. + Hibernate는 데이터베이스에서 비지니스 로직을 구현하는데 내장 프로시저들을 전용으로 사용하는 데이터 + 중심적 어플리케이션에 대한 최상의 솔루션이 아닐 수도 있지만, 그것은 자바 기반 미들-티어에서 객체 지향 + 도메인 모형들과 비지니스 로직에 가장 유용하다. 하지만 Hibernate는 벤더 지정적인 SQL 코드를 + 제거하거나 캡슐화 시키는 당신을 확실히 도와줄 수 있고 테이블 형식의 표현으로부터 객체들의 그래프로 결과 + 셋을 변환하는 공통된 태스크를 도와줄 것이다. + </para> + + <para> + 만일 당신이 Hibernate와 Object/Relational 매핑 또는 심지어 자바에 초심자라면, 다음 + 단계들을 따르기 바란다: + </para> + + <orderedlist> + <listitem> + <para> + 더 많은 단계적인 사용 설명서들을 가진 더 긴 튜토리얼은 + <xref linkend="tutorial"/> + 을 읽어라. 튜토리얼을 위한 소스 코드는 <literal>doc/reference/tutorial/</literal> + 디렉토리에 포함되어 있다. + </para> + </listitem> + <listitem> + <para> + Hibernate가 사용될 수 있는 환경을 이해려면 + <xref linkend="architecture" /> + 를 읽어라. + </para> + </listitem> + <listitem> + <para> + Hibernate 배포본 내의 + <literal>eg/</literal> + 디렉토리를 살펴 보라. 이 디렉토리는 간단한 스탠드얼론 어플리케이션을 포함하고 있다. 당신의 + JDBC 드라이버를 + <literal>lib/</literal> + 디렉토리에 복사하고 당신의 데이터베이스에 맞는 정확한 값을 지정하여 + <literal>etc/hibernate.properties</literal> + 를 편집하라. 배보본 디렉토리에서 명령 라인 프롬프트에서 (Ant를 사용하여) + <literal>ant eg</literal> + 를 타이핑 하거나 , Windows 하에서 + <literal>build eg</literal> + 를 타이프 하라. + </para> + </listitem> + <listitem> + <para> + 당신의 주된 정보의 소스로서 이 참조 문서를 사용하라. 만일 어플리케이션 설계에 대해 더 많은 + 도움을 필요로 하거나 당신이 단계적인 튜토리얼을 선호한다면 + <emphasis>Java Persistence with Hibernate</emphasis> + (http://www.manning.com/bauer2)을 읽는 것을 고려하라.또한 + http://caveatemptor.hibernate.org에 방문하여 Java Persistence + with Hibernate용 예제 어플리케이션을 다운로드 하라. + </para> + </listitem> + <listitem> + <para> + FAQ들은 Hibernate 웹 사이트 상에 답변되어 있다. + </para> + </listitem> + <listitem> + <para> + 제 3의 데모들, 예제들, 그리고 튜토리얼들은 Hibernate 웹 사이트 상에 링크되어 + 있다. + </para> + </listitem> + <listitem> + <para> + Hibernate 웹사이트 상의 공동체 영역은 설계 패턴과 다양한 통합 솔루션들(Tomcat, + JBoss AS, Struts, EJB 등.)에 관한 좋은 리소스이다. + </para> + </listitem> + </orderedlist> + + <para> + 질문이 있다면, Hibernate 상에 링크되어 있는 사용자 포럼을 사용하라. 우리는 또한 버그 보고와 특징 + 요청들을 위한 JIRA 쟁점 추적 시스템을 제공한다. 당신이 Hibernate의 개발에 관심이 있다면, + 개발자 메일링 리스트에 참여하라. 만일 당신이 이 문서를 당신의 언어로 번역하는 것에 관심이 있다면, 개발자 + 메일링 리스트에 접촉하라. + </para> + + <para> + Hibernate를 위한 상용 개발 지원, 제품 지원, 그리고 교육은 JBoss Inc를 통해 이용 가능하다 + (http://www.hibernate.org/SupportTraining/를 보라). Hibernate는 + JBoss Professional Open Source product 프로젝트이고 제품들에 대한 JBoss + Enterprise Middleware System (JEMS) suite의 중대한 컴포넌트이다. + </para> + +</preface> \ No newline at end of file Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/query_criteria.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/query_criteria.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/query_criteria.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/query_criteria.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,418 @@ +<chapter id="querycriteria"> + <title>Criteria 질의들</title> + + <para> + Hibernate는 직관적인, 확장 가능한 criteria query API를 특징 짓는다. + </para> + + <sect1 id="querycriteria-creating"> + <title><literal>Criteria</literal> 인스턴스 생성하기</title> + + <para> + <literal>org.hibernate.Criteria</literal>인터페이스는 특정 영속 클래스에 대한 질의를 표현한다. + <literal>Session</literal>은 <literal>Criteria</literal> 인스턴스들에 대한 팩토리이다. + </para> + + <programlisting><![CDATA[Criteria crit = sess.createCriteria(Cat.class); +crit.setMaxResults(50); +List cats = crit.list();]]></programlisting> + + </sect1> + + <sect1 id="querycriteria-narrowing"> + <title>결과 셋 제한하기</title> + + <para> + 개별적인 질의 기준은 <literal>org.hibernate.criterion.Criterion</literal> 인터페이스의 인스턴스이다. + <literal>org.hibernate.criterion.Restrictions</literal> 클래스는 어떤 미리 만들어진 <literal>Criterion</literal> + 타입들을 얻는 팩토리 메소드들을 정의한다. + </para> + + <programlisting><![CDATA[List cats = sess.createCriteria(Cat.class) + .add( Restrictions.like("name", "Fritz%") ) + .add( Restrictions.between("weight", minWeight, maxWeight) ) + .list();]]></programlisting> + + <para> + 제한들은 논리적으로 그룹지워질 수도 있다. + </para> + + <programlisting><![CDATA[List cats = sess.createCriteria(Cat.class) + .add( Restrictions.like("name", "Fritz%") ) + .add( Restrictions.or( + Restrictions.eq( "age", new Integer(0) ), + Restrictions.isNull("age") + ) ) + .list();]]></programlisting> + + <programlisting><![CDATA[List cats = sess.createCriteria(Cat.class) + .add( Restrictions.in( "name", new String[] { "Fritz", "Izi", "Pk" } ) ) + .add( Restrictions.disjunction() + .add( Restrictions.isNull("age") ) + .add( Restrictions.eq("age", new Integer(0) ) ) + .add( Restrictions.eq("age", new Integer(1) ) ) + .add( Restrictions.eq("age", new Integer(2) ) ) + ) ) + .list();]]></programlisting> + + <para> + 미리 만들어진 criterion 타입들(<literal>Restrictions</literal> 서브클래스들)의 영역이 꽤 존재하지만, 특히 유용한 것은 + 당신으로 하여금 SQL을 직접 지정하도록 해준다. + </para> + + <programlisting><![CDATA[List cats = sess.createCriteria(Cat.class) + .add( Restrictions.sqlRestriction("lower({alias}.name) like lower(?)", "Fritz%", Hibernate.STRING) ) + .list();]]></programlisting> + + <para> + 질의된 엔티티의 행 alias에 의해 대체된 <literal>{alias}</literal> placeholder. + </para> + + <para> + criterion을 얻는 대안적인 접근법은 <literal>Property</literal> 인스턴스로부터 그것을 얻는 것이다. 당신은 + <literal>Property.forName()</literal>을 호출하여 <literal>Property</literal>를 생성시킬 수 있다. + </para> + + <programlisting><![CDATA[ +Property age = Property.forName("age"); +List cats = sess.createCriteria(Cat.class) + .add( Restrictions.disjunction() + .add( age.isNull() ) + .add( age.eq( new Integer(0) ) ) + .add( age.eq( new Integer(1) ) ) + .add( age.eq( new Integer(2) ) ) + ) ) + .add( Property.forName("name").in( new String[] { "Fritz", "Izi", "Pk" } ) ) + .list();]]></programlisting> + + </sect1> + + <sect1 id="querycriteria-ordering"> + <title>결과들을 순서지우기(ordering)</title> + + <para> + 당신은 <literal>org.hibernate.criterion.Order</literal>를 사용하여 결과들을 순서(ordering)지울 수 있다. + </para> + + <programlisting><![CDATA[List cats = sess.createCriteria(Cat.class) + .add( Restrictions.like("name", "F%") + .addOrder( Order.asc("name") ) + .addOrder( Order.desc("age") ) + .setMaxResults(50) + .list();]]></programlisting> + + <programlisting><![CDATA[List cats = sess.createCriteria(Cat.class) + .add( Property.forName("name").like("F%") ) + .addOrder( Property.forName("name").asc() ) + .addOrder( Property.forName("age").desc() ) + .setMaxResults(50) + .list();]]></programlisting> + + </sect1> + + <sect1 id="querycriteria-associations" revision="2"> + <title>연관들</title> + + <para> + 당신은 <literal>createCriteria()</literal>를 사용하여 연관들을 네비게이트함으로써 관계된 엔티티들에 대한 컨스트레인트들을 + 쉽게 지정할 수 있다. + </para> + + <programlisting><![CDATA[List cats = sess.createCriteria(Cat.class) + .add( Restrictions.like("name", "F%") ) + .createCriteria("kittens") + .add( Restrictions.like("name", "F%") ) + .list();]]></programlisting> + + <para> + 두 번째 <literal>createCriteria()</literal>는 <literal>Criteria</literal>의 새로운 인스턴스를 반환하며, 그것은 + <literal>kittens</literal> 콜렉션의 요소들을 참조한다는 점을 노트하라. + </para> + + <para> + 다음 대체 형식은 어떤 환경들에서 유용하다. + </para> + + <programlisting><![CDATA[List cats = sess.createCriteria(Cat.class) + .createAlias("kittens", "kt") + .createAlias("mate", "mt") + .add( Restrictions.eqProperty("kt.name", "mt.name") ) + .list();]]></programlisting> + + <para> + (<literal>createAlias()</literal>는 <literal>Criteria</literal>의 새로운 인스턴스를 생성시키지 않는다.) + </para> + + <para> + 앞의 두 개의 질의들에 의해 반환된 <literal>Cat</literal> 인스턴스들에 의해 보관된 kittens 콜렉션들은 criteria에 의해 + 사전-필터링되지 <emphasis>않는다</emphasis>는 점을 노트하라! 만일 당신이 criteria(기준)과 일치하는 고양이 새끼들을 + 단지 검색하고자 원할 경우, 당신은 하나의 <literal>ResultTransformer</literal>를 사용해야 한다. + </para> + + <programlisting><![CDATA[List cats = sess.createCriteria(Cat.class) + .createCriteria("kittens", "kt") + .add( Restrictions.eq("name", "F%") ) + .setResultTransformer(Criteria.ALIAS_TO_ENTITY_MAP) + .list(); +Iterator iter = cats.iterator(); +while ( iter.hasNext() ) { + Map map = (Map) iter.next(); + Cat cat = (Cat) map.get(Criteria.ROOT_ALIAS); + Cat kitten = (Cat) map.get("kt"); +}]]></programlisting> + + </sect1> + + <sect1 id="querycriteria-dynamicfetching" revision="1"> + <title>동적인 연관 페칭</title> + + <para> + 당신은 <literal>setFetchMode()</literal>를 사용하여 실행 시에 연관 페칭 의미를 지정할 수 있다. + </para> + + <programlisting><![CDATA[List cats = sess.createCriteria(Cat.class) + .add( Restrictions.like("name", "Fritz%") ) + .setFetchMode("mate", FetchMode.EAGER) + .setFetchMode("kittens", FetchMode.EAGER) + .list();]]></programlisting> + + <para> + 이 질의는 outer 조인으로 <literal>mate</literal>와 <literal>kittens</literal> 모두를 페치할 것이다. 추가 정보는 + <xref linkend="performance-fetching"/>을 보라. + </para> + + </sect1> + + <sect1 id="querycriteria-examples"> + <title>예제 질의들</title> + + <para> + <literal>org.hibernate.criterion.Example</literal> 클래스는 주어진 인스턴스로부터 질의 기준(criterion)을 구조화 + 시키는 것을 당신에게 허용해준다. + </para> + + <programlisting><![CDATA[Cat cat = new Cat(); +cat.setSex('F'); +cat.setColor(Color.BLACK); +List results = session.createCriteria(Cat.class) + .add( Example.create(cat) ) + .list();]]></programlisting> + + <para> + 버전 프로퍼티들, 식별자들, 연관관계들이 무시된다. 디폴트로 null 값 프로퍼티들이 제외된다. + </para> + + <para> + 당신은 <literal>Example</literal>이 적용되는 방법을 조정할 수 있다. + </para> + + <programlisting><![CDATA[Example example = Example.create(cat) + .excludeZeroes() //exclude zero valued properties + .excludeProperty("color") //exclude the property named "color" + .ignoreCase() //perform case insensitive string comparisons + .enableLike(); //use like for string comparisons +List results = session.createCriteria(Cat.class) + .add(example) + .list();]]></programlisting> + + <para> + 당신은 연관된 객체들에 대한 criteria(기준)을 위치지우는데 examples를 사용할 수 있다. + </para> + + <programlisting><![CDATA[List results = session.createCriteria(Cat.class) + .add( Example.create(cat) ) + .createCriteria("mate") + .add( Example.create( cat.getMate() ) ) + .list();]]></programlisting> + + </sect1> + + <sect1 id="querycriteria-projection"> + <title>Projections, aggregation 그리고 grouping</title> + <para> + <literal>org.hibernate.criterion.Projections</literal> 클래스는 <literal>Projection</literal> 인스턴스들에 + 대한 팩토리이다. 우리는 <literal>setProjection()</literal>을 호출하여 하나의 질의에 projection(투사,투영)을 적용시킨다. + </para> + + <programlisting><![CDATA[List results = session.createCriteria(Cat.class) + .setProjection( Projections.rowCount() ) + .add( Restrictions.eq("color", Color.BLACK) ) + .list();]]></programlisting> + + <programlisting><![CDATA[List results = session.createCriteria(Cat.class) + .setProjection( Projections.projectionList() + .add( Projections.rowCount() ) + .add( Projections.avg("weight") ) + .add( Projections.max("weight") ) + .add( Projections.groupProperty("color") ) + ) + .list();]]></programlisting> + + <para> + criteria 질의 내에서는 명시적인 "group by"가 필수적이지 않다. 어떤 projection 타입들은 + <emphasis>grouping projections</emphasis>들이게끔 정의되고, 그것은 또한 SQL <literal>group by</literal> 절 속에 + 나타난다. + </para> + + <para> + alias는 선택적으로 projection에 할당될 수 있어서, 투사된(projected) 값은 제한(restriction)들 또는 ordering들 내에서 + 참조될 수 있다. 다음은 이것을 행하는 두 개의 다른 방법들이다: + </para> + + <programlisting><![CDATA[List results = session.createCriteria(Cat.class) + .setProjection( Projections.alias( Projections.groupProperty("color"), "colr" ) ) + .addOrder( Order.asc("colr") ) + .list();]]></programlisting> + + <programlisting><![CDATA[List results = session.createCriteria(Cat.class) + .setProjection( Projections.groupProperty("color").as("colr") ) + .addOrder( Order.asc("colr") ) + .list();]]></programlisting> + + <para> + <literal>alias()</literal> 메소드와 <literal>as()</literal> 메소드는 또 다른 alias 된 + <literal>Projection</literal>의 인스턴스 내에 하나의 projection 인스턴스를 간단하게 포장한다. 지름길로서, + 당신이 projection을 projection 리스트에 추가할 때 당신은 alias를 할당할 수 있다: + </para> + + <programlisting><![CDATA[List results = session.createCriteria(Cat.class) + .setProjection( Projections.projectionList() + .add( Projections.rowCount(), "catCountByColor" ) + .add( Projections.avg("weight"), "avgWeight" ) + .add( Projections.max("weight"), "maxWeight" ) + .add( Projections.groupProperty("color"), "color" ) + ) + .addOrder( Order.desc("catCountByColor") ) + .addOrder( Order.desc("avgWeight") ) + .list();]]></programlisting> + + <programlisting><![CDATA[List results = session.createCriteria(Domestic.class, "cat") + .createAlias("kittens", "kit") + .setProjection( Projections.projectionList() + .add( Projections.property("cat.name"), "catName" ) + .add( Projections.property("kit.name"), "kitName" ) + ) + .addOrder( Order.asc("catName") ) + .addOrder( Order.asc("kitName") ) + .list();]]></programlisting> + + <para> + 당신은 또한 projection들을 표현하는데 <literal>Property.forName()</literal>을 사용할 수 있다: + </para> + + <programlisting><![CDATA[List results = session.createCriteria(Cat.class) + .setProjection( Property.forName("name") ) + .add( Property.forName("color").eq(Color.BLACK) ) + .list();]]></programlisting> + + <programlisting><![CDATA[List results = session.createCriteria(Cat.class) + .setProjection( Projections.projectionList() + .add( Projections.rowCount().as("catCountByColor") ) + .add( Property.forName("weight").avg().as("avgWeight") ) + .add( Property.forName("weight").max().as("maxWeight") ) + .add( Property.forName("color").group().as("color" ) + ) + .addOrder( Order.desc("catCountByColor") ) + .addOrder( Order.desc("avgWeight") ) + .list();]]></programlisting> + + </sect1> + + <sect1 id="querycriteria-detachedqueries"> + <title>Detached 질의들과 서브질의들</title> + <para> + <literal>DetachedCriteria</literal> 클래스는 당신에게 세션 영역의 외부에서 질의를 생성시키도록 하고, 그런 다음 나중에 + 어떤 임의의 <literal>Session</literal>을 사용하여 그것을 실행하도록 한다. + </para> + + <programlisting><![CDATA[DetachedCriteria query = DetachedCriteria.forClass(Cat.class) + .add( Property.forName("sex").eq('F') ); + +Session session = ....; +Transaction txn = session.beginTransaction(); +List results = query.getExecutableCriteria(session).setMaxResults(100).list(); +txn.commit(); +session.close();]]></programlisting> + + <para> + <literal>DetachedCriteria</literal>는 또한 서브질의를 표현하는데 사용된다. 서브질의들을 포함하는 Criterion 인스턴스들은 + <literal>Subqueries</literal> 또는 <literal>Property</literal>를 통해 얻어질 수 있다. + </para> + + <programlisting><![CDATA[DetachedCriteria avgWeight = DetachedCriteria.forClass(Cat.class) + .setProjection( Property.forName("weight").avg() ); +session.createCriteria(Cat.class) + .add( Property.forName("weight").gt(avgWeight) ) + .list();]]></programlisting> + + <programlisting><![CDATA[DetachedCriteria weights = DetachedCriteria.forClass(Cat.class) + .setProjection( Property.forName("weight") ); +session.createCriteria(Cat.class) + .add( Subqueries.geAll("weight", weights) ) + .list();]]></programlisting> + + <para> + 심지어 상관관계 지워진 서브질의들이 가능하다: + </para> + + <programlisting><![CDATA[DetachedCriteria avgWeightForSex = DetachedCriteria.forClass(Cat.class, "cat2") + .setProjection( Property.forName("weight").avg() ) + .add( Property.forName("cat2.sex").eqProperty("cat.sex") ); +session.createCriteria(Cat.class, "cat") + .add( Property.forName("weight").gt(avgWeightForSex) ) + .list();]]></programlisting> + + </sect1> + + <!--TODO: ResultSetTransformer + aliasing. AliasToBeanTransformer는 -JDO2에서 setResultClass와 유사한- 임의적인 + 사용자 객체들을 반환하는 것을 허용한다. ResultTransformer에 대한 일반적인 사용이 또한 설명될 수 있다. --> + + <sect1 id="query-criteria-naturalid"> + <title>natural 식별자에 의한 질의들</title> + + <para> + 대부분의 질의들에서, criteria 질의들을 포함하여, 질의 캐시는 매우 효율적이지 않다. 왜냐하면 질의 캐시 비유효성이 + 너무 자주 발생하기 때문이다. 하지만, 우리가 캐시 비유효성 알고리즘을 최적화 시킬 수 있는 한 가지 특별한 종류의 질의가 + 존재한다: 상수 natural 키에 의한 룩업. 몇몇 어플리케이션들에서, 이런 종류의 질의가 자주 발생한다. criteria API는 + 이 쓰임새를 위한 특별한 설비를 제공한다. + </para> + + <para> + 첫번째로 당신은 <literal>&lt;natural-id&gt;</literal>를 사용하여 당신의 엔티티에 대한 natural 키를 매핑 + 시켜야 하고, second-level 캐시 사용을 가능하게 해야 한다. + </para> + + <programlisting><![CDATA[<class name="User"> + <cache usage="read-write"/> + <id name="id"> + <generator class="increment"/> + </id> + <natural-id> + <property name="name"/> + <property name="org"/> + </natural-id> + <property name="password"/> +</class>]]></programlisting> + + <para> + 이 기능은 <emphasis>가변성 있는</emphasis> natural 키들을 가진 엔티티들의 용도로 고안되어 있지 않음을 노트하라. + </para> + + <para> + 다음으로 , Hibernate 질의 캐시를 사용 가능하도록 하라. + </para> + + <para> + 이제 <literal>Restrictions.naturalId()</literal>는 캐시 알고리즘을 보다 효율적으로 사용할 수 있도록 우리에게 허용해준다. + </para> + + <programlisting><![CDATA[session.createCriteria(User.class) + .add( Restrictions.naturalId() + .set("name", "gavin") + .set("org", "hb") + ).setCacheable(true) + .uniqueResult();]]></programlisting> + + </sect1> + +</chapter> Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/query_hql.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/query_hql.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/query_hql.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/query_hql.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,1178 @@ +<chapter id="queryhql" revision="1"> + <title>HQL: 하이버네이트 질의 언어(Hibernate Query Language)</title> + + <para> + Hibernate는 (아주 의도적으로) SQL과 매우 흡사하게 보이는 극히 강력한 질의 언어를 구비하고 있다. 그러나 그 구문에 의해 우롱당하지 말라; + HQL은 상속, 다형성 그리고 연관과 같은 개념들을 이해하여서, 전체적으로 객체 지향적이다. + </para> + + <sect1 id="queryhql-casesensitivity"> + <title>대소문자 구분</title> + + <para> + 질의들은 Java 클래스들과 프로퍼티들의 이름들을 제외하면 대소문자를 구분하지 않는다. 따라서 <literal>SeLeCT</literal>는 + <literal>SELECT</literal>와 같고 <literal>SELECT</literal>와도 같지만 <literal>org.hibernate.eg.FOO</literal>는 + <literal>org.hibernate.eg.Foo</literal>과 같지 않고 <literal>foo.barSet</literal>은 + <literal>foo.BARSET</literal>과 같지 않다. + </para> + + <para> + 이 매뉴얼은 소문자 HQL 키워드를 사용한다. 몇몇 사용자들은 보다 나은 가독성을 위해 대문자 키워드들을 가진 질의들을 찾지만, 우리는 + 자바 코드 속에 삽입될 때 이 컨벤션이 추하다는 점을 발견한다. + </para> + + </sect1> + + <sect1 id="queryhql-from"> + <title>from 절</title> + + <para> + 가장 간단한 가능한 Hibernate 질의는 다음 형식이다: + </para> + + <programlisting><![CDATA[from eg.Cat]]></programlisting> + + <para> + 이것은 <literal>eg.Cat</literal> 클래스의 모든 인스턴스들을 간단하게 반환한다. 우리는 대개 클래스 이름을 수식할 필요가 없다. + 왜냐하면, <literal>auto-import</literal>가 디폴트이기 때문이다. 따라서 우리는 대개 항상 단지 다음과 같이 작성한다: + </para> + + <programlisting><![CDATA[from Cat]]></programlisting> + + <para> + 대개 당신은 한 개의 <emphasis>alias</emphasis>를 할당할 필요가 있을 것이다. 왜냐하면 당신은 질의의 다른 부분들에서 + <literal>Cat</literal>을 참조하고자 원할 것이기 때문이다. + </para> + + <programlisting><![CDATA[from Cat as cat]]></programlisting> + + <para> + 이 질의는 alias <literal>cat</literal>을 <literal>Cat</literal> 인스턴스들에 할당하여서, 우리는 나중에 질의 속에서 + 그 alias를 사용할 수 있을 것이다. <literal>as</literal> 키워드는 옵션이다; 우리는 또한 다음과 같이 작성할 수 있다: + </para> + + <programlisting><![CDATA[from Cat cat]]></programlisting> + + <para> + 여러 개의 클래스들은 cartesian product(카티젼 곱) 또는 "크로스" 조인으로 귀결되어 나타날 수도 있다. + </para> + + <programlisting><![CDATA[from Formula, Parameter]]></programlisting> + <programlisting><![CDATA[from Formula as form, Parameter as param]]></programlisting> + + <para> + 로컬 변수들에 대한 Java 네이밍 표준들과 일치되게, 첫 소문자를 사용하여 질의 alias들을 명명하는 것은 좋은 습관으로 간주된다 + (예를 들면 <literal>domesticCat</literal>). + </para> + + </sect1> + + <sect1 id="queryhql-joins" revision="2"> + <title>연관들과 조인들</title> + + <para> + 우리는 또한 <literal>join</literal>을 사용하여 , 연관된 엔티티들에 또는 값들을 가진 콜렉션의 요소들에도 alias들을 할당할 수도 + 있다. + </para> + + <programlisting><![CDATA[from Cat as cat + inner join cat.mate as mate + left outer join cat.kittens as kitten]]></programlisting> + + <programlisting><![CDATA[from Cat as cat left join cat.mate.kittens as kittens]]></programlisting> + + <programlisting><![CDATA[from Formula form full join form.parameter param]]></programlisting> + + <para> + 지원되는 join 타입들은 ANSI SQL로부터 빌려왔다 + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + <literal>inner join</literal> + </para> + </listitem> + <listitem> + <para> + <literal>left outer join</literal> + </para> + </listitem> + <listitem> + <para> + <literal>right outer join</literal> + </para> + </listitem> + <listitem> + <para> + <literal>full join</literal> (대개 유용하지 않음) + </para> + </listitem> + </itemizedlist> + + <para> + <literal>inner join</literal>, <literal>left outer join</literal>, 그리고 <literal>right outer join</literal> + 구조체들이 약칭될 수 있다. + </para> + + <programlisting><![CDATA[from Cat as cat + join cat.mate as mate + left join cat.kittens as kitten]]></programlisting> + + <para> + 당신은 HQL <literal>with</literal> 키워드를 사용하여 특별한 조인 조건들을 제공할 수 있다. + </para> + + <programlisting><![CDATA[from Cat as cat + left join cat.kittens as kitten + with kitten.bodyWeight > 10.0]]></programlisting> + + <para> + 게다가, "fetch" join은 값들을 가진 콜렉션들이나 연관관계들이 한 개의 select를 사용하여, 그것들의 부모 객체들에 따라 초기화 되는 + 것을 허용해준다. 이것은 콜렉션의 경우에 특히 유용하다. 그것은 연관관계들과 콜렉션들에 대한 매핑 파일의 outer join과 lazy 선언들을 + 효율적으로 오버라이드 시킨다. 추가 정보는 <xref linkend="performance-fetching"/>을 보라. + </para> + + <programlisting><![CDATA[from Cat as cat + inner join fetch cat.mate + left join fetch cat.kittens]]></programlisting> + + <para> + fetch join은 대개 alias를 할당할 필요가 없다. 왜냐하면, 연관된 객체들이 <literal>where</literal> 절(또는 어떤 다른 절) + 속에 사용되지 않을 것이기 때문이다. 또한 연관된 객체들은 질의 결과들 속에 직접 반환되지 않는다. 대신 그것들은 부모 객체를 통해 + 접근될 수 있다. 우리가 alias를 필요로 할 수 있는 유일한 이유는 더 많은 콜렉션들을 재귀적으로 조인 페칭시키는 경우이다: + </para> + + <programlisting><![CDATA[from Cat as cat + inner join fetch cat.mate + left join fetch cat.kittens child + left join fetch child.kittens]]></programlisting> + + <para> + (비록 <literal>scroll()</literal>이 사용될 수 있을지라도) <literal>fetch</literal> 구조체는 + <literal>iterate()</literal>를 사용하여 호출되는 질의들 내에 사용될 수 없음을 노트하라. 이들 오퍼레이션들이 결과 행들에 + 기초하고 있기 때문에 <literal>fetch</literal>는 <literal>setMaxResults()</literal> 또는 + <literal>setFirstResult()</literal>과 함께 사용되지 말아야 하며, 그것들(결과 행들)은 대개 각각의 eager 콜렉션 페칭에 대해 + 중복들을 포함하므로 많은 행들이 당신이 기대하는 것이 아니다. + <literal>fetch</literal>는 특별한 용도의 <literal>with</literal> 조건과도 함께 사용될 수 없다.한 개의 질의 내에 하나 + 이상의 콜렉션을 조인 페칭시켜 카티젼 곱을 생성시키는 것이 가능한데, 이 경우에 주의하라. 다중 콜렉션 role들을 조인 페칭시키는 것은 + 또한 때때로 bag 매핑들에 대해 예기치 않은 결과들을 가져다주기 때문에, 당신이 이 경우에 당신의 질의들을 처방하는 방법에 대해 주의하라. + 마지막으로 <literal>full join fetch</literal>와 <literal>right join fetch</literal>는 의미가 없다. + </para> + + <para> + 만일 당신이 (바이트코드 방편으로) property-레벨 lazy 페칭을 사용할 경우, Hibernate로 하여금 <literal>fetch all properties</literal>를 + 사용하여 (첫 번째 질의에서) lazy 프로퍼티들을 즉시 페치하도록 강제시키는 것이 가능하다. + </para> + + <programlisting><![CDATA[from Document fetch all properties order by name]]></programlisting> + <programlisting><![CDATA[from Document doc fetch all properties where lower(doc.name) like '%cats%']]></programlisting> + + </sect1> + + <sect1 id="queryhql-joins-forms"> + <title>join 구문의 형식들</title> + + <para> + HQL은 두 가지 형식의 연관 조인을 지원한다: <literal>암묵적</literal> 그리고 <literal>명시적</literal>. + </para> + + <para> + 앞의 절에서 보여진 질의들은 모두 join 키워드가 from 절 내에 명시적으로 사용되는 <literal>명시적인</literal> 형식을 + 사용한다. 이것은 권장되는 형식이다. + </para> + + <para> + <literal>함축적인</literal> 형식은 join 키워드를 사용하지 않는다. 대신에, 연관들은 dot(.) 표기를 + 사용하여 "dot-참조된다(dereferenced)". <literal>함축적인</literal> 조인들은 임의의 HQL 절들내에 + 나타날 수 있다. <literal>함축적인</literal> join은 결과되는 SQL 문장에서 inner join으로 귀결된다. + </para> + + <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> + composite 식별자 속성들에 대한 참조들은 동일한 네이밍 규칙들을 따른다. 만일 그 엔티티가 id로 명명된 비식별자를 + 갖고 있을 경우, composite 속성은 오직 그것의 정의된 명명에 의해 참조될 수 있다; 그밖의 경우 특별한 <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> + + <para> + <literal>select</literal> 절은 질의 결과 셋 속에 반환할 객체들과 프로퍼티들이 어느 것인지를 골라 내도록 강제한다. 다음을 + 검토하자: + </para> + + <programlisting><![CDATA[select mate +from Cat as cat + inner join cat.mate as mate]]></programlisting> + + <para> + 질의는 다른 <literal>Cat</literal>들의 <literal>mate</literal>들을 select 할 것이다. 실제로 당신은 이 질의들을 다음과 + 같이 보다 축약형으로 표현할수도 있다: + </para> + + <programlisting><![CDATA[select cat.mate from Cat cat]]></programlisting> + + <para> + 질의들은 컴포넌트 타입의 프로퍼티들을 포함하는 임의의 값 타입의 프로퍼티들을 반환할 수도 있다: + </para> + + <programlisting><![CDATA[select cat.name from DomesticCat cat +where cat.name like 'fri%']]></programlisting> + + <programlisting><![CDATA[select cust.name.firstName from Customer as cust]]></programlisting> + + <para> + <literal>Family</literal> 클래스가 적당한 생성자를 갖고 있음을 가정하면, + 질의들은 여러 객체들 그리고/또는 프로퍼티들을 <literal>Object[]</literal> 타입의 배열로서, + </para> + + <programlisting><![CDATA[select mother, offspr, mate.name +from DomesticCat as mother + inner join mother.mate as mate + left outer join mother.kittens as offspr]]></programlisting> + + <para> + 또는 <literal>List</literal>로서, + </para> + + <programlisting><![CDATA[select new list(mother, offspr, mate.name) +from DomesticCat as mother + inner join mother.mate as mate + left outer join mother.kittens as offspr]]></programlisting> + + <para> + 또는 실제 typesafe 자바 객체로서, + </para> + + <programlisting><![CDATA[select new Family(mother, mate, offspr) +from DomesticCat as mother + join mother.mate as mate + left join mother.kittens as offspr]]></programlisting> + + <para> + 반환할 수도 있다. + </para> + + <para> + 당신은 <literal>as</literal>를 사용하여 select되는 표현식들에 alias들을 할당할 수 있다: + </para> + + <programlisting><![CDATA[select max(bodyWeight) as max, min(bodyWeight) as min, count(*) as n +from Cat cat]]></programlisting> + + <para> + 다음은 <literal>select new map</literal>과 함께 사용될 때 가장 유용하다: + </para> + + <programlisting><![CDATA[select new map( max(bodyWeight) as max, min(bodyWeight) as min, count(*) as n ) +from Cat cat]]></programlisting> + + <para> + 이 질의는 select된 값들에 대한 alias로부터 한 개의 <literal>Map</literal>을 반환한다. + </para> + + </sect1> + + <sect1 id="queryhql-aggregation"> + <title>집계 함수들</title> + + <para> + HQL 질의들은 프로퍼티들에 대한 집계(aggregate) 함수들의 결과들을 반환할수도 있다: + </para> + + <programlisting><![CDATA[select avg(cat.weight), sum(cat.weight), max(cat.weight), count(cat) +from Cat cat]]></programlisting> + +<!-- NO LONGER SUPPORTED + <para> + Collections may also appear inside aggregate functions in the <literal>select</literal> + clause. + </para> + + <programlisting><![CDATA[select cat, count( elements(cat.kittens) ) +from Cat cat group by cat]]></programlisting> +--> + + <para> + 지원되는 집계 함수들은 다음과 같다 + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + <literal>avg(...), sum(...), min(...), max(...)</literal> + </para> + </listitem> + <listitem> + <para> + <literal>count(*)</literal> + </para> + </listitem> + <listitem> + <para> + <literal>count(...), count(distinct ...), count(all...)</literal> + </para> + </listitem> + </itemizedlist> + + <para> + 당신은 select 절 속에 산술 연산자들, 연결 연산자, 그리고 인지된 SQL 함수들을 사용할 수 있다: + </para> + + <programlisting><![CDATA[select cat.weight + sum(kitten.weight) +from Cat cat + join cat.kittens kitten +group by cat.id, cat.weight]]></programlisting> + + <programlisting><![CDATA[select firstName||' '||initial||' '||upper(lastName) from Person]]></programlisting> + + <para> + <literal>distinct</literal> 키워드와 all <literal>all</literal>가 사용될 수 있고 SQL의 경우와 동일한 의미를 갖는다. + </para> + + <programlisting><![CDATA[select distinct cat.name from Cat cat + +select count(distinct cat.name), count(cat) from Cat cat]]></programlisting> + + </sect1> + + <sect1 id="queryhql-polymorphism"> + <title>Polymorphic(다형성) 질의들</title> + + <para> + 다음과 같은 질의: + </para> + + <programlisting><![CDATA[from Cat as cat]]></programlisting> + + <para> + 은 <literal>Cat</literal>의 인스턴스들 뿐만 아니라, 또한 <literal>DomesticCat</literal>과 같은 서브클래스들 또한 + 반환한다. Hibernate 질의들은 <literal>from</literal> 절 내에 <emphasis>임의의</emphasis> 자바 클래스나 인터페이스를 + 명명할 수 있다. 질의는 그 클래스를 확장하거나 그 인터페이스를 구현하는 모든 영속 클래스들의 인스턴스들을 반환할 것이다. 다음 질의는 + 모든 영속 객체들을 반환할 것이다: + </para> + + <programlisting><![CDATA[from java.lang.Object o]]></programlisting> + + <para> + 인터페이스 <literal>Named</literal>는 여러 가지 영속 클래스들에 의해 구현될 수도 있다: + </para> + + <programlisting><![CDATA[from Named n, Named m where n.name = m.name]]></programlisting> + + <para> + 이들 마지막 두 개의 질의들은 하나 이상의 SQL <literal>SELECT</literal>를 필요로 할 것임을 노트하라. 이것은 <literal>order by</literal> + 절이 정확하게 전체 결과 셋을 순서지우지 않음을 의미한다.(그것은 또한 당신이 <literal>Query.scroll()</literal>을 사용하여 + 이들 질의들을 호출할 수 없음을 의미한다). + </para> + + </sect1> + + <sect1 id="queryhql-where" revision="1"> + <title>where 절</title> + + <para> + <literal>where</literal> 절은 반환된 인스턴스들의 목록을 제한시키는 것을 당신에게 허용해준다. 만일 alias가 존재하지 않을 경우, + 당신은 이름에 의해 프로퍼티들을 참조할 수도 있다: + </para> + + <programlisting><![CDATA[from Cat where name='Fritz']]></programlisting> + + <para> + 만일 한 개의 alias가 존재할 경우, 하나의 수식어가 붙은 프로퍼티 이름을 사용하라: + </para> + + <programlisting><![CDATA[from Cat as cat where cat.name='Fritz']]></programlisting> + + <para> + 는 'Fritz'로 명명된 <literal>Cat</literal>의 인스턴스들을 반환한다. + </para> + + <programlisting><![CDATA[select foo +from Foo foo, Bar bar +where foo.startDate = bar.date]]></programlisting> + + <para> + 는 <literal>Foo</literal>의 <literal>startDate</literal> 프로퍼티와 동일한 <literal>date</literal> 프로퍼티를 + 가진 <literal>bar</literal>의 인스턴스가 존재하는 <literal>Foo</literal>의 모든 인스턴스를 반환할 것이다. 합성 경로 + 표현식들은 <literal>where</literal> 절을 매우 강력하게 만들어준다. 다음을 검토하자: + </para> + + <programlisting><![CDATA[from Cat cat where cat.mate.name is not null]]></programlisting> + + <para> + 이 질의는 테이블 (inner) join을 가진 SQL 질의로 번역된다. 만일 당신이 다음과 같은 어떤 것을 작성했다면 + </para> + + <programlisting><![CDATA[from Foo foo +where foo.bar.baz.customer.address.city is not null]]></programlisting> + + <para> + 당신은 SQL에서 네 개의 테이블 join들을 필요로 하는 하나의 질의로 끝낼 것이다. + </para> + + <para> + <literal>=</literal> 연산자는 프로퍼티들 뿐만 아니라 또한 인스턴스들을 비교하는데 사용될 수 있다: + </para> + + <programlisting><![CDATA[from Cat cat, Cat rival where cat.mate = rival.mate]]></programlisting> + + <programlisting><![CDATA[select cat, mate +from Cat cat, Cat mate +where cat.mate = mate]]></programlisting> + + <para> + 특별한 프로퍼티(소문자) <literal>id</literal>는 객체의 유일 식별자를 참조하는데 사용될 수 있다. + 추가 정보는 <xref linkend="queryhql-identifier-property"/>를 보라. + </para> + + <programlisting><![CDATA[from Cat as cat where cat.id = 123 + +from Cat as cat where cat.mate.id = 69]]></programlisting> + + <para> + 두 번째 질의가 효율적이다. 테이블 join이 필요 없다! + </para> + + <para> + composite(합성) 식별자들의 프로퍼티들이 또한 사용될 수 있다. <literal>Person</literal>이 + <literal>country</literal>와 <literal>medicareNumber</literal>로 구성된 composite 식별자를 갖는다고 + 가정하자. 식별자 속성들을 참조하는 것과 관련된 추가 정보는 다시 <xref linkend="queryhql-identifier-property"/>를 보라. + </para> + + <programlisting><![CDATA[from bank.Person person +where person.id.country = 'AU' + and person.id.medicareNumber = 123456]]></programlisting> + + <programlisting><![CDATA[from bank.Account account +where account.owner.id.country = 'AU' + and account.owner.id.medicareNumber = 123456]]></programlisting> + + <para> + 다시 한번, 두 번째 질의는 테이블 join을 필요로 하지 않는다. + </para> + + <para> + 마찬가지로, 특별한 프로퍼티 <literal>class</literal>는 다형적인 영속성(polymorphic persistence)의 경우에 인스턴스의 + 판별자(discriminator) 값에 액세스한다. where 절 속에 삽입된 Java 클래스 이름은 그것의 판별자(discriminator) 값으로 + 변환될 것이다. + </para> + + <programlisting><![CDATA[from Cat cat where cat.class = DomesticCat]]></programlisting> + + <para> + 당신은 또한 컴포넌트들 또는 composite 사용자 타입들, 또는 명명된 컴포넌트 타입들의 속성들을 사용할 수도 있다. 상세한 것은 + <xref linkend="queryhql-components"/>를 보라. + </para> + + <para> + "임의의" 타입은 다음 방법으로 join을 표현하는 것을 우리에게 허용해주는, 특별한 프로퍼티들 <literal>id</literal>와 + <literal>class</literal>를 갖는다(여기서 <literal>AuditLog.item</literal>은 <literal>&lt;any&gt;</literal>로 + 매핑된 프로퍼티이다). + </para> + + <programlisting><![CDATA[from AuditLog log, Payment payment +where log.item.class = 'Payment' and log.item.id = payment.id]]></programlisting> + + <para> + <literal>log.item.class</literal>와 <literal>payment.class</literal>는 위의 질의 내에서 완전히 다른 데이터베이스 + 컬럼들의 값들을 참조할 것임을 노트하라. + </para> + + </sect1> + + <sect1 id="queryhql-expressions"> + <title>표현식들</title> + + <para> + <literal>where</literal> 절 속에 허용되는 표현식들은 당신이 SQL로 작성할 수 있는 대부분의 종류의 것들을 포함한다: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + 산술 연산자들 <literal>+, -, *, /</literal> + </para> + </listitem> + <listitem> + <para> + 바이너리 비교 연산자들 <literal>=, &gt;=, &lt;=, &lt;&gt;, !=, like</literal> + </para> + </listitem> + <listitem> + <para> + 논리 연산들 <literal>and, or, not</literal> + </para> + </listitem> + <listitem> + <para> + 그룹핑을 나타내는 괄호들 <literal>( )</literal>, indicating grouping + </para> + </listitem> + <listitem> + <para> + <literal>in</literal>, + <literal>not in</literal>, + <literal>between</literal>, + <literal>is null</literal>, + <literal>is not null</literal>, + <literal>is empty</literal>, + <literal>is not empty</literal>, + <literal>member of</literal> and + <literal>not member of</literal> + </para> + </listitem> + <listitem> + <para> + "간단한" 경우, <literal>case ... when ... then ... else ... end</literal>, 그리고 + "검색인" 경우, <literal>case when ... then ... else ... end</literal> + </para> + </listitem> + <listitem> + <para> + 문자열 연결 <literal>...||...</literal> or <literal>concat(...,...)</literal> + </para> + </listitem> + <listitem> + <para> + <literal>current_date()</literal>, <literal>current_time()</literal>, + <literal>current_timestamp()</literal> + </para> + </listitem> + <listitem> + <para> + <literal>second(...)</literal>, <literal>minute(...)</literal>, + <literal>hour(...)</literal>, <literal>day(...)</literal>, + <literal>month(...)</literal>, <literal>year(...)</literal>, + </para> + </listitem> + <listitem> + <para> + EJB-QL 3.0에 의해 정의된 임의의 함수 또는 오퍼레이터: <literal>substring(), trim(), + lower(), upper(), length(), locate(), abs(), sqrt(), bit_length(), mod()</literal> + </para> + </listitem> + <listitem> + <para> + <literal>coalesce()</literal> 그리고 <literal>nullif()</literal> + </para> + </listitem> + <listitem> + <para> + numeric 값들이나 temporal 값들을 가독성 있는 문자열로 변환시키는 <literal>str()</literal> + </para> + </listitem> + <listitem> + <para> + <literal>cast(... as ...)</literal>, 여기서 두번 째 아규먼트는 Hibernate 타입의 이름이고, + ANSI <literal>cast()</literal>와 <literal>extract()</literal>가 기반 데이터베이스에 의해 + 지원될 경우에는 <literal>extract(... from ...)</literal>. + </para> + </listitem> + <listitem> + <para> + 조인된 인덱싱된 콜렉션의 alias들에 적용되는, HQL <literal>index()</literal> 함수 + </para> + </listitem> + <listitem> + <para> + 콜렉션 값을 가진 경로 표현식들을 취하는 HQL 함수들 : <literal>some, all, exists, any, in</literal>을 + 사용하여 정량화 될 수 있는 특별한 <literal>elements()</literal>와 <literal>indices</literal> + 함수들과 함께 <literal>size(), minelement(), maxelement(), minindex(), maxindex()</literal>. + </para> + </listitem> + <listitem> + <para> + <literal>sign()</literal>, <literal>trunc()</literal>, <literal>rtrim()</literal>, + <literal>sin()</literal>과 같이 임의의 데이터베이스 지원 SQL 스칼라 함수 + </para> + </listitem> + <listitem> + <para> + JDBC-스타일 위치 파라미터들 <literal>?</literal> + </para> + </listitem> + <listitem> + <para> + 명명된 파라미터들 <literal>:name</literal>, <literal>:start_date</literal>, <literal>:x1</literal> + </para> + </listitem> + <listitem> + <para> + SQL 리터럴들 <literal>'foo'</literal>, <literal>69</literal>, <literal>6.66E+2</literal>, + <literal>'1970-01-01 10:00:01.0'</literal> + </para> + </listitem> + <listitem> + <para> + Java <literal>public static final</literal> 상수들. <literal>eg.Color.TABBY</literal> + </para> + </listitem> + </itemizedlist> + + <para> + <literal>in</literal> 과 <literal>between</literal>은 다음과 같이 사용될 수 있다: + </para> + + <programlisting><![CDATA[from DomesticCat cat where cat.name between 'A' and 'B']]></programlisting> + + <programlisting><![CDATA[from DomesticCat cat where cat.name in ( 'Foo', 'Bar', 'Baz' )]]></programlisting> + + <para> + 그리고 부정형들은 다음과 같이 작성될 수 있다 + </para> + + <programlisting><![CDATA[from DomesticCat cat where cat.name not between 'A' and 'B']]></programlisting> + + <programlisting><![CDATA[from DomesticCat cat where cat.name not in ( 'Foo', 'Bar', 'Baz' )]]></programlisting> + + <para> + 마찬가지로, <literal>is null</literal>과 <literal>is not null</literal>은 null 값들을 테스트하는데 사용될 수 있다. + </para> + + <para> + Boolean들은 Hibernate 구성 내에 HQL 질의 치환들을 선언함으로써 표현식들 내에 쉽게 사용될 수 있다: + </para> + + <programlisting><![CDATA[<property name="hibernate.query.substitutions">true 1, false 0</property>]]></programlisting> + + <para> + 이것은 키워드 <literal>true</literal>와 <literal>false</literal> 키워드들을 이 HQL로부터 번역된 SQL에서 + 리터럴 <literal>1</literal>과 <literal>0</literal>으로 대체될 것이다: + </para> + + <programlisting><![CDATA[from Cat cat where cat.alive = true]]></programlisting> + + <para> + 당신은 특별한 프로퍼티 <literal>size</literal>로서 또는 특별한 <literal>size()</literal> 함수로서 콜렉션의 사이즈를 + 테스트할 수 있다. + </para> + + <programlisting><![CDATA[from Cat cat where cat.kittens.size > 0]]></programlisting> + + <programlisting><![CDATA[from Cat cat where size(cat.kittens) > 0]]></programlisting> + + <para> + 인덱싱된 콜렉션들에 대해, 당신은<literal>minindex</literal>와 <literal>maxindex</literal> 함수들을 사용하여 + 최소 인덱스과 최대 인덱스를 참조할 수 있다. 유사하게 당신은 <literal>minelement</literal>와 + <literal>maxelement</literal> 함수를 사용하여 기본 타입을 가진 콜렉션의 최소 요소 및 최대 요소를 참조할 수 있다. + </para> + + <programlisting><![CDATA[from Calendar cal where maxelement(cal.holidays) > current_date]]></programlisting> + + <programlisting><![CDATA[from Order order where maxindex(order.items) > 100]]></programlisting> + + <programlisting><![CDATA[from Order order where minelement(order.items) > 10000]]></programlisting> + + <para> + SQL 함수들 <literal>any, some, all, exists, in</literal>은 콜렉션의 요소 또는 인덱스 세트(<literal>elements</literal> + 함수와 <literal>indices</literal> 함수), 또는 서브질의의 결과를 전달했을 때 지원된다(아래를 보라). + </para> + + <programlisting><![CDATA[select mother from Cat as mother, Cat as kit +where kit in elements(foo.kittens)]]></programlisting> + + <programlisting><![CDATA[select p from NameList list, Person p +where p.name = some elements(list.names)]]></programlisting> + + <programlisting><![CDATA[from Cat cat where exists elements(cat.kittens)]]></programlisting> + + <programlisting><![CDATA[from Player p where 3 > all elements(p.scores)]]></programlisting> + + <programlisting><![CDATA[from Show show where 'fizard' in indices(show.acts)]]></programlisting> + + <para> + 이들 구조체들-<literal>size</literal>, <literal>elements</literal>, <literal>indices</literal>, + <literal>minindex</literal>, <literal>maxindex</literal>, <literal>minelement</literal>, + <literal>maxelement</literal>-는 Hibernate3에서 where 절 내에서만 사용될 것임을 노트하라. + </para> + + <para> + 인덱싱 된 콜렉션들의 요소들(배열들, 리스트들, map들)은 인덱스에 의해 참조될 수 있다(where 절 안에서만): + </para> + + <programlisting><![CDATA[from Order order where order.items[0].id = 1234]]></programlisting> + + <programlisting><![CDATA[select person from Person person, Calendar calendar +where calendar.holidays['national day'] = person.birthDay + and person.nationality.calendar = calendar]]></programlisting> + + <programlisting><![CDATA[select item from Item item, Order order +where order.items[ order.deliveredItemIndices[0] ] = item and order.id = 11]]></programlisting> + + <programlisting><![CDATA[select item from Item item, Order order +where order.items[ maxindex(order.items) ] = item and order.id = 11]]></programlisting> + + <para> + <literal>[]</literal> 내부의 표현식은 산술 표현실일 수 있다. + </para> + + <programlisting><![CDATA[select item from Item item, Order order +where order.items[ size(order.items) - 1 ] = item]]></programlisting> + + <para> + HQL은 또한 one-to-many 연관 또는 값들을 가진 콜렉션의 요소들에 대해 미리 만들어진 <literal>index()</literal> 함수를 + 제공한다. + </para> + + <programlisting><![CDATA[select item, index(item) from Order order + join order.items item +where index(item) < 5]]></programlisting> + + <para> + 기본 데이터베이스에 의해 제공되는 Scalar SQL 함수들이 사용될 수도 있다 + </para> + + <programlisting><![CDATA[from DomesticCat cat where upper(cat.name) like 'FRI%']]></programlisting> + + <para> + 당신이 아직 이 모든 것을 납득하지 못한다면, SQL 내에서 다음 질의가 가독성이 얼마나 많고 적은지를 생각해보라: + </para> + + <programlisting><![CDATA[select cust +from Product prod, + Store store + inner join store.customers cust +where prod.name = 'widget' + and store.location.name in ( 'Melbourne', 'Sydney' ) + and prod = all elements(cust.currentOrder.lineItems)]]></programlisting> + + <para> + <emphasis>힌트</emphasis> : 다음과 같은 어떤 것 + </para> + + <programlisting><![CDATA[SELECT cust.name, cust.address, cust.phone, cust.id, cust.current_order +FROM customers cust, + stores store, + locations loc, + store_customers sc, + product prod +WHERE prod.name = 'widget' + AND store.loc_id = loc.id + AND loc.name IN ( 'Melbourne', 'Sydney' ) + AND sc.store_id = store.id + AND sc.cust_id = cust.id + AND prod.id = ALL( + SELECT item.prod_id + FROM line_items item, orders o + WHERE item.order_id = o.id + AND cust.current_order = o.id + )]]></programlisting> + + </sect1> + + <sect1 id="queryhql-ordering"> + <title>order by 절</title> + + <para> + 질의에 의해 반환된 리스트는 반환된 클래스 또는 컴포넌트들의 프로퍼티에 의해 순서(ordering)지워질 수 있다: + </para> + + <programlisting><![CDATA[from DomesticCat cat +order by cat.name asc, cat.weight desc, cat.birthdate]]></programlisting> + + <para> + <literal>asc</literal> 옵션 또는 <literal>desc</literal> 옵션은 각각 오름차순 또는 내림차순 정렬을 나타낸다. + </para> + </sect1> + + <sect1 id="queryhql-grouping" revision="1"> + <title>group by 절</title> + + <para> + aggregate 값들을 반환하는 질의는 반환된 클래스나 컴포넌트들의 프로퍼티에 의해 그룹지워질 수 있다: + </para> + + <programlisting><![CDATA[select cat.color, sum(cat.weight), count(cat) +from Cat cat +group by cat.color]]></programlisting> + + <programlisting><![CDATA[select foo.id, avg(name), max(name) +from Foo foo join foo.names name +group by foo.id]]></programlisting> + + <para> + 또한 <literal>having</literal> 절이 허용된다. + </para> + + <programlisting><![CDATA[select cat.color, sum(cat.weight), count(cat) +from Cat cat +group by cat.color +having cat.color in (eg.Color.TABBY, eg.Color.BLACK)]]></programlisting> + + <para> + SQL 함수들과 집계 함수들이 기본 데이터베이스에 의해 지원될 경우(예를 들어 MySQL은 지원되지 않는다) + <literal>having</literal> 절과 <literal>order by</literal> 절 속에 허용된다. + </para> + + <programlisting><![CDATA[select cat +from Cat cat + join cat.kittens kitten +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="3"> + <title>서브질의들</title> + + <para> + subselect들을 지원하는 데이터베이스들의 경우, Hibernate는 질의들 내에 서브질의들을 지원한다. 서브질의는 괄호로 묶여져야 + 한다(자주 SQL 집계함수 호출에 의해). 심지어 서로 상관된 서브질의들(외부 질의 내에서 alias를 참조하는 서브질의들)이 허용된다. + </para> + + <programlisting><![CDATA[from Cat as fatcat +where fatcat.weight > ( + select avg(cat.weight) from DomesticCat cat +)]]></programlisting> + + <programlisting><![CDATA[from DomesticCat as cat +where cat.name = some ( + select name.nickName from Name as name +)]]></programlisting> + + <programlisting><![CDATA[from Cat as cat +where not exists ( + from Cat as mate where mate.mate = cat +)]]></programlisting> + + <programlisting><![CDATA[from DomesticCat as cat +where cat.name not in ( + select name.nickName from Name as name +)]]></programlisting> + + <programlisting><![CDATA[select cat.id, (select max(kit.weight) from cat.kitten kit) +from Cat as cat]]></programlisting> + + <para> + HQL 서브질의들이 select 절 또는 where 절 내에서만 일어날 수 있음을 노트하라. + </para> + + + <para> + 서브질의들은 또한 <literal>row value constructor</literal> 구문을 활용할 수 있다. 상세한 것은 + <xref linkend="queryhql-tuple"/>를 보라. + </para> + + </sect1> + + <sect1 id="queryhql-examples"> + <title>HQL 예제들</title> + + <para> + + Hibernate 질의들은 매우 강력하고 복잡할 수 있다. 사실, 질의 언어의 힘은 Hibernate의 주요 판매 포인트들 중 하나이다. 다음은 + 내가 최근의 프로젝트에서 사용했던 질의들과 매우 유사한 몇몇 예제 질의들이다. 당신이 작성하게 될 대부분의 질의들은 이것들보다 훨씬 + 간단하다는 점을 노트하라! + </para> + + <para> + 다음 질의는 특정 고객에 대한 모든 지불되지 않은 주문들의 주문 id, 항목들의 개수, 그리고 주문의 전체 합계값 그리고 주어진 + 최소 전체 합계를 전체 합계값에 따라 결과들을 순서지워서 반환한다. 가격 결정에 있어, 그것은 현재의 카타록을 사용한다. + 귀결되는 SQL 질의는 <literal>ORDER</literal>, <literal>ORDER_LINE</literal>, <literal>PRODUCT</literal>, + <literal>CATALOG</literal>, <literal>PRICE</literal> 테이블들에 대한 네 개의 inner 조인들과 한 개의(상관지워지지 + 않은) subselect를 갖고 있다. + </para> + + <programlisting><![CDATA[select order.id, sum(price.amount), count(item) +from Order as order + join order.lineItems as item + join item.product as product, + Catalog as catalog + join catalog.prices as price +where order.paid = false + and order.customer = :customer + and price.product = product + and catalog.effectiveDate < sysdate + and catalog.effectiveDate >= all ( + select cat.effectiveDate + from Catalog as cat + where cat.effectiveDate < sysdate + ) +group by order +having sum(price.amount) > :minAmount +order by sum(price.amount) desc]]></programlisting> + + <para> + 괴물 같은 것! 실제로 실 생활에서, 나는 서브질의들을 매우 좋아하지 않아서, 나의 질의는 실제로 다음과 같았다: + </para> + + <programlisting><![CDATA[select order.id, sum(price.amount), count(item) +from Order as order + join order.lineItems as item + join item.product as product, + Catalog as catalog + join catalog.prices as price +where order.paid = false + and order.customer = :customer + and price.product = product + and catalog = :currentCatalog +group by order +having sum(price.amount) > :minAmount +order by sum(price.amount) desc]]></programlisting> + + <para> + 다음 질의는 현재 사용자에 의해 가장 최근의 상태 변경이 행해졌던 <literal>AWAITING_APPROVAL</literal> 상태에 있는 모든 + 지불들을 제외한, 각각의 상태에 있는 지불들의 개수를 카운트 한다. 그것은 <literal>PAYMENT</literal>, + <literal>PAYMENT_STATUS</literal>, <literal>PAYMENT_STATUS_CHANGE</literal> 테이블들에 대한 두 개의 inner + 조인들과 하나의 상관관계 지워진 subselect를 가진 SQL 질의로 변환된다. + </para> + + <programlisting><![CDATA[select count(payment), status.name +from Payment as payment + join payment.currentStatus as status + join payment.statusChanges as statusChange +where payment.status.name <> PaymentStatus.AWAITING_APPROVAL + or ( + statusChange.timeStamp = ( + select max(change.timeStamp) + from PaymentStatusChange change + where change.payment = payment + ) + and statusChange.user <> :currentUser + ) +group by status.name, status.sortOrder +order by status.sortOrder]]></programlisting> + + <para> + 만일 내가 <literal>statusChanges</literal> 콜렉션을 set가 아닌 list로 매핑했다면, 그 질의는 작성하기가 훨씬 더 + 간단했을 것이다. + </para> + + <programlisting><![CDATA[select count(payment), status.name +from Payment as payment + join payment.currentStatus as status +where payment.status.name <> PaymentStatus.AWAITING_APPROVAL + or payment.statusChanges[ maxIndex(payment.statusChanges) ].user <> :currentUser +group by status.name, status.sortOrder +order by status.sortOrder]]></programlisting> + + <para> + 다음 질의는 현재의 사용자가 속해 있는 조직의 모든 계정들과 지불되지 않은 지불들을 반환하는데 MS SQL Server + <literal>isNull()</literal> 함수를 사용한다. 그것은 <literal>ACCOUNT</literal>, <literal>PAYMENT</literal>, + <literal>PAYMENT_STATUS</literal>, <literal>ACCOUNT_TYPE</literal>, <literal>ORGANIZATION</literal>, + <literal>ORG_USER</literal> 테이블들에 대한 세 개의 inner 조인들, 하나의 outer 조인, 그리고 하나의 subselect를 가진 + 한 개의 SQL 질의로 번역된다. + </para> + + <programlisting><![CDATA[select account, payment +from Account as account + left outer join account.payments as payment +where :currentUser in elements(account.holder.users) + and PaymentStatus.UNPAID = isNull(payment.currentStatus.name, PaymentStatus.UNPAID) +order by account.type.sortOrder, account.accountNumber, payment.dueDate]]></programlisting> + + <para> + 몇몇 데이터베이스들의 경우, 우리는 (상관관계 지워진) subselect를 없앨 필요가 있을 것이다. + </para> + + <programlisting><![CDATA[select account, payment +from Account as account + join account.holder.users as user + left outer join account.payments as payment +where :currentUser = user + and PaymentStatus.UNPAID = isNull(payment.currentStatus.name, PaymentStatus.UNPAID) +order by account.type.sortOrder, account.accountNumber, payment.dueDate]]></programlisting> + + </sect1> + + <sect1 id="queryhql-bulk" revision="2"> + <title>대량 update와 delete</title> + + <para> + HQL은 이제 <literal>update</literal>, <literal>delete</literal> 그리고 + <literal>insert ... select ...</literal> 문장들을 지원한다. + 상세한 것은 <xref linkend="batch-direct"/>를 보라. + </para> + </sect1> + + <sect1 id="queryhql-tipstricks"> + <title>팁들 &amp; 트릭들</title> + + <para> + 당신은 실제로 질의 결과들을 반환하지 않고서 그것들(질의 결과들)의 개수를 카운트할 수 있다: + </para> + + <programlisting><![CDATA[( (Integer) session.createQuery("select count(*) from ....").iterate().next() ).intValue()]]></programlisting> + + <para> + 콜렉션의 크기에 따라 결과를 순서(ordering)지우려면, 다음 질의를 사용하라: + </para> + + <programlisting><![CDATA[select usr.id, usr.name +from User as usr + left join usr.messages as msg +group by usr.id, usr.name +order by count(msg)]]></programlisting> + + <para> + 만일 당신의 데이터베이스가 subselect들을 지원할 경우, 당신은 당신의 질의의 where 절 내에 selection 사이즈에 대한 조건을 + 위치지울 수 있다: + </para> + + <programlisting><![CDATA[from User usr where size(usr.messages) >= 1]]></programlisting> + + <para> + 만일 당신의 데이터베이스가 subselect를 지원하지 않을 경우, 다음 질의를 사용하라: + </para> + + <programlisting><![CDATA[select usr.id, usr.name +from User usr.name + join usr.messages msg +group by usr.id, usr.name +having count(msg) >= 1]]></programlisting> + + <para> + 이 해결책이 inner 조인 때문에 0개의 메시지를 가진 <literal>User</literal>를 반환할 수 없으므로, 다음 형식이 또한 유용하다: + </para> + + <programlisting><![CDATA[select usr.id, usr.name +from User as usr + left join usr.messages as msg +group by usr.id, usr.name +having count(msg) = 0]]></programlisting> + + <para> + 하나의 JavaBean의 프로퍼티들은 명명된 질의 파라미터들에 바인드될 수 있다: + </para> + + <programlisting><![CDATA[Query q = s.createQuery("from foo Foo as foo where foo.name=:name and foo.size=:size"); +q.setProperties(fooBean); // fooBean has getName() and getSize() +List foos = q.list();]]></programlisting> + + <para> + 콜렉션들은 필터를 가진 <literal>Query</literal> 인터페이스를 사용하여 쪼매김하는 것이 가능하다: + </para> + + <programlisting><![CDATA[Query q = s.createFilter( collection, "" ); // the trivial filter +q.setMaxResults(PAGE_SIZE); +q.setFirstResult(PAGE_SIZE * pageNumber); +List page = q.list();]]></programlisting> + + <para> + 콜렉션 요소들은 질의 필터를 사용하여 순서(ordering)지워지거나 그룹지워질 수 도 있다: + </para> + + <programlisting><![CDATA[Collection orderedCollection = s.filter( collection, "order by this.amount" ); +Collection counts = s.filter( collection, "select this.type, count(this) group by this.type" );]]></programlisting> + + <para> + 당신은 콜렉션을 초기화 하지 않고서 그것(콜렉션)의 크기를 찾을 수 있다: + </para> + + <programlisting><![CDATA[( (Integer) session.createQuery("select count(*) from ....").iterate().next() ).intValue();]]></programlisting> + + </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">row value constructors</xref>에 있다. + </para> + </sect1> + + <sect1 id="queryhql-tuple"> + <title>Row value constructor 구문</title> + + <para> + HQL은 ANSI SQL <literal>row value constructor</literal> 구문(종종 <literal>tuple</literal> 구문이라 명명된다)의 사용을 지원한다. + 비록 데이터베이스가 그 개념을 지원하지 않을지라도 그러하다. 여기서 우리는 전형적으로 컴포넌트들과 연관되어 있는 다중-값 비교들을 + 일반적으로 언급하고 있다. name 컴포넌트를 정의하는 Person 엔티티를 검토하자: + </para> + + <programlisting><![CDATA[from Person p where p.name.first='John' and p.name.last='Jingleheimer-Schmidt']]></programlisting> + + <para> + 비록 약간 장황스럽지만 그것은 유효한 구문이다. 이것을 약간 더 간결하게 만들고 + <literal>row value constructor</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>row value constructor</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> + Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/query_sql.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/query_sql.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/query_sql.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/query_sql.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,694 @@ +<?xml version="1.0" encoding="UTF-8"?> +<chapter id="querysql" revision="2"> + <title>Native SQL</title> + + <para>당신은 또한 당신의 데이터베이스의 native SQL dialect로 질의들을 표현할 수도 있다. + 당신이 오라클의 질의 힌트들 또는 <literal>CONNECT</literal> 키워드와 같은 + 데이터베이스 지정적인 특징들을 활용하고자 원할 경우에 이것이 유용하다. + 그것은 또한 직접적인 SQL/JDBC 기반의 어플리케이션으로부터 Hibernate로의 보다 명료한 + 이전 경로를 제공한다.</para> + + <para>Hibernate3은 또한 모든 create, update, delete, load 오퍼레이션들에 대해 + (내장 프로시저들을 포함하여) 손으로 작성된 SQL을 지정하는 것을 당신에게 허용해준다.</para> + + <sect1 id="querysql-creating" revision="4"> + <title><literal>SQLQuery</literal> 사용하기</title> + + <para>native SQL 질의들의 실행은 <literal>SQLQuery</literal> 인터페이스를 통해 + 제어되며, 그것은 <literal>Session.createSQLQuery()</literal>을 호출하여 + 획득된다. 다음은 이 API를 질의에 사용하는 방법을 설명한다.</para> + + <sect2> + <title>스칼라 질의들</title> + + <para>가장 기본적인 SQL 질의는 스칼라들(값들)의 목록을 얻는 + 것이다.</para> + + <programlisting><![CDATA[sess.createSQLQuery("SELECT * FROM CATS").list(); +sess.createSQLQuery("SELECT ID, NAME, BIRTHDATE FROM CATS").list(); +]]></programlisting> + + <para>이것들은 둘다 CATS 테이블 내에 있는 각각의 컬럼에 대한 스칼라 값들을 가진 Object + 배열들의 List를 반환할 것이다. Hibernate는 반환되는 스칼라 값들의 실제 순서와 타입들을 + 도출하는데 ResultSetMetadata를 사용할 것이다.</para> + + <para><literal>ResultSetMetadata</literal> 사용의 오버헤드를 피하거나 + 간단하게는 반환되는 것을 보다 명시적이게끔 하기 위해 우리는 + <literal>addScalar()</literal>를 사용할 수 있다.</para> + + <programlisting><![CDATA[sess.createSQLQuery("SELECT * FROM CATS") + .addScalar("ID", Hibernate.LONG) + .addScalar("NAME", Hibernate.STRING) + .addScalar("BIRTHDATE", Hibernate.DATE) +]]></programlisting> + + <para>이 질의는 다음을 지정했다:</para> + + <itemizedlist> + <listitem> + <para>SQL 질의 문자열</para> + </listitem> + + <listitem> + <para>반환할 컬럼들과 타입들</para> + </listitem> + </itemizedlist> + + <para>이것은 여전히 Object 배열들을 반환할 것이지만, 이제 그것은 + <literal>ResultSetMetdata</literal>를 사용하지 않을 것이고 대신에 + 기반 결과셋으로부터 ID, NAME 그리고 BIRTHDATE 컬럼을 각각 Long, String + 그리고 Short 타입으로 반환할 것이다. 심지어 그 질의가 <literal>*</literal>를 + 사용하고 세 개의 열거된 컬럼들 보다 더 많은 것을 반환할 수 있을지라도, 이것은 + 또한 오직 이들 세 개의 컬럼들 만이 반환될 것임을 의미한다.</para> + + <para>스칼라들 중 몇몇 또는 전부에 대한 타입 정보를 남겨두는 것이 가능하다.</para> + + <programlisting><![CDATA[sess.createSQLQuery("SELECT * FROM CATS") + .addScalar("ID", Hibernate.LONG) + .addScalar("NAME") + .addScalar("BIRTHDATE") +]]></programlisting> + + <para>이것은 본질적으로 앞의 것과 동일한 질의이지만, 이제 + <literal>ResultSetMetaData</literal>는 ID의 타입이 명시적으로 지정되어 있으므로 + NAME과 BIRTHDATE의 타입을 결정하는데 사용된다.</para> + + <para>java.sql.Types returned from ResultSetMetaData이 Hibernate + 타입들로 매핑되는 방법은 Dialect에 의해 제어된다. 만일 특정 타입이 매핑되지 않거나 + 예상되는 타입으로 귀결되지 않을 경우에 Dialect 내에 있는 + <literal>registerHibernateType</literal>에 대한 호출들을 통해 그것을 + 맞춤화 시키는 것이 가능하다.</para> + </sect2> + + <sect2> + <title>Entity 질의들</title> + + <para>위의 질의들은 스칼라 값들을 반환하는 것, 결과셋들로부터 "원래의" 값들을 + 기본적으로 반환하는 것에 대한 전부였다. 다음은 <literal>addEntity()</literal>를 + 통해 native sql 질의로부터 엔티티 객체들을 얻는 방법을 보여준다.</para> + + <programlisting><![CDATA[sess.createSQLQuery("SELECT * FROM CATS").addEntity(Cat.class); +sess.createSQLQuery("SELECT ID, NAME, BIRTHDATE FROM CATS").addEntity(Cat.class); +]]></programlisting> + + <para>이 질의는 다음을 지정했다:</para> + + <itemizedlist> + <listitem> + <para>SQL 질의 문자열</para> + </listitem> + + <listitem> + <para>그 질의에 의해 반환되는 엔티티</para> + </listitem> + </itemizedlist> + + <para>Cat이 컬럼 ID, NAME 그리고 BIRTHDATE로서 매핑된다고 가정하면, + 위의 질의들은 둘다 각각의 요소가 하나의 Cat 엔티티인 하나의 List를 반환할 것이다.</para> + + <para>만일 그 엔티티가 또 다른 엔티티에 대해 <literal>many-to-one</literal>로 + 매핑되어 있다면 또한 native 질의를 실행할 때 이것을 반환하는 것이 필수적고, 그 밖의 경우 + 데이터베이스 지정적인 "컬럼이 발견되지 않았습니다" 오류가 일어날 것이다. 추가적인 + 컬럼은 * 표기를 사용할 자동적으로 반환될 것이지만, 우리는 다음 <literal>Dog</literal>에 + 대한 <literal>many-to-one</literal> 예제에서처럼 명시적인 것을 더 선호한다:</para> + + <programlisting><![CDATA[sess.createSQLQuery("SELECT ID, NAME, BIRTHDATE, DOG_ID FROM CATS").addEntity(Cat.class); +]]></programlisting> + + <para>이것은 cat.getDog()이 고유하게 기능하는 것을 허용한다.</para> + </sect2> + + <sect2> + <title>연관들과 콜렉션들을 처리하기</title> + + <para>프락시를 초기화 시킴에 있어 가능한 특별한 라운드트립을 피하기 위해서 + <literal>Dog</literal>에서 eagerly join시키는 것이 간으하다. 이것은 + <literal>addJoin()</literal> 메소드를 통해 행해지는데, 그것은 + 연관이나 콜렉션 내에서 조인시키는 것을 당신에게 허용해준다.</para> + + <programlisting><![CDATA[sess.createSQLQuery("SELECT c.ID, NAME, BIRTHDATE, DOG_ID, D_ID, D_NAME FROM CATS c, DOGS d WHERE c.DOG_ID = d.D_ID") + .addEntity("cat", Cat.class) + .addJoin("cat.dog"); +]]></programlisting> + + <para>이 예제에서 반환되는 <literal>Cat</literal>들은 데이터베이스에 + 대한 임의의 특별한 라운드크립 없이 전체적으로 초기화된 그것들의 <literal>dog</literal> + 프로퍼티를 갖는다. 우리가 join의 대상 프로퍼티 경로를 지정하는 것을 가능하도록 하기 위해 + 하나의 alias 이름("cat")을 추가했음을 주지하라. 대신에 예를 들어 <literal>Cat</literal>이 + <literal>Dog</literal>에 대해 one-to-many를 가질 경우, 콜렉션들에 대해 동일한 eager joining을 + 행하는 것이 가능하다.</para> + + <programlisting><![CDATA[sess.createSQLQuery("SELECT ID, NAME, BIRTHDATE, D_ID, D_NAME, CAT_ID FROM CATS c, DOGS d WHERE c.ID = d.CAT_ID") + .addEntity("cat", Cat.class) + .addJoin("cat.dogs"); +]]></programlisting> + + <p>이 단계에서 우리는 Hibernate에서 native 질의들을 사용가능하도록 만들기 위해 + sql 질의들을 강화시키지는 것을 시작하지 않고서도 native 질의들로서 가능한 것의 한계에 + 도달하고 있다; 문제점들은 동일한 타입의 여러 엔티티들을 반환할 때 또는 디폴트 alias/column + 이름들이 충분하지 않을 때 발생하기 시작한다.</p> + </sect2> + + <sect2> + <title>여러 개의 엔티티들을 반환하기</title> + + <para>지금까지 결과 셋 컬럼 이름들은 매핑 문서 내에 지정된 컬럼 이름들과 동일하다고 가정되어 있다. + 동일한 컬럼이 하나 이상의 테이블 내에서 나타날 수 있기 때문에, 이것은 여러 개의 테이블들을 조인시키는 + SQL 질의들에 대해 문제가 될 수 있다.</para> + + <para>컬럼 alias 주입은 다음 질의(아마 실패할 것이다)에서 필요하다:</para> + + <programlisting><![CDATA[sess.createSQLQuery("SELECT c.*, m.* FROM CATS c, CATS m WHERE c.MOTHER_ID = c.ID") + .addEntity("cat", Cat.class) + .addEntity("mother", Cat.class) +]]></programlisting> + + <para>이 질의의 목적은 단위 행 당 두 개의 Cat 인스턴스들, 하나의 cat 그리고 그것의 mother를 + 반환하는 것이다. 왜냐하면 그것들이 동일한 컬럼 이름들로 매핑되어 있기 때문에 이것은 실패할 것이고 + 데이베이스 상에서 반환된 컬럼 alias들은 아마 매핑들 내에 지정된 컬럼들("ID" 와 "NAME")과 같지 않은 + "c.ID", "c.NAME" 등의 형식일 것이다.</para> + + <para>다음 형식은 컬럼 이름 중복 취약점을 갖지 않는다:</para> + + <programlisting><![CDATA[sess.createSQLQuery("SELECT {cat.*}, {mother.*} FROM CATS c, CATS m WHERE c.MOTHER_ID = c.ID") + .addEntity("cat", Cat.class) + .addEntity("mother", Cat.class) +]]></programlisting> + + <para>이 질의는 다음을 지정했다:</para> + + <itemizedlist> + <listitem> + <para>컬럼 alias들을 주입하기 위한 Hibernate용 placeholder들을 가진 SQL 질의 문자열</para> + </listitem> + + <listitem> + <para>그 질의에 의해 반환되는 엔티티들</para> + </listitem> + </itemizedlist> + + <para>위에 사용된 {cat.*} 과 {mother.*} 표기는 "모든 프로퍼티들"에 대한 생략이다. + 다른 방법으로 당신은 컬럼들을 명시적으로 열거할 수도 있지만, 이 경우에 우리는 Hibernate로 하여금 + SQL 컬럼 alias들을 각각의 컬럼에 주입시키도록 강제한다. 컬럼 alias를 위한 placeholder는 단지 + 그 테이블 alias에 의해 수식된 프로퍼티 이름이다. 다음 예제에서, 우리는 다른 테이블(cat_log)로부터 + 매핑 메타데이터 내에 선언된 것으로의 Cat들과 그것들의 mother들을 검색한다. 우리는 우리가 좋다면 + 심지어 where 절 내에 프로퍼티 alias를 사용할 수도 있음을 주지하라.</para> + + <programlisting><![CDATA[String sql = "SELECT ID as {c.id}, NAME as {c.name}, " + + "BIRTHDATE as {c.birthDate}, MOTHER_ID as {c.mother}, {mother.*} " + + "FROM CAT_LOG c, CAT_LOG m WHERE {c.mother} = c.ID"; + +List loggedCats = sess.createSQLQuery(sql) + .addEntity("cat", Cat.class) + .addEntity("mother", Cat.class).list() +]]></programlisting> + + <sect3 id="querysql-aliasreferences" revision="2"> + <title>alias 참조와 프로퍼티 참조</title> + + <para>대부분의 경우에 위의 alias 주입이 필요하지만, composite 프로퍼티들, 상속 판별자들 + (inheritance discriminators), 콜렉션 등과 같은 보다 복잡한 매핑들과 관련된 질의들의 경우에는 + 고유한 alias들을 주입시키는 것을 Hibernate에게 허용하는데 사용될 몇몇 특별한 alias들이 존재한다.</para> + + <para>다음 테이블은 alias 주입을 사용하는 다른 가능성들을 보여준다. 노트: 결과 내에 있는 alias 이름들이 + 예제이며, 각각의 alias는 사용될 때 하나의 유일한 이름과 아마 다른 이름을 가질 것이다.</para> + + <table frame="topbot" id="aliasinjection-summary"> + <title>alias 주입 이름들</title> + + <tgroup cols="3"> + <colspec colwidth="1*" /> + + <colspec colwidth="1*" /> + + <colspec colwidth="2.5*" /> + + <thead> + <row> + <entry>설명</entry> + + <entry>구문</entry> + + <entry>예제</entry> + </row> + </thead> + + <tbody> + <row> + <entry>간단한 프로퍼티</entry> + <entry><literal>{[aliasname].[propertyname]</literal></entry> + + <entry><literal>A_NAME as {item.name}</literal></entry> + </row> + + <row> + <entry>composite 프로퍼티</entry> + + <entry><literal>{[aliasname].[componentname].[propertyname]}</literal></entry> + + <entry><literal>CURRENCY as {item.amount.currency}, VALUE as {item.amount.value}</literal></entry> + </row> + + <row> + <entry>엔티티의 판별자(Discriminator)</entry> + <entry><literal>{[aliasname].class}</literal></entry> + + <entry><literal>DISC as {item.class}</literal></entry> + </row> + + <row> + <entry>엔티티의 모든 프로퍼티들</entry> + <entry><literal>{[aliasname].*}</literal></entry> + + <entry><literal>{item.*}</literal></entry> + </row> + + <row> + <entry>콜렉션 키</entry> + <entry><literal>{[aliasname].key}</literal></entry> + + <entry><literal>ORGID as {coll.key}</literal></entry> + </row> + + <row> + <entry>콜렉션의 id</entry> + <entry><literal>{[aliasname].id}</literal></entry> + + <entry><literal>EMPID as {coll.id}</literal></entry> + </row> + + <row> + <entry>콜렉션의 요소</entry> + <entry><literal>{[aliasname].element}</literal></entry> + + <entry><literal>XID as {coll.element}</literal></entry> + <entry></entry> + </row> + + <row> + <entry>콜렉션 내에 있는 요소의 프로퍼티</entry> + <entry><literal>{[aliasname].element.[propertyname]}</literal></entry> + + <entry><literal>NAME as {coll.element.name}</literal></entry> + </row> + + <row> + <entry>콜렉션 내에 있는 요소의 모든 프로퍼티들</entry> + <entry><literal>{[aliasname].element.*}</literal></entry> + + <entry><literal>{coll.element.*}</literal></entry> + </row> + + <row> + <entry>콜렉션의 모든 프로퍼티들</entry> + <entry><literal>{[aliasname].*}</literal></entry> + + <entry><literal>{coll.*}</literal></entry> + </row> + </tbody> + </tgroup> + </table> + </sect3> + </sect2> + + <sect2> + <title>non-managed 엔티티들을 반환하기</title> + + <para>native sql 질의에 ResultTransformer를 적용하는 것이 가능하다. 예를 들어 + non-managed 엔티티들을 반환하기 위해 ResultTransformer를 허용하는 것.</para> + + <programlisting><![CDATA[sess.createSQLQuery("SELECT NAME, BIRTHDATE FROM CATS") + .setResultTransformer(Transformers.aliasToBean(CatDTO.class))]]></programlisting> + + <para>이 질의는 다음을 지정했다:</para> + + <itemizedlist> + <listitem> + <para>SQL 질의 문자열</para> + </listitem> + + <listitem> + <para>결과 변환자(transformer)</para> + </listitem> + </itemizedlist> + + <para> + 위의 질의는 초기화되어 있고 NAME과 BIRTHNAME의 값들을 <literal>CatDTO</literal>의 + 대응하는 프로퍼티들과 필드들 속으로 주입시킨 <literal>CatDTO</literal>의 리스트를 반환할 것이다. + </para> + </sect2> + + <sect2> + <title>상속 처리하기</title> + + <para>상속의 부분으로서 매핑되는 엔티티들을 질의하는 native sql 질의들은 baseclass의 + 모든 프로퍼티들을 포함해야 하고 그 모든 것이 서브클래스화 되어야 한다.</para> + </sect2> + + <sect2> + <title>파라미터들</title> + + <para>Native sql 질의들은 위치 파라미터들 뿐만 아니라 명명된 파라미터들을 지원한다:</para> + + <programlisting><![CDATA[Query query = sess.createSQLQuery("SELECT * FROM CATS WHERE NAME like ?").addEntity(Cat.class); +List pusList = query.setString(0, "Pus%").list(); + +query = sess.createSQLQuery("SELECT * FROM CATS WHERE NAME like :name").addEntity(Cat.class); +List pusList = query.setString("name", "Pus%").list(); ]]></programlisting> + </sect2> + + + + </sect1> + + <sect1 id="querysql-namedqueries" revision="3"> + <title>명명된 SQL 질의들</title> + + <para> + 명명된 SQL 질의들은 HQL 질의와 동일한 방법으로 매핑 문서 속에 정의될 수 있고 정확하게 호출될 수도 있다. 이 경우에, 우리는 + <literal>addEntity()</literal> 호출을 필요로 하지 <emphasis>않는다</emphasis>. + </para> + + <programlisting><![CDATA[<sql-query name="persons"> + <return alias="person" class="eg.Person"/> + SELECT person.NAME AS {person.name}, + person.AGE AS {person.age}, + person.SEX AS {person.sex} + FROM PERSON person + WHERE person.NAME LIKE :namePattern +</sql-query>]]></programlisting> + + <programlisting><![CDATA[List people = sess.getNamedQuery("persons") + .setString("namePattern", namePattern) + .setMaxResults(50) + .list();]]></programlisting> + + <para><literal>&lt;return-join&gt;</literal> 요소와 + <literal>&lt;load-collection&gt;</literal> + 요소는 연관들을 조인시키고 콜렉션들을 각각 초기화 시키는 질의들을 + 정의하는데 사용된다.</para> + + <programlisting><![CDATA[<sql-query name="personsWith"> + <return alias="person" class="eg.Person"/> + <return-join alias="address" property="person.mailingAddress"/> + SELECT person.NAME AS {person.name}, + person.AGE AS {person.age}, + person.SEX AS {person.sex}, + address.STREET AS {address.street}, + address.CITY AS {address.city}, + address.STATE AS {address.state}, + address.ZIP AS {address.zip} + FROM PERSON person + JOIN ADDRESS address + ON person.ID = address.PERSON_ID AND address.TYPE='MAILING' + WHERE person.NAME LIKE :namePattern +</sql-query>]]></programlisting> + + <para>명명된 SQL 질의는 스칼라 값을 반환할수도 있다. 당신은 + <literal>&lt;return-scalar&gt;</literal> 요소를 사용하여 + 컬럼 alias와 Hibernate 타입을 선언해야 한다:</para> + + <programlisting><![CDATA[<sql-query name="mySqlQuery"> + <return-scalar column="name" type="string"/> + <return-scalar column="age" type="long"/> + SELECT p.NAME AS name, + p.AGE AS age, + FROM PERSON p WHERE p.NAME LIKE 'Hiber%' +</sql-query>]]></programlisting> + + <para>당신은 여러 개의 명명된 질의들을 가로질러 재사용하거나 <literal>setResultSetMapping()</literal> API를 통해 결과셋 + 매핑정보들을 재사용하기 위해 <literal>&lt;resultset&gt;</literal> 요소 속에 결과셋 매핑 정보들을 구체화 시킬 수 있다.</para> + + <programlisting><![CDATA[<resultset name="personAddress"> + <return alias="person" class="eg.Person"/> + <return-join alias="address" property="person.mailingAddress"/> +</resultset> + +<sql-query name="personsWith" resultset-ref="personAddress"> + SELECT person.NAME AS {person.name}, + person.AGE AS {person.age}, + person.SEX AS {person.sex}, + address.STREET AS {address.street}, + address.CITY AS {address.city}, + address.STATE AS {address.state}, + address.ZIP AS {address.zip} + FROM PERSON person + JOIN ADDRESS address + ON person.ID = address.PERSON_ID AND address.TYPE='MAILING' + WHERE person.NAME LIKE :namePattern +</sql-query>]]></programlisting> + + <para>다른방법으로 당신은 당신의 hbm 파일들 내에 직접 자바 코드로 된 결과셋 매핑 정보를 사용할 수 있다.</para> + + <programlisting><![CDATA[List cats = sess.createSQLQuery( + "select {cat.*}, {kitten.*} from cats cat, cats kitten where kitten.mother = cat.id" + ) + .setResultSetMapping("catAndKitten") + .list();]]></programlisting> + + <sect2 id="propertyresults"> + <title>명시적으로 column/alias 이름들을 지정하는데 return-property 사용하기</title> + + <para>Hibernate로 하여금 그것 자신의 alias들을 끼워넣도록 하기 위해 + <literal>{}</literal>-구문을 사용하는 것 대신에, + <literal>&lt;return-property&gt;</literal>로서 당신은 사용할 + 컬럼 alias들이 무엇인지를 Hibernate에게 명시적으로 알려줄 수 있다.</para> + + <programlisting><![CDATA[<sql-query name="mySqlQuery"> + <return alias="person" class="eg.Person"> + <return-property name="name" column="myName"/> + <return-property name="age" column="myAge"/> + <return-property name="sex" column="mySex"/> + </return> + SELECT person.NAME AS myName, + person.AGE AS myAge, + person.SEX AS mySex, + FROM PERSON person WHERE person.NAME LIKE :name +</sql-query> +]]></programlisting> + + <para><literal>&lt;return-property&gt;</literal>는 또한 다중 컬럼들에 대해 동작한다. + 이것은 다중-컬럼 프로퍼티들에 대한 fine grained 제어를 허용할 수 없는 + <literal>{}</literal>-구문을 가진 제약을 해결해준다.</para> + + <programlisting><![CDATA[<sql-query name="organizationCurrentEmployments"> + <return alias="emp" class="Employment"> + <return-property name="salary"> + <return-column name="VALUE"/> + <return-column name="CURRENCY"/> + </return-property> + <return-property name="endDate" column="myEndDate"/> + </return> + SELECT EMPLOYEE AS {emp.employee}, EMPLOYER AS {emp.employer}, + STARTDATE AS {emp.startDate}, ENDDATE AS {emp.endDate}, + REGIONCODE as {emp.regionCode}, EID AS {emp.id}, VALUE, CURRENCY + FROM EMPLOYMENT + WHERE EMPLOYER = :id AND ENDDATE IS NULL + ORDER BY STARTDATE ASC +</sql-query>]]></programlisting> + + <para>이 예제에서 우리는 끼워넣기(injection)를 위해 <literal>{}</literal>-구문과 함께 <literal>&lt;return-property&gt;</literal>를 + 사용했음을 주목하라. 사용자들이 컬럼과 프로퍼티들을 참조하고자 원하는 방법을 선택하는 것을 사용자들에게 허용해줌으로써.</para> + + <para>만일 당신의 매핑이 한 개의 판별자(discriminator )를 가질 경우 당신은 판별자 컬럼을 지정하는데 + <literal>&lt;return-discriminator&gt;</literal>를 사용해야 한다.</para> + </sect2> + + <sect2 id="sp_query" revision="1"> + <title>질의를 위한 내장 프로시저 사용하기</title> + + <para>Hibernate 3은 내장 프로시저들과 함수들을 통한 질의 지원을 도입한다. 대부분의 다음 문서는 양자 모두에 동일하게 적용된다. + 내장 프로시저/함수는 Hibernate와 동작하는 것이 가능하도록 첫 번째 out-파라미터로서 한 개의 결과셋을 반환해야 한다. + Oracle9 이상의 버전에서 그런 내장 프로시저에 대한 예제는 다음과 같다:</para> + + <programlisting><![CDATA[CREATE OR REPLACE FUNCTION selectAllEmployments + RETURN SYS_REFCURSOR +AS + st_cursor SYS_REFCURSOR; +BEGIN + OPEN st_cursor FOR + SELECT EMPLOYEE, EMPLOYER, + STARTDATE, ENDDATE, + REGIONCODE, EID, VALUE, CURRENCY + FROM EMPLOYMENT; + RETURN st_cursor; + END;]]></programlisting> + + <para>Hibernate에서 이 질의를 사용하기 위해 당신은 하나의 명명된 질의(a named query)를 통해 + 그것을 매핑할 필요가 있다.</para> + + <programlisting><![CDATA[<sql-query name="selectAllEmployees_SP" callable="true"> + <return alias="emp" class="Employment"> + <return-property name="employee" column="EMPLOYEE"/> + <return-property name="employer" column="EMPLOYER"/> + <return-property name="startDate" column="STARTDATE"/> + <return-property name="endDate" column="ENDDATE"/> + <return-property name="regionCode" column="REGIONCODE"/> + <return-property name="id" column="EID"/> + <return-property name="salary"> + <return-column name="VALUE"/> + <return-column name="CURRENCY"/> + </return-property> + </return> + { ? = call selectAllEmployments() } +</sql-query>]]></programlisting> + + <para>내장 프로시저들은 현재 스칼라들과 엔티티들 만을 반환함을 주목하라. <literal>&lt;return-join&gt;</literal>과 + <literal>&lt;load-collection&gt;</literal>은 지원되지 않는다.</para> + + <sect3 id="querysql-limits-storedprocedures" revision="1"> + <title>내장 프로시저들을 사용하는 규칙들/제약들</title> + + <para>Hibernate에서 내장 프로시저들을 사용하기 위해서 프로시저들/함수들은 다음 몇몇 규칙들을 따라야 한다. 만일 그것들이 그들 규칙들을 + 따르지 않을 경우 그것들은 Hibernate와 함께 사용 불가능하다. 만일 당신이 여전히 이들 프로시저들을 사용하고자 원할 경우, + 당신은 <literal>session.connection()</literal>을 통해 그것들을 실행시켜야 한다. 데이터베이스 벤더들이 다른 내장 + 프로시저 의미론/구문을 갖고 있기 때문에, 규칙들은 각각의 데이터베이스에 따라 차이가 난다.</para> + + <para>내장 프로시저 질의들은 <literal>setFirstResult()/setMaxResults()</literal>로서 쪽매김 될 수 없다.</para> + + <para>권장되는 호출 형식은 표준 SQL92이다: <literal>{ ? = call + functionName(&lt;parameters&gt;) }</literal> 또는 <literal>{ ? = call + procedureName(&lt;parameters&gt;}</literal>. Native 호출 구문은 지원되지 않는다.</para> + + <para>Oracle의 경우 다음 규칙들이 적용된다:</para> + + <itemizedlist spacing="compact"> + <listitem> + <para>하나의 함수는 하나의 결과 셋을 반환해야 한다. 프로시저의 첫 번째 파라미터는 하나의 결과 셋을 반환하는 + 하나의 <literal>OUT</literal>이어야 한다. 이것은 Oracle 9 또는 10에서 하나의 + <literal>SYS_REFCURSOR</literal>를 사용하여 행해진다. Oracle에서 당신은 + <literal>REF CURSOR</literal> 타입을 정의할 필요가 있는데, Oracle 보고서를 보라.</para> + </listitem> + </itemizedlist> + + <para>Sybase 또는 MS SQL server의 경우 다음 규칙들이 적용된다:</para> + + <itemizedlist spacing="compact"> + <listitem> + <para>프로시저는 한 개의 결과 셋을 반환해야 한다. 이들 서버들이 여러 개의 결과셋들과 업데이트 카운트들을 반환 할수 있다/할 것이이므로, + Hibernate는 결과들을 반복 순환할 것이고 그것의 반환 값으로서 하나의 결과 셋인 첫 번째 결과를 취할 것이다. 그 밖의 모든 것은 + 폐기될 것이다.</para> + </listitem> + <listitem> + <para>만일 당신이 당신의 프로시저 내에 <literal>SET NOCOUNT ON</literal>을 이용 가능하게 할 수 있다면 그것은 아마 + 보다 효율적이게 될 것이지만 이것은 필요 조건이 아니다.</para> + </listitem> + </itemizedlist> + </sect3> + </sect2> + </sect1> + + <sect1 id="querysql-cud"> + <title>create, update 그리고 delete를 위한 맞춤형 SQL</title> + + <para>Hibernate3는 create, update, delete 오퍼레이션들을 위한 맞춤형 문장들을 사용할 수 있다. Hibernate에서 클래스와 콜렉션 + 영속자들은 구성 시에 생성된 문자열들의 집합(insertsql, deletesql, updatesql 등)을 이미 포함하고 있다. + <literal>&lt;sql-insert&gt;</literal>, <literal>&lt;sql-delete&gt;</literal>, + <literal>&lt;sql-update&gt;</literal> 매핑 태그들은 이들 문자열들을 오버라이드 시킨다:</para> + + <programlisting><![CDATA[<class name="Person"> + <id name="id"> + <generator class="increment"/> + </id> + <property name="name" not-null="true"/> + <sql-insert>INSERT INTO PERSON (NAME, ID) VALUES ( UPPER(?), ? )</sql-insert> + <sql-update>UPDATE PERSON SET NAME=UPPER(?) WHERE ID=?</sql-update> + <sql-delete>DELETE FROM PERSON WHERE ID=?</sql-delete> +</class>]]></programlisting> + + <para>SQL이 당신의 데이터베이스 내에서 직접 실행되어서, 당신이 좋아하는 임의의 dialect를 사용하는 것이 자유롭다. 만일 당신이 데이터베이스 + 지정적인 SQL을 사용할 경우 이것은 물론 당신의 매핑의 이식성을 감소시킬 것이다.</para> + + <para>만일 <literal>callable</literal> 속성이 설정되면 내장 프로시저들이 지원된다:</para> + + <programlisting><![CDATA[<class name="Person"> + <id name="id"> + <generator class="increment"/> + </id> + <property name="name" not-null="true"/> + <sql-insert callable="true">{call createPerson (?, ?)}</sql-insert> + <sql-delete callable="true">{? = call deletePerson (?)}</sql-delete> + <sql-update callable="true">{? = call updatePerson (?, ?)}</sql-update> +</class>]]></programlisting> + + <para>위치 파라미터들은 Hibernate가 그것들을 기대하는 것과 같은 순서가 되어야 하므로, + 위치 파라미터들의 순서는 현재 절대적으로 중요하다.</para> + + <para>당신은 <literal>org.hiberate.persister.entity</literal> 레벨로 디버그 로깅을 사용 가능하게 함으로써 예상된 순서를 볼 수 + 있다. 이 레벨을 이용 가능하게 하면 Hibernate는 엔티티들을 생성시키고, 업데이트하고, 삭제하는데 사용되는 정적인 SQL을 출력할 것이다. + (예상되는 결과를 보려면, Hibernate 생성된 정적인 sql을 오버라이드 시키게 매핑 파일들 속에 당신의 맞춤형 SQL을 포함시키지 않도록 염두에 + 두라.)</para> + + <para>Hibernate가 문장의 성공을 위해 몇몇 실행 시 체크들을 행하므로, 내장 프로시저들은 대부분의 경우들(읽기:다른 경우들 보다 그것을 더 잘 + 행한다)에서 insert되고/업데이트되고/삭제된 행들의 개수를 반환하는데 필요하다. Hibernate는 항상 CUD 오퍼레이션들에 대한 숫자 + 출력 파라미터로서 첫 번째 문장 파라미터를 등록시킨다:</para> + + <programlisting><![CDATA[CREATE OR REPLACE FUNCTION updatePerson (uid IN NUMBER, uname IN VARCHAR2) + RETURN NUMBER IS +BEGIN + + update PERSON + set + NAME = uname, + where + ID = uid; + + return SQL%ROWCOUNT; + +END updatePerson;]]></programlisting> + </sect1> + + <sect1 id="querysql-load"> + <title>로딩을 위한 맞춤형 SQL</title> + + <para>당신은 또한 엔티티 로딩을 위한 당신 자신의 SQL (또는 HQL)을 선언할 수도 있다:</para> + + <programlisting><![CDATA[<sql-query name="person"> + <return alias="pers" class="Person" lock-mode="upgrade"/> + SELECT NAME AS {pers.name}, ID AS {pers.id} + FROM PERSON + WHERE ID=? + FOR UPDATE +</sql-query>]]></programlisting> + + <para>이것은 앞서 논의했듯이 단지 명명된 질의 선언이다. 당신은 class 매핑 속에 이 명명된 질의를 참조할 수 있다:</para> + + <programlisting><![CDATA[<class name="Person"> + <id name="id"> + <generator class="increment"/> + </id> + <property name="name" not-null="true"/> + <loader query-ref="person"/> +</class>]]></programlisting> + + <para>이것은 심지어 내장 프로시저들에 동작한다.</para> + + <para>당신은 콜렉션 로딩을 위한 한 개의 질의를 정의할 수도 있다:</para> + + <programlisting><![CDATA[<set name="employments" inverse="true"> + <key/> + <one-to-many class="Employment"/> + <loader query-ref="employments"/> +</set>]]></programlisting> + + <programlisting><![CDATA[<sql-query name="employments"> + <load-collection alias="emp" role="Person.employments"/> + SELECT {emp.*} + FROM EMPLOYMENT emp + WHERE EMPLOYER = :id + ORDER BY STARTDATE ASC, EMPLOYEE ASC +</sql-query>]]></programlisting> + + <para>당신은 심지어 조인 페칭에 의해 하나의 콜렉션을 로드시키는 하나의 엔티티를 정의할 수 있다:</para> + + <programlisting><![CDATA[<sql-query name="person"> + <return alias="pers" class="Person"/> + <return-join alias="emp" property="pers.employments"/> + SELECT NAME AS {pers.*}, {emp.*} + FROM PERSON pers + LEFT OUTER JOIN EMPLOYMENT emp + ON pers.ID = emp.PERSON_ID + WHERE ID=? +</sql-query>]]></programlisting> + </sect1> +</chapter> \ No newline at end of file Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/quickstart.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/quickstart.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/quickstart.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/quickstart.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,572 @@ +<chapter id="quickstart"> + <title>Tomcat으로 빠른 시작</title> + + <sect1 id="quickstart-intro" revision="2"> + <title>Hibernate 시작하기</title> + + <para> + 이 튜토리얼은 웹 기반의 어플리케이션 용 Apache Tomcat 서블릿 컨테이너에 대한 Hibernate 3.0 셋업을 + 설명한다(우리는 버전 4.1을 사용했다. 5.0에 대한 차이점들은 적을 것이다). Hibernate는 모든 주요 J2EE + 어플리케이션 서버들의 관리되는 환경에서 잘 동작하고, 또는 심지어 스탠드얼론 어플리케이션들에서도 잘 동작 + 한다. 이 튜토리얼에 사용되는 데이터베이스 시스템은 PostgreSQL 7.4이고, 다른 데이터베이스에 대한 지원은 + 단지 Hibernate SQL dialect 구성과 커넥션 프로퍼티들을 변경시키는 것에만 관계된다. + </para> + + <para> + 먼저 우리는 모든 필수적인 라이브러리들을 Tomcat 설치 장소에 복사해야 한다. 우리는 이 튜토리얼을 위해 별도의 + 웹 컨텍스트(<literal>webapps/quickstart</literal>)를 사용하며, 따라서 우리는 전역 라이브러리 검색 경로 + (<literal>TOMCAT/common/lib</literal>)와 <literal>webapps/quickstart/WEB-INF/lib</literal> + (JAR 파일들의 경우)와 <literal>webapps/quickstart/WEB-INF/classes</literal> 내 에 있는 컨텍스트 + 레벨에서 클래스로더 양자를 고려해야 한다. 우리는 두 개의 클래스로더 레벨들을 전역 classpath와 컨텍스트 + classpath로서 언급한다. + </para> + + <para> + 이제 라이브러리들을 두 개의 classpath들에 복사하라: + </para> + + <orderedlist> + <listitem> + <para> + 데이터베이스 용 JDBC 드라이버를 전역 classpath로 복사하라. 이것은 Tomcat에 번들로구성된 DBCP 커넥션 + 풀 소프트웨어에 필요하다. Hibernate는 데이터베이스 상에서 SQL을 실행시키는데 JDBC 커넥션들을 사용하므로, + 당신은 풀링된 JDBC 커넥션들을 제공해야 하거나, 직접 지원되는 풀들(C3P0, Proxool) 중 하나를 사용하기 + 위해 Hibernate를 구성해야 한다. 이 튜토리얼을 위해, (PostgreSQL 7.4와 JDK 1.4용) <literal>pg74jdbc3.jar</literal> + 라이브러리를 전역 classloaders 경로로 복사하라. 만일 당신이 다른 데이터베이스를 사용하고자 원할 경우, + 간단하게 그것의 적절한 JDBC 드라이버를 복사하라. + </para> + </listitem> + <listitem> + <para> + 그 밖의 어떤 것을 Tomcat 내의 전역 클래스로더 경로에 복사하지 말라. 또는 당신은 Log4j, commons-logging + 그리고 다른 것들을 포함하는 여러 가지 도구들에 관련된 문제점들을 얻게 될 것이다. 각각의 웹 어플리케이션에 대해 + 컨텍스트 classpath를 사용하라. 즉 라이브러리들을 <literal>WEB-INF/lib</literal>에 복사하고, 당신 자신의 클래스들과 + 구성 파일들/프로퍼티 파일들을 <literal>WEB-INF/classes</literal>에 복사하라. 두 디렉토리들 양자는 디폴트로 컨텍스트 + classpath 내에 있다. + </para> + </listitem> + <listitem> + <para> + Hibernate는 JAR 라이브러리로서 패키지화 되어 있다. <literal>hibernate3.jar</literal> 파일은 어플리케이션의 다른 클래스들과 + 함께 컨텍스트 classpath 속에 복사되어야 한다. Hibernate는 실행 시에 어떤 제 3의 라이브러리들을 필요로하고, + 이것들은 <literal>lib/</literal> 디렉토리 내의 Hibernate 배포본에 번들화되어 있다; <xref linkend="3rdpartylibs"/>를 + 보라. 필요한 제3의 라이브러리들을 컨텍스트 classpath로 복사하라. + </para> + </listitem> + </orderedlist> + + <table frame="topbot" id="3rdpartylibs"> + <title> + Hibernate 제3의 라이브러리 + </title> + <tgroup cols="2" rowsep="1" colsep="1"> + <colspec colname="c1" colwidth="1*"/> + <colspec colname="c2" colwidth="2*"/> + <thead> + <row> + <entry align="center"> + 라이브러리 + </entry> + <entry align="center"> + 설명 + </entry> + </row> + </thead> + <tbody> + <row> + <entry> + antlr (필수) + </entry> + <entry> + Hibernate는 질의 파서들을 산출하는데 ANTLR을 사용하고, 이 라이브러리는 또한 + 실행 시에 필요하다. + </entry> + </row> + <row> + <entry> + dom4j (필수) + </entry> + <entry> + Hibernate는 XML 구성과 XML 매핑 메타데이터 파일들을 파싱하는데 dom4j를 사용 + 한다. + </entry> + </row> + <row> + <entry> + CGLIB, asm (필수) + </entry> + <entry> + Hibernate는 (Java reflection과 결합하여) 런타임 시에 클래스들을 고양시키는데 + 코드 생성 라이브러리를 사용한다. + </entry> + </row> + <row> + <entry> + Commons Collections, Commons Logging (필수) + </entry> + <entry> + Hibernate는 Apache Jakarta Commons 프로젝트로부터 다양한 유틸리티 라이브러리 + 들을 사용한다. + </entry> + </row> + <row> + <entry> + EHCache (필수) + </entry> + <entry> + Hibernate는 second-level 캐시를 위한 다양한 캐시 프로바이더들을 사용할 수 있다. + 만일 구성에서 변하지 않을 경우 EHCache가 디폴트 캐시 프로바이더이다. + </entry> + </row> + <row> + <entry> + Log4j (옵션) + </entry> + <entry> + Hibernate는 기본 로깅 메커니즘으로서 Log4j를 사용할 수 있는, Commons Logging + API를 사용한다. 만일 Log4j 라이브러리가 컨텍스트 라이브러리 디렉토리 속에서 이용 + 가능하다면, Commons Logging은 Log4j와 컨텍스트 classpath 내에 있는 <literal>log4j.properties</literal> + 구성을 사용할 것이다. Log4j에 대한 예제 properties 파일은 Hibernate 배포본에 + 번들화 되어 있다. 따라서 당신이 이면에서 무엇이 진행되는 지을 보고자 원할 경우에 log4j.jar와 + (<literal>src/</literal>에 있는) 구성 파일을 당신의 컨텍스트 classpath 속으로 복사하라. + </entry> + </row> + <row> + <entry> + 필수 여부? + </entry> + <entry> + Hibernate 배포본 내에 있는 <literal>lib/README.txt</literal> 파일을 살펴보라. + 이것은 Hibernate에 배포된 제 3의 라이브러리들의 최신 목록이다. 당신은 그곳에 열거된 + 모든 필수 라이브러리들과 옵션 라이브러리들을 찾게 될 것이다(여기서 "빌드 시 필요함"은 + 당신의 어플리케이션이 아니라 Hibernate에 대한 의미임을 노트하라). + </entry> + </row> + </tbody> + </tgroup> + </table> + + <para> + 우리는 이제 Tomcat과 Hibernate 양자에서 데이터베이스 커넥션 풀링과 공유를 설정한다. 이것은 Tomcat이 + (그것의 미리 빌드되어 있는 DBCP 풀링 특징을 사용하여) 풀링된 JDBC 커넥션들을 제공할 것이고, Hibernate가 + JNDI를 통해 이들 커넥션들을 요청한다는 것을 의미한다. 달리 당신은 Hibernate로 하여금 커넥션 풀을 관리하도록 + 할 수 있다. Tomcat은 그것의 커넥션 풀을 JNDI에 바인드 시킨다; 우리는 리소스 선언을 Tomcat 메인 구성 파일인 + <literal>TOMCAT/conf/server.xml</literal>에 추가한다: + </para> + + <programlisting><![CDATA[<Context path="/quickstart" docBase="quickstart"> + <Resource name="jdbc/quickstart" scope="Shareable" type="javax.sql.DataSource"/> + <ResourceParams name="jdbc/quickstart"> + <parameter> + <name>factory</name> + <value>org.apache.commons.dbcp.BasicDataSourceFactory</value> + </parameter> + + <!-- DBCP database connection settings --> + <parameter> + <name>url</name> + <value>jdbc:postgresql://localhost/quickstart</value> + </parameter> + <parameter> + <name>driverClassName</name><value>org.postgresql.Driver</value> + </parameter> + <parameter> + <name>username</name> + <value>quickstart</value> + </parameter> + <parameter> + <name>password</name> + <value>secret</value> + </parameter> + + <!-- DBCP connection pooling options --> + <parameter> + <name>maxWait</name> + <value>3000</value> + </parameter> + <parameter> + <name>maxIdle</name> + <value>100</value> + </parameter> + <parameter> + <name>maxActive</name> + <value>10</value> + </parameter> + </ResourceParams> +</Context>]]></programlisting> + + <para> + 우리가 이 예제에서 구성하는 컨텍스트는 <literal>quickstart</literal>로 명명되고, 그것의 베이스는 + <literal>TOMCAT/webapp/quickstart</literal> 디렉토리이다. 임의의 서블릿들에 접근하기 위해, + (물론 당신의 <literal>web.xml</literal> 속에 매핑된 서블릿의 이름을 추가하여) 당신의 브라우저에서 + <literal>http://localhost:8080/quickstart</literal> 경로를 호출하라. 당신은 또한 계속 진행하고 + 이제 공백의 <literal>process()</literal> 메소드를 가진 간단한 서블릿을 생성시킬 수 있다. + </para> + + <para> + Tomcat은 이제 <literal>java:comp/env/jdbc/quickstart</literal>로 JNDI을 통해 커넥션들을 제공한다. + 만일 당신이 실행 중인 커넥션 풀을 얻는 것에 문제가 있다면 Tomcat 문서를 참조하라. 당신이 JDBC 드라이버 예외상황 + 메시지를 얻을 경우, 먼저 Hibernate 없이 JDBC 커넥션 풀을 셋업하라. Tomcat &amp; JDBC 튜토리얼들은 + 그 웹 서이트에서 이용 가능하다. + </para> + + <para> + 당신의 다음 단계는 Hibernate를 구성하는 것이다. Hibernate는 그것이 JDBC 커넥션들을 얻는 방법을 알고 있어야 한다. + 우리는 Hibernate의 XML 기반 구성을 사용한다. properties 파일을 사용하는 다른 접근법은 거의 동일하지만 XML + 구문이 허용하는 몇몇 특징들을 누락하고 있다. XML 구성 파일은 <literal>hibernate.cfg.xml</literal>로서 + 컨텍스트 classpath (<literal>WEB-INF/classes</literal>) 내에 위치해 있다: + </para> + + <programlisting><![CDATA[<?xml version='1.0' encoding='utf-8'?> +<!DOCTYPE hibernate-configuration PUBLIC + "-//Hibernate/Hibernate Configuration DTD//EN" + "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd"> + +<hibernate-configuration> + + <session-factory> + + <property name="connection.datasource">java:comp/env/jdbc/quickstart</property> + <property name="show_sql">false</property> + <property name="dialect">org.hibernate.dialect.PostgreSQLDialect</property> + + <!-- Mapping files --> + <mapping resource="Cat.hbm.xml"/> + + </session-factory> + +</hibernate-configuration>]]></programlisting> + + <para> + 우리는 SQL 명령들에 대한 로깅을 사용하지 않고 Hibernate에게 사용되는 데이터베이스 SQL direct가 무엇인지 + 그리고 (Tomcat 바인드된 풀의 JNDI 주소를 선언하여) JDBC 커넥션들을 얻는 곳을 알려준다. dialect는 + 필수적인 설정이고, 데이터베이스들은 SQL "표준"에 대한 그것들의 해석을 달리한다. Hibernate는 차이점들을 + 처리하고 모든 주요 상용 데이터베이스들 및 오픈 소스 데이터베이스들 용도의 direct들을 번들로 포함하고 있다. + </para> + + <para> + <literal>SessionFactory</literal>는 단일 데이터저장소에 관한 개념이고, 여러 데이터베이스들은 여러 + 개의 XML 구성 파일들을 생성시키고 당신의 어플리케이션 속에서 여러 개의 <literal>Configuration</literal> + 및 <literal>SessionFactory</literal> 객체들을 생성시켜서 사용될 수 있다. + </para> + + <para> + <literal>hibernate.cfg.xml</literal>의 마지막 요소는 영속 클래스 <literal>Cat</literal>에 대한 + Hibernate XML 매핑 파일의 이름으로써 <literal>Cat.hbm.xml</literal>을 선언한다. 이 파일은 데이터베이스 + 테이블(또는 테이블들)로 POJO 클래스 <literal>Cat</literal> 을 매핑시키는 메타데이터를 포함한다. 우리는 + 곧 그 파일로 되돌아 갈 것이다. 먼저 POJO 클래스를 작성하고 그런 다음 그것을 위한 매핑 메타데이터를 선언하자. + </para> + + </sect1> + + <sect1 id="quickstart-persistentclass" revision="1"> + <title>첫 번째 영속 클래스</title> + + <para> + Hibernate는 영속 클래스들에 대한 Plain Old Java Objects (POJOs, 종종 Plain Ordinary Java Objects로 + 명명된다) 프로그래밍 모형으로 가장 잘 동작한다. POJO는 공용으로 가시적인 인터페이스로부터 내부적인 표상을 은폐시켜, + getter와 setter 메소드들을 통해 접근가능한 클래스들의 프로퍼티들을 가진 자바빈과 꽤 유사하다(필요하다면 Hibernate는 + 또한 필드들에 직접 접근할 수 있다): + </para> + + <programlisting><![CDATA[package org.hibernate.examples.quickstart; + +public class Cat { + + private String id; + private String name; + private char sex; + private float weight; + + public Cat() { + } + + public String getId() { + return id; + } + + private void setId(String id) { + this.id = id; + } + + public String getName() { + return name; + } + + public void setName(String name) { + this.name = name; + } + + public char getSex() { + return sex; + } + + public void setSex(char sex) { + this.sex = sex; + } + + public float getWeight() { + return weight; + } + + public void setWeight(float weight) { + this.weight = weight; + } + +}]]></programlisting> + + <para> + Hibernate는 그것의 프로퍼티 타입들의 사용에 제약되지 않고, 자바 콜렉션 프레임웍에서의 클래스들을 포함하여, 모든 + 자바 JDK 타입들과 (<literal>String</literal>, <literal>char</literal>와 <literal>Date</literal> + 같은) 원시타입들이 매핑될 수 있다. 당신은 그것을 값들로서, 값들을 가진 콜렉션들로서, 또는 다른 엔티티들에 대한 + 연관들로서 매핑시킬 수 있다. <literal>id</literal>는 그 클래스의 데이터베이스 식별자(프라이머리 키)를 표현하는 + 특별한 프로퍼티이고, 그것은 <literal>Cat</literal>과 같은 엔티티들에 대해 매우 권장된다. Hibernate는 내부적으로만 + 식별자들을 사용할 수 있지만, 우리는 우리의 어플리케이션 아키텍처에서 어떤 유연성을 상실하게 될 것이다. + </para> + + <para> + 특정 인터페이스는 영속 클래스들에 대해 구현되지 말아야 하거나 특정 루트 영속 클래스로부터 서브 클래스로 만들지 말아야 한다. + Hibernate는 또한 바이트 코드 처리와 같은, 어떤 빌드 시 처리를 필요로 하지 않고, 그것은 오직 자바 reflection과 + (CGLIB를 통한) 런타임 클래스 고양에만 의존한다. 따라서 Hibernate에 대한 POJO 클래스의 어떤 의존성 없이도, 우리는 + 그것을 데이터베이스 테이블로 매핑할 수 있다. + </para> + + </sect1> + + <sect1 id="quickstart-mapping" revision="2"> + <title>cat 매핑하기</title> + + <para> + <literal>Cat.hbm.xml</literal> 매핑파일은 객체/관계형 매핑에 필요한 메타데이터를 포함한다. 메타데이터는 영속 + 클래스들의 선언과 데이터베이스 테이블들에 대한 (컬럼들과 다른 엔티티들에 대한 foreign 키 관계들에 대한) 프로퍼티들의 + 매핑을 포함한다. + </para> + + <programlisting><![CDATA[<?xml version="1.0"?> +<!DOCTYPE hibernate-mapping PUBLIC + "-//Hibernate/Hibernate Mapping DTD 3.0//EN" + "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> + +<hibernate-mapping> + + <class name="org.hibernate.examples.quickstart.Cat" table="CAT"> + + <!-- A 32 hex character is our surrogate key. It's automatically + generated by Hibernate with the UUID pattern. --> + <id name="id" type="string" unsaved-value="null" > + <column name="CAT_ID" sql-type="char(32)" not-null="true"/> + <generator class="uuid"/> + </id> + + <!-- A cat has to have a name, but it shouldn' be too long. --> + <property name="name"> + <column name="NAME" length="16" not-null="true"/> + </property> + + <property name="sex"/> + + <property name="weight"/> + + </class> + +</hibernate-mapping>]]></programlisting> + + <para> + 모든 영속 클래스는 식별자 속성을 가져야 한다(실제로 value-타입의 클래스들에 의존하지 않는, 엔티티들을 표현하는 유일한 + 클래스들은 엔티티을 가진 컴포넌트들로 매핑된다). 이 프로퍼티는 영속 객체들을 구별짓는데 사용된다: 만일 + <literal>catA.getId().equals(catB.getId())</literal>가 true일 경우, 두 개의 cat들은 같고, 이 개념은 + <emphasis>database identity</emphasis>로 명명된다. Hibernate는 (데이터베이스 시퀀스, hi/lo 식별자 테이블들, + 그리고 어플리케이션 할당 식별자들에 대한 native 생성기들을 포함하는) 다른 시나리오들에 대해 여러 가지 식별자 생성기들을 + 번들로 갖고 있다. 우리는 UUID 생성기(데이터이스에 의해 생성된 정수 대용 키들이 선호될 것이므로, 테스트용으로만 권장됨)를 + 사용하고 또한 Hibernate 생성된 식별자 값을 위한 <literal>CAT</literal> 테이블의 <literal>CAT_ID</literal> + 컬럼을 (테이블의 프라이머리 키로서) 지정한다. + </para> + + <para> + <literal>Cat</literal>의 모든 다른 프로퍼티들은 동일한 테이블로 매핑된다. <literal>name</literal> 프로퍼티의 경우에, + 우리는 그것을 명시적인 데이터베이스 컬럼 선언으로 매핑시켰다. 데이터베이스 스키마가 Hibernate의 <emphasis>SchemaExport</emphasis> + 도구에 의해 매핑 선언으로부터 (SQL DDL 문장들로) 자동적으로 생성될 때 이것이 특별히 유용하다. 모든 다른 프로퍼티들은 + Hibernate의 디폴트 설정들을 사용하여 매핑되고, 디폴트 설정들은 당신이 가장 많은 시간을 필요로 하는 것이다. 데이터베이스 + 내의 테이블 <literal>CAT</literal>은 다음과 같다: + </para> + + <programlisting><![CDATA[ Column | Type | Modifiers +--------+-----------------------+----------- + cat_id | character(32) | not null + name | character varying(16) | not null + sex | character(1) | + weight | real | +Indexes: cat_pkey primary key btree (cat_id)]]></programlisting> + + <para> + 당신은 이제 수작업으로 당신의 데이터베이스 내에 이 테이블을 생성시킬 것이고, 만일 당신이 <literal>hbm2ddl</literal> + 도구로 이 단계를 자동화 시키고자 원할 경우 <xref linkend="toolsetguide"/>를 읽어라. 이 도구는 테이블 정의, 맞춤형 + 컬럼 타입 컨스트레인트들, 유일 컨스트레인트들과 인덱스들을 포함하는, 전체 SQL DDL을 생성시킬 수 있다. + </para> + + </sect1> + + <sect1 id="quickstart-playingwithcats" revision="3"> + <title>cat들에 작업하기</title> + + <para> + 우리는 이제 Hibernate의 <literal>Session</literal>을 시작할 준비가 되어 있다. 그것은 <emphasis>persistence manager</emphasis> + (영속 관리자)이고, 우리는 데이터베이스로 <literal>Cat</literal>들을 저장하고 데이터베이스로부터 + <literal>Cat</literal>들을 검색하는데 그것을 사용한다. 그러나 먼저 우리는 <literal>SessionFactory</literal>로부터 + <literal>Session</literal>(Hibernate의 작업 단위)를 얻어야 한다: + </para> + + <programlisting><![CDATA[SessionFactory sessionFactory = + new Configuration().configure().buildSessionFactory();]]></programlisting> + + <para> + <literal>configure()</literal> 호출은 <literal>hibernate.cfg.xml</literal> 구성 파일을 로드시키고 + <literal>Configuration</literal> 인스턴스를 초기화 시킨다. 당신이 SessionFactory(불변적임)를 빌드하기 + <emphasis>이전에</emphasis> 당신은 <literal>Configuration</literal>에 접근함으로써 다른 프로퍼티들을 + 설정할 수 있다(그리고 심지어 매핑 메타데이터를 변경시킬 수 있다). 우리는 어디서 <literal>SessionFactory</literal>를 + 생성시키고 우리의 어플리케이션 속에서 어떻게 그것에 접근할 수 있나? + </para> + + <para> + <literal>SessionFactory</literal>는 대개 오직 한번만, 예를 들어 대개 <emphasis>load-on-startup</emphasis> + 서블릿으로 시작 시에 빌드된다. 이것은 또한 당신이 당신의 서블릿들 내에 있는 인스턴스 변수 속에 그것을 유지하지 않을 것이지만 + 어떤 다른 위치에 유지시킬 것임을 의미한다. 더구나 우리는 어떤 종류의 <emphasis>Singleton</emphasis>을 필요로 하며, + 따라서 우리는 어플리케이션 코드로 쉽게 <literal>SessionFactory</literal>에 액세스 할 수 있다. 다음에 보여진 접근법은 + 두 문제 모두를 해결한다: 시작 구성과 <literal>SessionFactory</literal>에 대한 쉬운 접근. + </para> + + <para> + 우리는 <literal>HibernateUtil</literal> helper 클래스를 구현한다: + </para> + + <programlisting><![CDATA[import org.hibernate.*; +import org.hibernate.cfg.*; + +public class HibernateUtil { + + private static Logger log = LoggerFactory.getLogger(HibernateUtil.class); + + private static final SessionFactory sessionFactory; + + static { + try { + // Create the SessionFactory + sessionFactory = new Configuration().configure().buildSessionFactory(); + } catch (Throwable ex) { + // Make sure you log the exception, as it might be swallowed + log.error("Initial SessionFactory creation failed.", ex); + throw new ExceptionInInitializerError(ex); + } + } + + public static final ThreadLocal session = new ThreadLocal(); + + public static Session getCurrentSession() { + Session s = (Session) session.get(); + // Open a new Session, if this Thread has none yet + if (s == null) { + s = sessionFactory.openSession(); + session.set(s); + } + return s; + } + + public static void closeSession() { + Session s = (Session) session.get(); + if (s != null) + s.close(); + session.set(null); + } +}]]></programlisting> + + <para> + 이 클래스는 static 초기자를 가진 <literal>SessionFactory</literal>를 처리할 뿐만 아니라 또한 현재의 쓰레드를 + 위한 <literal>Session</literal>을 소유하는 <literal>ThreadLocal</literal> 변수를 갖는다. 이 helper를 + 사용하려고 시도하기 전에 thread-local 변수에 대한 자바 개념을 이해해야 한다. 보다 복잡하고 강력한 <literal>HibernateUtil</literal> + 클래스는 http://caveatemptor.hibernate.org/의 <literal>CaveatEmptor</literal>에서 찾을 수 있다. + </para> + + <para> + <literal>SessionFactory</literal>는 threadsafe이고, 많은 쓰레드들이 동시에 그것에 접근할 수 있고 + <literal>Session</literal>들을 요청할 수 있다. 하나의 <literal>Session</literal>은 데이터베이스에 대해 + 한 개의 단위 작업을 나타내는 non-threadsafe 객체이다. <literal>Session</literal>들은 <literal>SessionFactory</literal> + 로부터 열려지고 모든 작업이 완료될 때 닫혀진다. 당신의 서블릿의 <literal>process()</literal> 메소드 내에 있는 + 예제는 다음과 같을 수 있다(예외상황 처리 없이): + </para> + + <programlisting><![CDATA[Session session = HibernateUtil.getCurrentSession(); +Transaction tx = session.beginTransaction(); + +Cat princess = new Cat(); +princess.setName("Princess"); +princess.setSex('F'); +princess.setWeight(7.4f); + +session.save(princess); + +tx.commit(); +HibernateUtil.closeSession();]]></programlisting> + + <para> + 하나의 <literal>Session</literal> 내에서 모든 데이터베이스 오퍼레이션은 데이터베이스 오퍼레이션들(심지어 읽기 전용 + 오퍼레이션들 조차도)을 격리시키는 하나의 트랜잭션 내부에서 발생한다. 우리는 기본 트랜잭션 방도(우리의 경우, JDBC + 트랜잭션들)로부터 추상화시키는데 Hibernates <literal>Transaction</literal> API 를 사용한다. 이것은 우리의 + 코드가 임의의 변경들 없이도 (JTA를 사용하는) 컨테이너-관리되는 트랜잭션들에 배치되는 것을 허용해준다. + </para> + + <para> + 당신이 원하는 만큼 당신이 <literal>HibernateUtil.getCurrentSession();</literal>을 호출할 수 있고, 당신은 + 이 쓰레드의 현재 <literal>Session</literal>을 항상 얻을 것임을 노트하라. 당신은 서블릿 코드 내에서든 또는 서블릿 필터 + 내에서든 HTTP response가 전송되기 전에, 당신의 단위 작업이 완료된 후에 <literal>Session</literal>이 확실히 + 닫혀지도록 해야 한다. 두 번째 옵션의 좋은 측면은 쉬운 lazy 초기화이다: 뷰가 렌더링 될 때 <literal>Session</literal>이 + 여전히 열려져 있어서, Hibernate는 당신이 현재 객체 그래프를 네비게이트 하는 동안 초기화 되지 않은 객체들을 로드시킬 수 있다. + </para> + + <para> + Hibernate는 데이터베이스로부터 객체들을 검색하는데 사용될 수 있는 다양한 메소드들을 갖고 있다. 가장 유연한 방법은 Hibernate + Query Language (HQL)을 사용하는 것이다. Hibernate Query Language (HQL)은 배우기가 쉽고 SQL에 대한 강력한 객체 지향 + 확장이다: + </para> + + <programlisting><![CDATA[Transaction tx = session.beginTransaction(); + +Query query = session.createQuery("select c from Cat as c where c.sex = :sex"); +query.setCharacter("sex", 'F'); +for (Iterator it = query.iterate(); it.hasNext();) { + Cat cat = (Cat) it.next(); + out.println("Female Cat: " + cat.getName() ); +} + +tx.commit();]]></programlisting> + + <para> + Hibernate는 또한 type-safe 질의들을 공식화 시키는데 사용될 수 있는 객체-지향 <emphasis>query by criteria</emphasis> + API을 제공한다. 물론 Hibernate는 데이터베이스와의 모든 SQL 통신을 위해 <literal>PreparedStatement</literal>들과 + 파라미터 바인딩을 사용한다. 당신은 또한 Hibernate 직접적인 SQL 질의 특징을 사용할 수도 있거나 드문 경우에 + <literal>Session</literal>으로부터 plain JDBC 커넥션을 얻을 수도 있다. + </para> + + </sect1> + + <sect1 id="quickstart-summary" revision="1"> + <title>마지막으로</title> + + <para> + 우리는 이 작은 튜토리얼 내에서 단지 Hibernate의 표면을 훑기만 했다. 우리는 우리의 예제들 속에 어떤 서블릿 지정적 코드를 + 포함하지 않음을 노트하라. 당신이 적합한지를 알려고 할 때 당신은 당신 자신의 서블릿을 생성시켜야 하고 Hibernate 코드를 + 삽입해야 한다. + </para> + + <para> + 데이터 접근 계층으로서 Hibernate는 당신의 어플리케이션에 강하게 통합됨을 염두에 두라. 대개 모든 다른 레이어들은 영속 + 메커니즘에 의존했다. 당신은 이 설계의 함축을 확실히 이해하도록 하라. + </para> + + <para> + 보다 복잡한 어플리케이션 예제는 http://caveatemptor.hibernate.org/ 를 보고 http://caveatemptor.hibernate.org/에 + 있는 다른 튜토리얼들을 살펴보라. + </para> + + </sect1> + +</chapter> Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/session_api.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/session_api.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/session_api.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/session_api.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,1133 @@ +<chapter id="objectstate"> + <title>객체들로 작업하기</title> + + <para> + Hibernate는 기본 데이터베이스 관리 시스템의 상세로부터 개발자들을 은폐시켜줄 뿐만 아니라, 또한 객체들에 대한 + <emphasis>상태 관리</emphasis>를 제공하는 하나의 완전한 객체/관계형 매핑 솔루션이다. 이것은 공통적인 + JDBC/SQL 영속 계층들 내에서의 SQL <literal>문장들</literal>에 대한 관리와는 반대로, 자바 어플리케이션들에서 + 영속에 관한 매우 고유한 객체-지향적 관점이다. + </para> + + <para> + 달리 말해, Hibernate 어플리케이션 개발자들은 그들의 객체들의 <emphasis>상태</emphasis>에 대해 항상 생각해야 하고, + SQL 문장들의 실행에 대해서는 필수적이지 않다. 이 부분은 Hibernate에 의해 처리되고 시스템의 퍼포먼스를 튜닝할 때 + 어플리케이션 개발자와 유일하게 관련된다. + </para> + + <sect1 id="objectstate-overview"> + <title>Hibernate 객체 상태들</title> + + <para> + Hibernate 다음 객체 상태들을 정의하고 지원한다: + </para> + + <itemizedlist> + <listitem> + <para> + <emphasis>Transient</emphasis> - 만일 객체가 <literal>new</literal> 연산자를 사용하여 방금 초기화 되었다면 + 객체는 transient이고, 그것은 Hibernate <literal>Session</literal>과 연관되어 있지 않다. 그것은 데이터베이스 + 내에서 영속 표상을 갖지 않고 식별자 값이 할당되지 않았다. 만일 어플리케이션이 더 이상 참조를 소유하지 않을 경우 + transient 인스턴스들은 쓰레기 수집기에 의해 파괴될 것이다. 객체를 영속화 시키는데 + (그리고 이 전이(transition)에 대해 실행될 필요가 있는 SQL 문장들을 Hibernate로 하여금 처리하도록 하는데) + Hibernate <literal>Session</literal>을 사용하라. + </para> + </listitem> + <listitem> + <para> + <emphasis>Persistent</emphasis> - 하나의 영속 인스턴스는 데이터베이스 내에서 하나의 표상을 갖고 하나의 식별자 값을 + 갖는다. 그것은 방금 저장되었거나 로드되었을 수 있지만, 정의상 그것은 <literal>Session</literal>의 범위 내에 있다. + Hibernate는 영속 상태에서 객체에 대해 행해진 임의의 변경들을 검출해낼 것이고 단위 작업이 완료될 때 그 상태를 데이터베이스와 + 동기화 시킬 것이다. 개발자들은 하나의 객체가 transient로 되어야 할 때 <literal>UPDATE</literal> 문장들이나 + <literal>DELETE</literal> 문장들을 수작업으로 실행하지 않는다. + </para> + </listitem> + <listitem> + <para> + <emphasis>Detached</emphasis> - 하나의 detached 인스턴스는 영속화 되었지만, 그것의 + <literal>Session</literal>이 닫혀진 객체이다. 물론 그 객체에 대한 참조는 여전히 유효하고, + 그 detached 인스턴스는 이 상태에서도 변경될 수도 있다. 하나의 detached 인스턴스는 나중에 + 그것(과 모두 변경들)을 다시 영속화 시켜서 새로운 <literal>Session</literal>에 다시 첨부될 수 있다. + 이 특징은 사용자가 생각할 시간을 필요로 하는 장 기간 실행되는 작업 단위를 위한 프로그래밍 모형을 가능하게 + 해준다. 우리는 그것들을 <emphasis>어플리케이션 트랜잭션들</emphasis>, 즉 사용자의 관점의 작업 단위라고 + 부른다. + </para> + </listitem> + </itemizedlist> + + <para> + 이제 우리는 상태들과 상태 전이(transition)들(그리고 전이를 트리거 시키는 Hibernate 메소드들)을 상세하게 논의할 것이다. + </para> + + </sect1> + + <sect1 id="objectstate-makingpersistent" revision="1"> + <title>객체들을 영속화 시키기</title> + + <para> + 하나의 영속 클래스의 새로이 초기화 된 인스턴스들은 Hibernate에 의해 <emphasis>transient</emphasis>로 간주된다. + 우리는 그것을 세션과 연관지어서 transient 인스턴스를 <emphasis>영속화</emphasis> 시킬 수 있다: + </para> + + <programlisting><![CDATA[DomesticCat fritz = new DomesticCat(); +fritz.setColor(Color.GINGER); +fritz.setSex('M'); +fritz.setName("Fritz"); +Long generatedId = (Long) sess.save(fritz);]]></programlisting> + + <para> + 만일 <literal>Cat</literal>이 생성된 식별자를 가질 경우, <literal>save()</literal>가 호출될 때 + 그 식별자가 생성되고 <literal>cat</literal>에 할당된다. 만일 <literal>Cat</literal>이 하나의 + <literal>assigned</literal> 식별자나 하나의 composite key를 가질 경우, <literal>save()</literal>를 + 호출하기 전에 그 식별자가<literal>cat</literal> 인스턴스에 할당될 것이다. 당신은 또한 EJB3 초기 드래프트에서 + 정의된 의미로 <literal>save()</literal> 대신 <literal>persist()</literal>를 사용할 수도 있다. + </para> + + <para> + 다른 방법으로, 당신은 <literal>save()</literal>의 오버로드된 버전을 사용하여 식별자를 할당할 수 있다. + </para> + +<programlisting><![CDATA[DomesticCat pk = new DomesticCat(); +pk.setColor(Color.TABBY); +pk.setSex('F'); +pk.setName("PK"); +pk.setKittens( new HashSet() ); +pk.addKitten(fritz); +sess.save( pk, new Long(1234) );]]></programlisting> + + <para> + 만일 당신이 영속화 시키는 객체가 연관된 객체들(예를 들면. 앞의 예제에 있는 <literal>kittens</literal> 콜렉션)을 갖고 있다면, + 당신이 하나의 foreign 키 컬럼에 대해 하나의 <literal>NOT NULL</literal> 컨스트레인트를 갖지 않는 한, + 이들 객체들은 당신이 좋아하는 임의의 순서로 영속화 되었을 수도 있다. foreign 키 컨스트레인트들을 위배하는 위험성이 + 결코 존재하지 않는다. 하지만 당신이 잘못된 순서로 그 객체들을 <literal>save()</literal> 시킬 경우 당신은 + <literal>NOT NULL</literal> 컨스트레인트를 위배할 수도 있다. + </para> + + <para> + 당신이 연관된 객체들을 자동적으로 저장시키는데 Hibernate의 <emphasis>transitive persistence(전이 영속)</emphasis> + 특징을 사용하는 것을 매우 좋아할 것이므로 대개 당신은 이 상세를 내버려둔다. 그때 <literal>NOT NULL</literal> 컨스트레인트 + 위배들이 발생되지 않을지라도 - Hibernate는 모든 것을 처리할 것이다. Transitive persistence(전이 영속)은 이 장에서 + 후반부에서 논의된다. + </para> + + </sect1> + + <sect1 id="objectstate-loading"> + <title>객체를 로드시키기</title> + + <para> + <literal>Session</literal>의 <literal>load()</literal> 메소드들은 만일 당신이 그것(영속 인스턴스)의 식별자들을 + 이미 알고 있을 경우에 영속 인스턴스를 검색하는 방법을 당신에게 제공한다. <literal>load()</literal>는 하나의 클래스 객체를 + 취하고 그 상태를 영속(persistent) 상태로 그 클래스의 새로이 초기화 된 인스턴스 속으로 로드시킬 것이다. + </para> + + <programlisting><![CDATA[Cat fritz = (Cat) sess.load(Cat.class, generatedId);]]></programlisting> + +<programlisting><![CDATA[// you need to wrap primitive identifiers +long id = 1234; +DomesticCat pk = (DomesticCat) sess.load( DomesticCat.class, new Long(id) );]]></programlisting> + + <para> + 다른 방법으로 당신은 주어진 인스턴스 속으로 상태를 로드시킬 수 있다: + </para> + +<programlisting><![CDATA[Cat cat = new DomesticCat(); +// load pk's state into cat +sess.load( cat, new Long(pkId) ); +Set kittens = cat.getKittens();]]></programlisting> + + <para> + 만일 일치하는 데이터베이스 행이 존재하지 않을 경우에 <literal>load()</literal>가 unrecoverable(복구 불가능한) 예외상황을 + 던질 것임을 노트하라. 만일 클래스가 프락시를 갖도록 매핑된 경우, <literal>load()</literal>는 초기화 되지 않은 프락시를 단지 + 반환하고 당신이 그 프락시의 메소드를 호출하기 전까지는 실제로 데이터베이스에 접속하지 않는다. 당신이 데이터베이스로부터 + 객체에 대한 연관을 실제로 로드시키지 않고서 객체에 대한 연관을 생성시키고자 원할 경우에 이 특징이 매우 유용하다. 만일 + <literal>batch-size</literal>가 class 매핑에 정의되는 경우 그것은 또한 다중 인스턴스들이 하나의 배치로서 로드되는 것을 + 허용해준다. + </para> + + <para> + 만일 당신이 하나의 일치하는 행이 존재하는지를 확신할 수 없을 경우, 당신은 <literal>get()</literal> 메소드를 사용해야 한다. + 그것(<literal>get()</literal> 메소드)는 데이터베이스에 즉시 접속하고 만일 일치하는 행이 없을 경우 null을 반환한다. + </para> + + <programlisting><![CDATA[Cat cat = (Cat) sess.get(Cat.class, id); +if (cat==null) { + cat = new Cat(); + sess.save(cat, id); +} +return cat;]]></programlisting> + + <para> + 당신은 하나의 <literal>LockMode</literal>를 사용하는, <literal>SELECT ... FOR UPDATE</literal>를 사용하여 + 하나의 객체를 로드시킬 수도 있다. 추가 정보는 API 문서를 보라. + </para> + + <programlisting><![CDATA[Cat cat = (Cat) sess.get(Cat.class, id, LockMode.UPGRADE);]]></programlisting> + + <para> + 어떤 연관된 인스턴스들이나 포함된 콜렉션들은 당신이 그 연관에 대한 케스케이드 스타일로서 <literal>lock</literal> 또는 + <literal>all</literal>을 지정하도록 결정하지 않는 한, <literal>FOR UPDATE</literal>로 선택되지 않음을 노트하라. + </para> + + <para> + <literal>refresh()</literal> 메소드를 사용하여, 아무때나 하나의 객체와 모든 그것의 콜렉션들을 다시 로드시키는 것이 + 가능하다. 데이터베이스 트리거들이 그 객체의 프로퍼티들 중 어떤 것을 초기화 시키는데 사용될 때 이것이 유용하다. + </para> + + <programlisting><![CDATA[sess.save(cat); +sess.flush(); //force the SQL INSERT +sess.refresh(cat); //re-read the state (after the trigger executes)]]></programlisting> + + <para> + 중요한 질문이 대개 이 지점에서 나타난다: Hibernate는 데이터베이로부터 그것을 얼마나 많이 로드시키고 그리고 얼마나 많은 + SQL <literal>SELECT</literal>들이 그것을 사용할 것인가? 이것은 <emphasis>페칭 방도</emphasis>에 의존하고 + <xref linkend="performance-fetching"/>에 설명되어 있다. + </para> + + </sect1> + + <sect1 id="objectstate-querying" revision="1"> + <title>질의하기</title> + + <para> + 만일 당신이 당신이 찾고 있는 객체들에 대한 식별자들을 모를 경우, 당신은 하나의 질의를 필요로 한다. Hibernate는 사용이 쉽지만 + 강력한 객체 지향 질의 언어(HQL)를 지원한다. 프로그램 상의 질의 생성을 위해, Hibernate는 정교한 Criteria 및 Example 질의 + 특징(QBC와 QBE)를 지원한다. 당신은 또한 객체들로의 결과 셋 변환을 위한 선택적인 Hibernate의 지원으로, 당신의 데이터베이스의 + native SQL 속에 당신의 질의를 표현할 수도 있다. + </para> + + <sect2 id="objectstate-querying-executing" revision="1"> + <title>질의들을 실행하기</title> + + <para> + HQL 질의와 native SQL 질의는 <literal>org.hibernate.Query</literal>의 인스턴스로 표현된다. 이 인터페이스는 + 파라미터 바인딩, 결과셋 핸들링을 위한, 그리고 실제 질의의 실행을 위한 메소드들을 제공한다. 당신은 항상 현재 + <literal>Session</literal>을 사용하여 하나의 <literal>Query</literal>를 얻는다: + </para> + + <programlisting><![CDATA[List cats = session.createQuery( + "from Cat as cat where cat.birthdate < ?") + .setDate(0, date) + .list(); + +List mothers = session.createQuery( + "select mother from Cat as cat join cat.mother as mother where cat.name = ?") + .setString(0, name) + .list(); + +List kittens = session.createQuery( + "from Cat as cat where cat.mother = ?") + .setEntity(0, pk) + .list(); + +Cat mother = (Cat) session.createQuery( + "select cat.mother from Cat as cat where cat = ?") + .setEntity(0, izi) + .uniqueResult();]] + +Query mothersWithKittens = (Cat) session.createQuery( + "select mother from Cat as mother left join fetch mother.kittens"); +Set uniqueMothers = new HashSet(mothersWithKittens.list());]]></programlisting> + + <para> + 하나의 질의는 대개 <literal>list()</literal>를 호출하여 실행되고, 질의의 결과는 메모리 내에서 하나의 콜렉션 속으로 + 전체적으로 로드될 것이다. 하나의 질의에 의해 검색된 엔티티 인스턴스들은 영속(persistent) 상태에 있다. 당신의 질의가 + 하나의 객체를 오직 반환할 것임을 당신이 알고 있을 경우에 <literal>uniqueResult()</literal> 메소드는 단축을 제공한다. + 콜렉션들에 대해 eager 페칭을 사용하는 질의들은 대개 (그것들의 초기화된 콜렉션들을 가진) 루트 객체들에 대한 중복들을 대개 + 반환한다. 당신은 <literal>Set</literal>을 통해 이들 중복들을 간단하게 필터링할 수 있다. + </para> + + <sect3 id="objectstate-querying-executing-iterate"> + <title>결과들을 반복하기</title> + + <para> + 종종, 당신은 <literal>iterate()</literal> 메소드를 사용하여 질의를 실행함으로써 더 나은 퍼포먼스를 성취하는 + 것이 가능할 수 있다. 이것은 오직 대개 질의에 의해 반환되는 실제 엔티티 인스턴스들이 이미 세션 내에 있거나 + second-level 캐시 내에 있을 것임을 당신이 예상하는 경우일 것이다. 만일 그것들이 이미 캐시되지 않았다면, + <literal>iterate()</literal>는 <literal>list()</literal> 보다 더 느릴 것이고 간단한 질의에 대해 + 많은 데이터베이스 접속들을, 대개 오직 식별자들을 반환하는 초기 select에 대해 <emphasis>1</emphasis>번의 접속과 + 실제 인스턴스들을 초기화 시키는 추가적인 select들에 대해 <emphasis>n</emphasis> 번의 접속을 필요로 할 수 있다. + </para> + + <programlisting><![CDATA[// fetch ids +Iterator iter = sess.createQuery("from eg.Qux q order by q.likeliness").iterate(); +while ( iter.hasNext() ) { + Qux qux = (Qux) iter.next(); // fetch the object + // something we couldnt express in the query + if ( qux.calculateComplicatedAlgorithm() ) { + // delete the current instance + iter.remove(); + // dont need to process the rest + break; + } +}]]></programlisting> + </sect3> + + <sect3 id="objectstate-querying-executing-tuples"> + <title>튜플들을 반환하는 질의들</title> + + <para> + Hibernate 질의들은 때때로 객체들의 튜플들을 반환하고, 그 경우에 각각의 튜플은 배열로서 반환된다: + </para> + + <programlisting><![CDATA[Iterator kittensAndMothers = sess.createQuery( + "select kitten, mother from Cat kitten join kitten.mother mother") + .list() + .iterator(); + +while ( kittensAndMothers.hasNext() ) { + Object[] tuple = (Object[]) kittensAndMothers.next(); + Cat kitten = (Cat) tuple[0]; + Cat mother = (Cat) tuple[1]; + .... +}]]></programlisting> + + </sect3> + + <sect3 id="objectstate-querying-executing-scalar" revision="1"> + <title>스칼라 결과들</title> + + <para> + 질의들은 <literal>select</literal> 절 내에 하나의 클래스에 대한 하나의 프로퍼티를 지정할 수 있다. + 그것들은 심지어 SQL 집계 함수들을 호출할 수도 있다. 프로퍼티들이나 aggregate들은 + "스칼라" 결과들(그리고 영속 상태에 있는 엔티티들이 아닌 것으)로 간주된다. + </para> + + <programlisting><![CDATA[Iterator results = sess.createQuery( + "select cat.color, min(cat.birthdate), count(cat) from Cat cat " + + "group by cat.color") + .list() + .iterator(); + +while ( results.hasNext() ) { + Object[] row = (Object[]) results.next(); + Color type = (Color) row[0]; + Date oldest = (Date) row[1]; + Integer count = (Integer) row[2]; + ..... +}]]></programlisting> + + </sect3> + + <sect3 id="objectstate-querying-executing-parameters"> + <title>바인드 프라미터들</title> + + <para> + <literal>Query</literal> 상의 메소드들은 명명된 파라미터들 또는 JDBC-스타일의 <literal>?</literal> + 파라미터들에 바인딩 값들을 제공한다. <emphasis>JDBC와는 대조적으로, Hibernate 숫자 파라미터들은 0에서 + 시작된다.</emphasis> 명명된 파라미터들은 질의 문자열 속에서 <literal>:name</literal> 형식의 식별자들이다. + 명명된 파라미터들의 장점들은 다음과 같다: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + 명명된 파라미터들은 그것들이 질의 문자열 내에 발생하는 순서에 관계없다 + </para> + </listitem> + <listitem> + <para> + 그것들은 동일한 질의 내에서 여러 번 발생할 수 있다 + </para> + </listitem> + <listitem> + <para> + 그것은 자기-설명적이다 + </para> + </listitem> + </itemizedlist> + + <programlisting><![CDATA[//named parameter (preferred) +Query q = sess.createQuery("from DomesticCat cat where cat.name = :name"); +q.setString("name", "Fritz"); +Iterator cats = q.iterate();]]></programlisting> + + <programlisting><![CDATA[//positional parameter +Query q = sess.createQuery("from DomesticCat cat where cat.name = ?"); +q.setString(0, "Izi"); +Iterator cats = q.iterate();]]></programlisting> + + <programlisting><![CDATA[//named parameter list +List names = new ArrayList(); +names.add("Izi"); +names.add("Fritz"); +Query q = sess.createQuery("from DomesticCat cat where cat.name in (:namesList)"); +q.setParameterList("namesList", names); +List cats = q.list();]]></programlisting> + + </sect3> + + <sect3 id="objectstate-querying-executing-pagination"> + <title>쪽매김</title> + + <para> + 만일 당신이 당신의 결과 셋에 경계(당신이 검색하고자 원하는 최대 개수 그리고/또는 당신이 검색하고자 원하는 첫 번째 행)을 + 지정할 필요가 있다면 당신은 <literal>Query</literal> 인터페이스의 메소드들을 사용해야 한다: + </para> + + <programlisting><![CDATA[Query q = sess.createQuery("from DomesticCat cat"); +q.setFirstResult(20); +q.setMaxResults(10); +List cats = q.list();]]></programlisting> + + <para> + Hibernate는 이 limit 질의를 당신의 DBMS의 native SQL로 번역하는 방법을 알고 있다. + </para> + + </sect3> + + <sect3 id="objectstate-querying-executing-scrolling"> + <title>스크롤 가능한 iteration</title> + + <para> + 당신의 JDBC 드라이버가 스크롤 가능한 <literal>ResultSet</literal>들을 지원할 경우, + <literal>Query</literal> 인터페이스는 <literal>ScrollableResults</literal> 객체를 얻는데 + 사용될 수 있고, 그것은 질의 결과들에 대한 유연한 네비게이션을 허용해준다. + </para> + + <programlisting><![CDATA[Query q = sess.createQuery("select cat.name, cat from DomesticCat cat " + + "order by cat.name"); +ScrollableResults cats = q.scroll(); +if ( cats.first() ) { + + // find the first name on each page of an alphabetical list of cats by name + firstNamesOfPages = new ArrayList(); + do { + String name = cats.getString(0); + firstNamesOfPages.add(name); + } + while ( cats.scroll(PAGE_SIZE) ); + + // Now get the first page of cats + pageOfCats = new ArrayList(); + cats.beforeFirst(); + int i=0; + while( ( PAGE_SIZE > i++ ) && cats.next() ) pageOfCats.add( cats.get(1) ); + +} +cats.close()]]></programlisting> + + <para> + 열려진 데이터베이스 커넥션(과 커서)가 이 기능에 필요함을 노트하고, 만일 당신이 쪽매김 기능을 작동시킬 필요가 있다면 + <literal>setMaxResult()</literal>/<literal>setFirstResult()</literal>를 사용하라. + </para> + + </sect3> + + <sect3 id="objectstate-querying-executing-named" revision="1"> + <title>명명된 질의들을 구체화 시키기</title> + + <para> + 당신은 또한 매핑 문서 속에 명명된 질의들을 정의할 수 있다.(만일 당신의 질의가 마크업으로서 해석될 수 있는 문자들을 + 포함할 경우에 <literal>CDATA</literal> 섹션을 사용하는 것을 기억하라)) + </para> + + <programlisting><![CDATA[<query name="ByNameAndMaximumWeight"><![CDATA[ + from eg.DomesticCat as cat + where cat.name = ? + and cat.weight > ? +] ]></query>]]></programlisting> + + <para> + 파라미터 바인딩과 실행은 프로그램 상으로 행해진다: + </para> + + <programlisting><![CDATA[Query q = sess.getNamedQuery("ByNameAndMaximumWeight"); +q.setString(0, name); +q.setInt(1, minWeight); +List cats = q.list();]]></programlisting> + + <para> + 실제 프로그램 코드는 사용되는 질의 언어에 독립적이고, 당신은 또한 메타데이터로 native SQL 질의들을 정의할 수도 있거나 + 그것들을 매핑 파일들 속에 기존 질의들을 위치지움으로써 기존 질의들을 Hibernate로 이전시킬 수도 있음을 노트하라. + </para> + + <para> + 또한 <literal>&lt;hibernate-mapping&gt;</literal> 요소 내에서 하나의 질의 선언은 그 질의에 대한 + 전역 유일 이름을 필요로 하고, 반면에 <literal>&lt;class&gt;</literal> 요소 내에서의 질의 선언은 + 클래스 이름으로 수직된이름을 첨가하여 자동적으로 유일하게 만들어진다. + 예를 들어 <literal>eg.Cat.ByNameAndMaximumWeight</literal>. + </para> + + </sect3> + + </sect2> + + <sect2 id="objectstate-filtering" revision="1"> + <title>콜렉션들을 필터링 하기</title> + <para> + 콜렉션 <emphasis>필터</emphasis>는 영속 콜렉션 또는 배열에 적용될 수 있는 질의의 특별한 타입이다. 질의 문자열은 + 현재의 콜렉션 요소를 의미하는 <literal>this</literal>를 참조할 수 있다. + </para> + + <programlisting><![CDATA[Collection blackKittens = session.createFilter( + pk.getKittens(), + "where this.color = ?") + .setParameter( Color.BLACK, Hibernate.custom(ColorUserType.class) ) + .list() +);]]></programlisting> + + <para> + 반환되는 콜렉션은 하나의 bag으로 간주되고, 그것은 주어진 콜렉션에 대한 사본이다. 원래의 콜렉션은 변경되지 않는다 + (이것은 이름 "filter"의 의미와는 정반대이지만, 예상되는 행위와 일치된다). + </para> + + <para> + 필터들은 <literal>from</literal> 절을 필요로 하지 않음을 관찰하라(필요할 경우에 필터들이 한 개의 from 절을 가질 수 + 있을지라도). 필터들은 콜렉션 요소들 자체들을 반환하는 것으로 한정되지 않는다. + </para> + + <programlisting><![CDATA[Collection blackKittenMates = session.createFilter( + pk.getKittens(), + "select this.mate where this.color = eg.Color.BLACK.intValue") + .list();]]></programlisting> + + <para> + 심지어 하나의 공백의 필터 질의도 예를 들어 거대한 콜렉션 내에 있는 요소들의 부분집합들을 로드시키는데 유용하다: + </para> + + <programlisting><![CDATA[Collection tenKittens = session.createFilter( + mother.getKittens(), "") + .setFirstResult(0).setMaxResults(10) + .list();]]></programlisting> + + </sect2> + + <sect2 id="objecstate-querying-criteria" revision="1"> + <title>Criteria 질의들</title> + + <para> + HQL은 극히 강력하지만 몇몇 개발자들은 질의 문자열들을 빌드하기 보다, 객체 지향 API를 사용하여 동적으로 질의들을 빌드시키는 + 것을 선호한다. Hibernate는 이들 경우들을 위한 직관적인 <literal>Criteria</literal> query API를 제공한다: + </para> + + <programlisting><![CDATA[Criteria crit = session.createCriteria(Cat.class); +crit.add( Restrictions.eq( "color", eg.Color.BLACK ) ); +crit.setMaxResults(10); +List cats = crit.list();]]></programlisting> + + <para> + <literal>Criteria</literal>와 연관된 <literal>Example</literal> API 는 + <xref linkend="querycriteria"/>에서 상세하게 논의된다. + </para> + + </sect2> + + <sect2 id="objectstate-querying-nativesql" revision="2"> + <title>native SQL에서 질의들</title> + + <para> + 당신은 <literal>createSQLQuery()</literal>를 사용하여 SQL 속에 하나의 질의를 표현할 수 있고, + Hibernate로 하여금 결과 셋들로부터 객체들로의 매핑을 처리하도록 할수도 있다. 당신은 아무때나 + <literal>session.connection()</literal>을 호출할 수 있고 직접 JDBC <literal>Connection</literal>을 + 사용할 수 있음을 노트하라. 만일 당신이 Hibernate API를 사용하고자 선택한 경우에 , 당신은 SQL alias들을 + 중괄호들 속에 포함시켜야 한다: + </para> + + <programlisting><![CDATA[List cats = session.createSQLQuery("SELECT {cat.*} FROM CAT {cat} WHERE ROWNUM<10") + .addEntity("cat", Cat.class) +.list();]]></programlisting> + + <programlisting><![CDATA[List cats = session.createSQLQuery( + "SELECT {cat}.ID AS {cat.id}, {cat}.SEX AS {cat.sex}, " + + "{cat}.MATE AS {cat.mate}, {cat}.SUBCLASS AS {cat.class}, ... " + + "FROM CAT {cat} WHERE ROWNUM<10") + .addEntity("cat", Cat.class) +.list()]]></programlisting> + + <para> + SQL 질의들은 Hibernate 질의들처럼 명명된 파라미터들과 위치 파라미터들을 포함할 수도 있다. SQL 질의들에 대한 + 추가 정보는 <xref linkend="querysql"/>에서 찾을 수 있다. + </para> + + </sect2> + + </sect1> + + <sect1 id="objectstate-modifying" revision="1"> + <title>영속 객체들을 변경하기</title> + + <para> + <emphasis>트랜잭션 상의 영속 인스턴스들</emphasis> (예를들면. <literal>Session</literal>에 의해 로드되고, + 저장되고, 생성되거나 질의된 객체들)은 어플리케이션에 의해 처리될 수 있고 영속 상태에 대한 임의의 변경들은 + <literal>Session</literal>이 <emphasis>flush될</emphasis> 때 영속화 될 것이다(이 장의 뒷 부분에서 논의됨). + 당신의 변경들을 영속화 시키기 위해 (다른 용도를 가진 <literal>update()</literal>와 같은) 특별한 메소드를 호출할 + 필요가 없다. 따라서 객체의 상태를 업데이트 시키는 가장 간단한 방법은 <literal>Session</literal>이 열려 있는 동안, + 그것을 <literal>load()</literal>시키고 나서, 그것을 직접 처리하는 것이다: + </para> + + <programlisting><![CDATA[DomesticCat cat = (DomesticCat) sess.load( Cat.class, new Long(69) ); +cat.setName("PK"); +sess.flush(); // changes to cat are automatically detected and persisted]]></programlisting> + + <para> + 때때로 이 프로그래밍 모형은 불충분하다. 왜냐하면 그것은 동일한 세션 내에서 (객체를 로드시키는) SQL + <literal>SELECT</literal>와 (그것의 업데이트된 상태를 영속화 시키는) SQL <literal>UPDATE</literal> + 양자를 필요로 할 것이기 때문이다. 그러므로 Hibernate는 detached 인스턴스들을 사용하는 대안적인 접근법을 제공한다. + </para> + + <para> + <emphasis>Hibernate는 <literal>UPDATE</literal> 문장 또는 <literal>DELETE</literal> 문장의 직접적인 실행을 위한 + 그것 자신의 API를 제공하지 않음을 노트하라. Hibernate는 하나의 <emphasis>상태 관리</emphasis> 서비스이고, 당신은 그것을 + 사용할 <emphasis>문장들</emphasis>을 생각하지 말아야 한다. JDBC는 SQL 문장들을 실행시키는 완전한 API이고, 당신은 + <literal>session.connection()</literal>을 호출하여 아무때나 한 개의 JDBC <literal>Connection</literal>을 + 얻을 수 있다. 게다가 대량 오퍼레이션의 개념은 온라인 트랜잭션 처리-지향적인 어플리케이션들을 위한 객체/관계형 매핑과 충돌한다. + 하지만 Hibernate의 장래 버전들은 특별한 대용량의 오퍼레이션 기능들을 제공할 수도 있다. 몇몇 가능한 배치 오퍼레이션 트릭들에 + 대해서는 <xref linkend="batch"/>을 보라.</emphasis> + </para> + + </sect1> + + <sect1 id="objectstate-detached" revision="2"> + <title>detached 객체들을 변경시키기</title> + + <para> + 많은 어플리케이션들은 하나의 트랜잭션 내에서 하나의 객체를 검색하고, 처리를 위한 UI 계층으로 그것을 전송하고, + 그런 다음 새로운 트랜잭션 내에서 변경들을 저장할 필요가 있다. 고도의-동시성 환경에서 이런 종류의 접근법을 사용하는 + 어플리케이션들은 대개 작업의 "긴" 단위를 확실히 격리시키기 위해 버전화 된 데이터를 사용한다. + </para> + + <para> + Hibernate는 <literal>Session.update()</literal> 메소드 또는 <literal>Session.merge()</literal> 메소드를 + 사용하여 detached 인스턴스들의 재첨부를 제공함으로써 이 모형을 지원한다: + </para> + + <programlisting><![CDATA[// in the first session +Cat cat = (Cat) firstSession.load(Cat.class, catId); +Cat potentialMate = new Cat(); +firstSession.save(potentialMate); + +// in a higher layer of the application +cat.setMate(potentialMate); + +// later, in a new session +secondSession.update(cat); // update cat +secondSession.update(mate); // update mate]]></programlisting> + + <para> + 만일 <literal>catId</literal> 식별자를 가진 <literal>Cat</literal>이 <literal>secondSession</literal>에 의해 + 이미 로드되었을 경우에 어플리케이션이 그것을 다시 재첨부하려고 시도할 때, 예외상황이 던져졌을 것이다. + </para> + + <para> + 만일 그 세션이 동일한 식별자를 가진 영속 인스턴스를 이미 포함하지 않음을 당신이 확신하는 경우에는 + <literal>update()</literal>를 사용하고, 만일 당신이 세션의 상태를 고려하지 않은채로 아무때나 당신의 변경을 병합시키고자 + 원할 경우에는 <literal>merge()</literal>를 사용하라. 달리 말해, 당신의 detached 인스턴스들에 대한 재첨부가 실행되는 + 첫 번째 오퍼레이션임을 확실히 함으로써, <literal>update()</literal>는 대개 갓 만들어진 세션에서 당신이 호출하게 될 + 첫 번째 메소드이다. + </para> + + <para> + 어플리케이션은 만일 그것이 detached 인스턴스들의 상태가 또한 업데이트 되는 것을 원할 경우에<emphasis>만</emphasis> + 주어진 detached 인스턴스로부터 도달 가능한 detached 인스턴스들을 개별적으로<literal>update()</literal> 시킬 것이다. + 이것은 물론 <emphasis>transitive persistence(전이 영속)</emphasis>을 사용하여 자동화 될 수 있고, + <xref linkend="objectstate-transitive"/>를 보라. + </para> + + <para> + <literal>lock()</literal> 메소드는 또한 하나의 객체를 새로운 세션에 대해 다시 연관시키는것을 어플리케이션에게 허용해준다. + 하지만 detached 인스턴스는 변경되지 않아야 한다! + </para> + + <programlisting><![CDATA[//just reassociate: +sess.lock(fritz, LockMode.NONE); +//do a version check, then reassociate: +sess.lock(izi, LockMode.READ); +//do a version check, using SELECT ... FOR UPDATE, then reassociate: +sess.lock(pk, LockMode.UPGRADE);]]></programlisting> + + <para> + <literal>lock()</literal>이 여러가지 <literal>LockMode</literal>들에 사용될 수 있음을 노트하고, + 상세한 것은 API 문서와 트랜잭션 처리에 관한 장을 보라. 재첨부는 <literal>lock()</literal>에 대한 + 유일한 쓰임새는 아니다. + </para> + + <para> + 긴 작업 단위에 대한 다른 모형들은 <xref linkend="transactions-optimistic"/>에서 논의된다. + </para> + + </sect1> + + <sect1 id="objectstate-saveorupdate"> + <title>자동적인 상태 검출</title> + + <para> + Hibernate 사용자들은 새로운 식별자를 생성시켜서 transient 인스턴스를 저장하거나 + 그것의 현재 식별자와 연관된 detached 인스턴스들을 업데이트/재첨부 시키는 일반적인 용도의 메소드를 요청했다. + <literal>saveOrUpdate()</literal> 메소드는 이 기능을 구현한다. + </para> + + <programlisting><![CDATA[// in the first session +Cat cat = (Cat) firstSession.load(Cat.class, catID); + +// in a higher tier of the application +Cat mate = new Cat(); +cat.setMate(mate); + +// later, in a new session +secondSession.saveOrUpdate(cat); // update existing state (cat has a non-null id) +secondSession.saveOrUpdate(mate); // save the new instance (mate has a null id)]]></programlisting> + + <para> + <literal>saveOrUpdate()</literal>의 사용 예제와 의미는 초심자들에게는 혼동스러워 보인다. 먼저, 하나의 세션에서 온 + 인스턴스를 또 다른 새로운 세션 내에서 사용하려고 시도하지 않는 한, 당신은 <literal>update()</literal>, + <literal>saveOrUpdate()</literal>, 또는 <literal>merge()</literal>를 사용할 필요는 없을 것이다. + 몇몇 전체 어플리케이션들은 이들 메소드들 중 어느 것도 결코 사용하지 않을 것이다. + </para> + + <para> + 대개 <literal>update()</literal> 또는 <literal>saveOrUpdate()</literal>는 다음 시나리오에서 사용된다: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + 어플리케이션이 첫 번째 세션 내에 객체를 로드시킨다 + </para> + </listitem> + <listitem> + <para> + 객체가 UI 티어로 전달된다 + </para> + </listitem> + <listitem> + <para> + 몇몇 변경들이 그 객체에 행해진다 + </para> + </listitem> + <listitem> + <para> + 객체가 비지니스 로직 티어로 전달된다 + </para> + </listitem> + <listitem> + <para> + 어플리케이션은 두 번째 세션에서 <literal>update()</literal>를 호출함으로써 이들 변경들을 영속화 시킨다 + </para> + </listitem> + </itemizedlist> + + <para> + <literal>saveOrUpdate()</literal>는 다음을 행한다: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + 만일 객체가 이 세션 내에서 이미 영속화 되어 있을 경우, 아무것도 행하지 않는다 + </para> + </listitem> + <listitem> + <para> + 만일 그 세션과 연관된 또 다른 객체가 동일한 식별자를 가질 경우, 예외상황을 던진다 + </para> + </listitem> + <listitem> + <para> + 만일 그 객체가 식별자 프로퍼티를 갖지 않을 경우, 그것을 <literal>save()</literal> 시킨다 + </para> + </listitem> + <listitem> + <para> + 만일 객체의 식별자가 새로이 초기화 된 객체에 할당된 값을 가질 경우, 그것을 <literal>save()</literal> 시킨다 + </para> + </listitem> + <listitem> + <para> + 만일 객체가 (<literal>&lt;version&gt;</literal> 또는 <literal>&lt;timestamp&gt;</literal>에 의해) + 버전화 되고, version 프로퍼티 값이 새로이 초기화 된 객체에 할당된 것과 동일한 값일 경우, 그것을 <literal>save()</literal> + 시킨다 + </para> + </listitem> + <listitem> + <para> + 그 밖의 경우 그 객체를 <literal>update()</literal> 시킨다 + </para> + </listitem> + </itemizedlist> + + <para> + 그리고 <literal>merge()</literal>는 매우 다르다: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + 만일 세션과 현재 연관된 동일한 식별자를 가진 영속 인스턴스가 존재할 경우, + 주어진 객체의 상태를 영속 인스턴스 상으로 복사한다 + </para> + </listitem> + <listitem> + <para> + 만일 세션과 현재 연관된 영속 인스턴스가 존재하지 않을 경우, 데이터베이스로부터 그것을 로드시키려고 시도하거나 + 새로운 영속 인스턴스를 생성시키려고 시도한다 + </para> + </listitem> + <listitem> + <para> + 영속 인스턴스가 반환된다 + </para> + </listitem> + <listitem> + <para> + 주어진 인스턴스는 세션과 연관되지 않고, 그것은 detached 상태에 머무른다 + </para> + </listitem> + </itemizedlist> + + </sect1> + + <sect1 id="objectstate-deleting" revision="1"> + <title>영속 객체들을 삭제하기</title> + + <para> + <literal>Session.delete()</literal>는 데이터베이스로부터 객체의 상태를 제거할 것이다. + 물론 당신의 어플리케이션은 여전히 detached 객체에 대한 참조를 소유할 것이다. 영속 인스턴스를 transient로 만들 때 + <literal>delete()</literal>를 생각하는 것이 최상이다. + </para> + + <programlisting><![CDATA[sess.delete(cat);]]></programlisting> + + <para> + 당신은 foreign 키 컨스트레인트 위배들에 대한 위험성 없이 당신이 좋아하는 어떤 순서로 객체들을 삭제할 수도 있다. + 잘못된 순서로 객체들을 삭제함으로써 foreign 키 컬럼에 대한 <literal>NOT NULL</literal> 컨스트레인트를 위배할 가능성이 + 여전히 존재한다. 예를 들어, 당신이 부모를 삭제하지만, 그 자식들을 삭제하는 것을 잊은 경우. + </para> + + </sect1> + + <sect1 id="objectstate-replicating" revision="1"> + <title>두 개의 다른 데이터저장소들 사이에 객체들을 복제하기</title> + + <para> + 영속 인스턴스들의 그래프를 취하고 식별자 값들을 다시 생성시키지 않고서 그것들을 다른 저장소 속에 영속화 시키는 것을 가능하도록 + 만드는 것이 종종 유용하다. + </para> + + <programlisting><![CDATA[//retrieve a cat from one database +Session session1 = factory1.openSession(); +Transaction tx1 = session1.beginTransaction(); +Cat cat = session1.get(Cat.class, catId); +tx1.commit(); +session1.close(); + +//reconcile with a second database +Session session2 = factory2.openSession(); +Transaction tx2 = session2.beginTransaction(); +session2.replicate(cat, ReplicationMode.LATEST_VERSION); +tx2.commit(); +session2.close();]]></programlisting> + + <para> + <literal>ReplicationMode</literal>는 <literal>replicate()</literal>가 데이터베이스 내에 있는 기존의 + 행들과의 충돌을 처리하게될 방법을 결정한다. + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + <literal>ReplicationMode.IGNORE</literal> - 동일한 식별자를 가진 기존 데이터베이스 행이 존재할 + 경우에 그 객체를 무시한다 + </para> + </listitem> + <listitem> + <para> + <literal>ReplicationMode.OVERWRITE</literal> - 동일한 식별자를 가진 어떤 기존의 데이터베이스 행을 덮어 쓴다 + </para> + </listitem> + <listitem> + <para> + <literal>ReplicationMode.EXCEPTION</literal> - 만일 동일한 식별자를 가진 기존 데이터베이스 행이 존재할 경우에 + 예외상황을 던진다 + </para> + </listitem> + <listitem> + <para> + <literal>ReplicationMode.LATEST_VERSION</literal> - 행의 버전 번호가 객체의 버전 번호 보다 이전의 것이면 덮어쓰고, + 그 밖의 경우에 그 객체를 무시한다 + </para> + </listitem> + </itemizedlist> + + <para> + 이 특징의 쓰임새들은 다른 데이터베이스 인스턴스들 속으로 입력된 데이터 일치시키기, 제품 업그레이드 동안에 시스템 구성 정보 + 업데이트 하기, non-ACID 트랜잭션들 동안에 행해진 변경들을 롤백시키기 등을 포함한다. + </para> + + </sect1> + + <sect1 id="objectstate-flushing"> + <title>Session을 flush 시키기</title> + + <para> + 시간이 지남에 따라 <literal>Session</literal>은 JDBC 커넥션의 상태와 메모리 내에 보관된 객체들의 상태를 동기화 시키는데 + 필요한 SQL 문장들을 실행시킬 것이다. 이 프로세스 <emphasis>flush</emphasis>는 다음 시점들에서 디폴트로 발생한다 + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + 몇몇 질의들이 실행되기 전에 + </para> + </listitem> + <listitem> + <para> + <literal>org.hibernate.Transaction.commit()</literal> 시점에서 + </para> + </listitem> + <listitem> + <para> + <literal>Session.flush()</literal> 시점에서 + </para> + </listitem> + </itemizedlist> + + <para> + SQL 문장들이 다음 순서로 실행 명령이 내려진다 + </para> + + <orderedlist spacing="compact"> + <listitem> + <para> + + 대응하는 객체들이 <literal>Session.save()</literal>를 사용하여 저장되었던 것과 같은 순서로, 모든 엔티티 삽입들 + </para> + </listitem> + <listitem> + <para> + 모든 엔티티 업데이트들 + </para> + </listitem> + <listitem> + <para> + 모든 콜렉션 삭제들 + </para> + </listitem> + <listitem> + <para> + 모든 콜렉션 요소 삭제들, 업데이트들 그리고 삽입들 + </para> + </listitem> + <listitem> + <para> + 모든 콜렉션 삽입들 + </para> + </listitem> + <listitem> + <para> + 대응하는 객체들이 <literal>Session.delete()</literal>를 사용하여 삭제되었던 것과 같은 순서로 모든 엔티티 삭제들. + </para> + </listitem> + </orderedlist> + + <para> + (한가지 예외는 객체들이 저장될 때 <literal>native</literal> ID 생성을 사용하는 객체들이 insert 되는 점이다.) + </para> + + <para> + 당신이 명시적으로 <literal>flush()</literal> 시킬 때를 제외하면, <literal>Session</literal>이 JDBC 호출들을 + 실행시키는 <emphasis>시점</emphasis>, 그것들이 실행되는 <emphasis>순서</emphasis>만을 절대적으로 보장하지는 않는다. + 하지만 Hibernate는 <literal>Query.list(..)</literal>가 실효성이 없는 데이터를 결코 반환하지 않을 것임을 보장하거나; + 그것들이 잘못된 데이터도 반환하지 않을 것임을 보장한다. + </para> + + <para> + flush가 너무 자주 발생하지 않도록 디폴트 행위를 변경하는 것이 가능하다. <literal>FlushMode</literal> 클래스는 세 개의 + 다른 모드들을 정의한다: 오직 커밋 시(그리고 Hibernate <literal>Transaction</literal> API가 사용될 때에만) flush 모드, + 설명된 루틴을 사용하는 자동적인 flush 모드, 또는 <literal>flush()</literal>가 명시적으로 호출되지 않는 한 flush 시키지 + 않는 모드. 마지막 모드는 오래 동안 실행되는 작업 단위에 대해 유용하고, 여기서 <literal>Session</literal>은 열려진채로 + 유지되고 오랜 시간 동안 연결이 해제된 채로 유지된다. (<xref linkend="transactions-optimistic-longsession"/>를 보라). + </para> + + <programlisting><![CDATA[sess = sf.openSession(); +Transaction tx = sess.beginTransaction(); +sess.setFlushMode(FlushMode.COMMIT); // allow queries to return stale state + +Cat izi = (Cat) sess.load(Cat.class, id); +izi.setName(iznizi); + +// might return stale data +sess.find("from Cat as cat left outer join cat.kittens kitten"); + +// change to izi is not flushed! +... +tx.commit(); // flush occurs +sess.close();]]></programlisting> + + <para> + flush 동안에, 하나의 예외상황이 발생할 수도 있다(예를 들면. 만일 DML 오퍼레이션이 컨스트레인트를 위반할 경우). 예외상황들을 + 처리하는 것은 Hibernatem의 트랜잭션 특징에 관한 어떤 이해를 수반하며, 우리는 <xref linkend="transactions"/>에서 그것을 + 논의한다. + </para> + + </sect1> + + <sect1 id="objectstate-transitive" revision="1"> + <title>Transitive persistence(전이 영속)</title> + + <para> + 특히 당신이 연관된 객체들의 그래프를 다룰 경우에, 특히 개별 객체들을 저장하고, 삭제하거나, 재첨부시키는 것이 꽤 번거롭다. + 공통된 경우는 하나의 부모/자식 관계이다. 다음 예제를 검토하자: + </para> + + <para> + 만일 부모/자식 관계에서 자식들이 값(value) 타입(예를 들면. 주소들 또는 문자열들을 가진 하나의 콜렉션)일 경우, 그것들의 생명주기는 + 부모에 의존할 것이고 상태 변경들에 대해 편리한 "케스케이딩"에 더 이상의 액션이 필요하지 않을 것이다. 만일 부모가 저장될 때, + 값(value)-타입의 자식 객체들도 마찬가지로 저장되고, 부모가 삭제될 때, 자식들이 삭제될 것이다. 이것은 심지어 콜렉션으로부터 하나의 + 자식을 제거하는 그런 오퍼레이션들에 대해서도 동작한다; Hibernate는 이것을 검출하고, 값(value)-타입의 객체들은 참조를 공유할 수 + 없으므로, 데이터베이스로부터 그 자식을 삭제시킨다. + </para> + + <para> + 이제 값(value) 타입이 아닌, 엔티티들인 부모와 자식 객체들을 가진 동일한 시나리오를 검토하자(예를 들면. 카테고리들과 아이템들, + 또는 부모 고양이나 자식 고양이). 엔티티들은 그것들 자신의 생명주기를 갖고, 공유된 참조들을 지원하고 (따라서 콜렉션으로부터 하나의 + 엔티티를 제거하는 것은 그것이 삭제될 수 있음을 의미하지 않는다), 그리고 디폴트로 하나의 엔티티로부터 어떤 다른 연관된 엔티티들로의 + 상태의 케스케이딩은 존재하지 않는다. Hibernate는 디폴트로 <emphasis>도달가능성에 의한 영속성(persistence by reachability)</emphasis>을 + 구현하지 않는다. + </para> + + <para> + - <literal>persist(), merge(), saveOrUpdate(), delete(), lock(), refresh(), evict(), replicate()</literal>를 + 포함하는- Hibernate 세션에 대한 각각의 기본 오퍼레이션에 대해서 하나의 대응하는 케스케이딩 스타일이 존재한다. 케스케이드 스타일들 + 각각은 <literal>create, merge, save-update, delete, lock, refresh, evict, replicate</literal>로 명명된다. + 만일 당신이 하나의 오퍼레이션이 하나의 연관에 따라 케스케이딩되는 것을 원할 경우, 당신은 매핑 문서 내에 그것을 지시해야 한다. + 예를 들면: + </para> + + <programlisting><![CDATA[<one-to-one name="person" cascade="persist"/>]]></programlisting> + + <para> + 케스케이딩 스타일들이 결합될 수도 있다: + </para> + + <programlisting><![CDATA[<one-to-one name="person" cascade="persist,delete,lock"/>]]></programlisting> + + <para> + 당신은 <emphasis>모든</emphasis> 오퍼레이션들이 그 연관에 따라 케스케이드 되어야 함을 지정하는데 + <literal>cascade="all"</literal>을 사용할 수도 있다. 디폴트<literal>cascade="none"</literal>은 오퍼레이션들이 + 케스케이드 되지 않을 것임을 지정한다. + </para> + + <para> + 특정한 케스케이드 스타일인, <literal>delete-orphan</literal>은 오직 one-to-many 연관들에만 적용되고, + <literal>delete()</literal> 오퍼레이션이 그 연관으로부터 제거되는 임의의 자식 객체에 적용되어야 함을 나타낸다. + </para> + + + <para> + 권장사항들 : + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + 하나의 <literal>&lt;many-to-one&gt;</literal> 또는 <literal>&lt;many-to-many&gt;</literal> 연관에 + 대해 케스케이드를 가능하게 하는 것은 대개 의미가 없다. 케스케이드는 <literal>&lt;one-to-one&gt;</literal> 연관과 + <literal>&lt;one-to-many&gt;</literal> 연관에 대해 종종 유용하다. + </para> + </listitem> + <listitem> + <para> + 만일 자식 객체의 수명이 그 부모 객체의 수명에 묶여져 있을 경우, <literal>cascade="all,delete-orphan"</literal>을 + 지정함으로써 그것을 <emphasis>생명 주기 객체</emphasis>로 만들어라. + </para> + </listitem> + <listitem> + <para> + 그 밖의 경우, 당신은 케스케이드를 전혀 필요로 하지 않을 수 있다. 그러나 만일 당신이 동일한 트랜잭션 내에서 부모와 자식에 + 대해 자주 함께 작업하게 될 것이라 생각되고, 당신 스스로 타이핑 하는 것을 절약하고자 원할 경우, + <literal>cascade="persist,merge,save-update"</literal>를 사용하는 것을 고려하라. + </para> + </listitem> + </itemizedlist> + + <para> + <literal>cascade="all"</literal>을 가진 (단일 값 연관이든 하나의 콜렉션이든) 하나의 연관을 매핑시키는 것은 + 그 연관을 부모의 저장/업데이트/삭제가 자식 또는 자식들의 저장/업데이트/삭제로 귀결되는 <emphasis>부모/자식</emphasis> + 스타일의 관계로 마크한다. + </para> + <para> + 게다가, 하나의 영속 부모로부터 하나의 자식에 대한 단순한 참조는 자식의 저장/업데이트로 귀결될 것이다. 하지만 이 메타포는 불완전하다. + 그것의 부모에 의해 참조 해제되는 자식은 <literal>cascade="delete-orphan"</literal>으로 매핑된 하나의 + <literal>&lt;one-to-many&gt;</literal> 연관의 경우를 제외하면, 자동적으로 삭제되지 <emphasis>않는다</emphasis>. + 하나의 부모/자식 관계에 대한 케스케이딩 오퍼레이션의 정확한 의미는 다음과 같다: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + 만일 부모가 <literal>persist()</literal>에 전달될 경우, 모든 자식들이 <literal>persist()</literal>에 전달된다 + </para> + </listitem> + <listitem> + <para> + 만일 부모가 <literal>merge()</literal>에 전달될 경우, 모든 자식들이 <literal>merge()</literal>에 전달된다 + </para> + </listitem> + <listitem> + <para> + 만일 부모가 <literal>save()</literal>, <literal>update()</literal> 또는 <literal>saveOrUpdate()</literal>에 + 전달될 경우, 모든 자식들이 <literal>saveOrUpdate()</literal>에 전달된다 + </para> + </listitem> + <listitem> + <para> + 만일 transient 또는 detached 자식이 영속 부모에 의해 참조될 경우, 그것은 <literal>saveOrUpdate()</literal>에 전달된다 + </para> + </listitem> + <listitem> + <para> + 만일 부모가 삭제될 경우, 모든 자식들이 <literal>delete()</literal>에 전달된다 + </para> + </listitem> + <listitem> + <para> + 만일 자식이 영속 부모에 의해 참조 해제 될 경우, <literal>cascade="delete-orphan"</literal>이 아닌 한, + <emphasis>특별한 어떤 것도 발생하지 않는다</emphasis> - 어플리케이션은 필요한 경우에 자식을 명시적으로 삭제해야 한다 -, + <literal>cascade="delete-orphan"</literal>인 경우에 "orphaned(고아)"인 경우 자식이 삭제된다. + </para> + </listitem> + </itemizedlist> + + </sect1> + + <para> + 마지막으로 오퍼레이션들의 케스케이딩이 <emphasis>호출 시점</emphasis>에서 또는 <emphasis>flush 시점</emphasis>에서 + 객체 그래프에 적용될 수 있음을 노트하라. 이용 가능할 경우에 모든 오퍼레이션들은 그 오퍼레이션이 실행될 때 도달 가능한 연관된 + 엔티티들에 대해 케스케이드 된다. 하지만 <literal>save-upate</literal>와 <literal>delete-orphan</literal>은 + <literal>Session</literal>의 flush 동안에 도달 가능한 모든 연관된 엔티티들에 대해 이행적(transitive)이다. + </para> + + <sect1 id="objectstate-metadata"> + <title>메타데이터 사용하기</title> + + <para> + Hibernate는 모든 엔티티와 값(value) 타입들을 가진 매우 풍부한 메타-레벨 모형을 필요로 한다. 시간이 지남에 따라, 이 모형은 + 어플리케이션 그 자체에 매우 유용하다. 예를 들어, 어플리케이션은 어느 객체들이 복사되어야 하는지(예를 들면 가변적인 값(value) 타입들) + 그리고 어느 것이 복사되지 말아야 하는지(예를 들면, 불변의 value 타입들과 가능한 연관된 엔티티들)를 인지하는 "스마트" deep-copy + 알고리즘을 구현하는데 Hibernate의 메타데이터를 사용할 수도 있다. + </para> + <para> + Hibernate는 <literal>ClassMetadata</literal> 인터페이스와 <literal>CollectionMetadata</literal> 인터페이스 + 그리고 <literal>Type</literal> 계층구조를 통해 메타데이터를 노출시킨다. 메타데이터 인터페이스들의 인스턴스들은 + <literal>SessionFactory</literal>로부터 얻어질 수도 있다. + </para> + + <programlisting><![CDATA[Cat fritz = ......; +ClassMetadata catMeta = sessionfactory.getClassMetadata(Cat.class); + +Object[] propertyValues = catMeta.getPropertyValues(fritz); +String[] propertyNames = catMeta.getPropertyNames(); +Type[] propertyTypes = catMeta.getPropertyTypes(); + +// get a Map of all properties which are not collections or associations +Map namedValues = new HashMap(); +for ( int i=0; i<propertyNames.length; i++ ) { + if ( !propertyTypes[i].isEntityType() && !propertyTypes[i].isCollectionType() ) { + namedValues.put( propertyNames[i], propertyValues[i] ); + } +}]]></programlisting> + + </sect1> + +</chapter> + Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/toolset_guide.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/toolset_guide.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/toolset_guide.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/toolset_guide.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,588 @@ +<chapter id="toolsetguide" revision="2"> + <title>도구셋 안내</title> + + <para> + Hibernate에 대한 라운드트립 엔지니어링은 Eclipse 플러그인 세트, 명령라인 도구들, 뿐만 아니라 Ant 태스크들을 사용하여 가능하다. + </para> + + <para> + <emphasis>Hibernate 도구들</emphasis>은 현재 기존 데이터베이스들에 대한 리버스 엔지니어링을 위해 Ant 태스크들 뿐만 아니라 + Eclipse IDE용 플러그인들을 포함하고 있다: + </para> + + <itemizedlist> + <listitem><para> + <emphasis>매핑 편집기:</emphasis> 자동 완성 기능과 구문 강조를 지원하는 Hibernate XML 매핑 파일들에 대한 편집기. 그것은 또한 + 통상의 XML 편집기 보다 훨씬 더 융통성 있게 만들어서 클래스 이름들과 프로퍼티/필드 이름들에 대한 의미론적 자동 완성 기능을 지원한다. + </para></listitem> + <listitem><para> + <emphasis>콘솔:</emphasis> 콘솔은 Eclipse에서 새로운 뷰이다. 당신의 콘솔 구성들에 대한 tree overview에 덧붙여, 당신은 또한 + 당신의 영속 클래스들과 그것들의 관계들에 대한 상호작용 뷰를 얻는다. 콘솔은 당신의 데이터베이스에 대해 HQL 질의들을 실행하고 그 결과를 + Eclipse 내에서 직접 브라우징 하도록 당신에게 허용해준다. + </para></listitem> + <listitem><para> + <emphasis>개발 마법사들:</emphasis> 몇몇 마법사들이 Hibernate Eclipse 도구들에 제공된다; 당신은 Hibernate 구성 + (cfg.xml) 파일들을 빠르게 생성시키는데 마법사를 사용하거나, 심지어 당신은 기존 데이터베이스 스키마를 POJO 소스 파일들과 + Hibernate 매핑 파일들로 완전하게 리버스 엔지니어링할 수도 있다. 리버스 엔지니어링 마법사는 맞춤 가능한 템플릿들을 제공한다. + </para></listitem> + <listitem><para> + <emphasis>Ant 태스크들:</emphasis> + </para></listitem> + + </itemizedlist> + + <para> + 추가 정보는 <emphasis>Hibernate Tools</emphasis> 패키지와 그것의 문서를 참조하길 바란다. + </para> + + <para> + 하지만 Hibernate 메인 패키지는 통합 도구에 번들화 되어 있다(그것은 심지어 플라이 상에서 Hibernate "내에서" 사용될 수 있다): + <emphasis>SchemaExport</emphasis> 별칭은 <literal>hbm2ddl</literal>. + </para> + + <sect1 id="toolsetguide-s1" revision="2"> + <title>자동적인 스키마 생성</title> + + <para> + DDL은 Hibernate 유틸리티에 의해 당신의 매핑 파일들로부터 생성될 수 있다. 생성된 스키마는 엔티티 테이블과 콜렉션 테이블에 대한 + 참조 무결성 컨스트레인트들(프라이머리 키와 foreign 키들)을 포함한다. 테이블들과 시퀀스들은 또한 페칭된 식별자 생성기들에 대해 + 생성된다. + </para> + + <para> + DDL이 매우 벤더에 특정하므로, 이 도구를 사용할 때 당신은 <literal>hibernate.dialect</literal> 프로퍼티를 통해 한 개의 SQL + <literal>Dialect</literal>를 지정<emphasis>해야 한다</emphasis>. + </para> + + <para> + 먼저 생성된 스키마를 개선시키기 위해 당신의 매핑 파일들을 맞춤화 시켜라. + </para> + + <sect2 id="toolsetguide-s1-2" revision="3"> + <title>스키마 맞춤화 시키기</title> + + <para> + 많은 Hibernate 매핑 요소들은 <literal>length</literal>로 명명된 옵션 속성을 정의한다. 당신은 이 속성으로 컬럼의 길이를 + 설정할 수 있다.(또는 numeric/decimal 데이터 타입들, 배정도에 대해 ). + 많은 Hibernate 매칭 요소들은 <literal>length</literal>, <literal>precision</literal> 그리고 + <literal>scale</literal>로 명명된 옵션 속성들을 정의하고 있다. 당신은 이 속성으로서 컬럼이 길이, 정밀도, 크기를 설정할 수 있다. + + </para> + + <programlisting><![CDATA[<property name="zip" length="5"/>]]></programlisting> + <programlisting><![CDATA[<property name="balance" precision="12" scale="2"/>]]></programlisting> + + <para> + 몇몇 태그들은 또한 (테이블 컬럼들에 대한 <literal>NOT NULL</literal> 컨스트레인트를 생성시키는) <literal>not-null</literal> + 속성과 (테이블 컬럼들에 대한 <literal>UNIQUE</literal> 컨스트레인트를 생성시키는) <literal>unique</literal> 속성을 수용한다. + </para> + + <programlisting><![CDATA[<many-to-one name="bar" column="barId" not-null="true"/>]]></programlisting> + + <programlisting><![CDATA[<element column="serialNumber" type="long" not-null="true" unique="true"/>]]></programlisting> + + <para> + <literal>unique-key</literal> 속성은 하나의 유일 키 컨스트레인트로 컬럼들을 그룹지우는데 사용될 수도 있다. 현재 + <literal>unique-key</literal> 속성의 지정된 값은 산출된 DDL내에서 컨스트레인트를 명명하는데 사용되지 <emphasis>않고</emphasis>, + 오직 매핑 파일 내에서 컬럼들을 그룹 지우는데 사용된다. + </para> + + <programlisting><![CDATA[<many-to-one name="org" column="orgId" unique-key="OrgEmployeeId"/> +<property name="employeeId" unique-key="OrgEmployee"/>]]></programlisting> + + + <para> + <literal>index</literal> 속성은 매핑된 컬럼 또는 컬럼들을 사용하여 생성될 인덱스의 이름을 지정한다. 간단하게 + 동일한 인덱스 이름을 지정함으로써 여러 컬럼들이 동일한 인덱스 내로 그룹지워질 수도 있다. + </para> + + <programlisting><![CDATA[<property name="lastName" index="CustName"/> +<property name="firstName" index="CustName"/>]]></programlisting> + + <para> + <literal>foreign-key</literal> 속성은 임의의 산출된 foreign 키 컨스트레인트의 이름을 + 오버라이드 시키는데 사용될 수 도 있다. + </para> + + <programlisting><![CDATA[<many-to-one name="bar" column="barId" foreign-key="FKFooBar"/>]]></programlisting> + + <para> + 많은 매핑 요소들은 또한 하나의 자식 <literal>&lt;column&gt;</literal> 요소를 허용한다. + 이것은 특히 다중 컬럼 타입들을 매핑하는데 유용하다: + </para> + + <programlisting><![CDATA[<property name="name" type="my.customtypes.Name"/> + <column name="last" not-null="true" index="bar_idx" length="30"/> + <column name="first" not-null="true" index="bar_idx" length="20"/> + <column name="initial"/> +</property>]]></programlisting> + + <para> + 다른 방법으로, 이들 요소들은 또한 자식 <literal>&lt;column&gt;</literal> 요소를 수용한다. 이것은 다중 컬럼 타입들에 + 특히 유용하다: + <literal>default</literal> 속성은 당신으로 하여금 하나의 컬럼에 대한 디폴트 값을 설정하도록 한다(당신은 매핑된 + 클래스의 새로운 인스턴스를 저장하기 전에 매핑된 프로퍼티에 동일한 값을 할당하게 될 것이다). + </para> + + <programlisting><![CDATA[<property name="credits" type="integer" insert="false"> + <column name="credits" default="10"/> +</property>]]></programlisting> + + <programlisting><![CDATA[<version name="version" type="integer" insert="false"> + <column name="version" default="0"/> +</property>]]></programlisting> + + <para> + <literal>sql-type</literal> 속성은 SQL 데이터타입에 대한 Hibernate 타입의 디폴트 매핑을 오버라이드 시키는 것을 + 사용자에게 허용해준다. + </para> + + <programlisting><![CDATA[<property name="balance" type="float"> + <column name="balance" sql-type="decimal(13,3)"/> +</property>]]></programlisting> + + <para> + <literal>check</literal> 속성은 check 컨스트레인트를 지정하는 것을 당신에게 허용해준다. + </para> + + <programlisting><![CDATA[<property name="foo" type="integer"> + <column name="foo" check="foo > 10"/> +</property>]]></programlisting> + + <programlisting><![CDATA[<class name="Foo" table="foos" check="bar < 100.0"> + ... + <property name="bar" type="float"/> +</class>]]></programlisting> + + + <table frame="topbot" id="schemattributes-summary" revision="2"> + <title>요약</title> + <tgroup cols="3"> + <colspec colwidth="1*"/> + <colspec colwidth="1*"/> + <colspec colwidth="2.5*"/> + <thead> + <row> + <entry>속성</entry> + <entry>값들</entry> + <entry>해석</entry> + </row> + </thead> + <tbody> + <row> + <entry><literal>length</literal></entry> + <entry>number</entry> + <entry>컬럼 길이</entry> + </row> + <row> + <entry><literal>precision</literal></entry> + <entry>number</entry> + <entry>컬럼 decimal 정밀도</entry> + </row> + <row> + <entry><literal>scale</literal></entry> + <entry>number</entry> + <entry>컬럼 decimal 크기</entry> + </row> + <row> + <entry><literal>not-null</literal></entry> + <entry><literal>true|false</literal></entry> + <entry>컬럼이 null이 아니어야 함을 지정한다</entry> + </row> + <row> + <entry><literal>unique</literal></entry> + <entry><literal>true|false</literal></entry> + <entry>컬럼이 하나의 유일 컨스트레인트를 가져야함을 지정한다</entry> + </row> + <row> + <entry><literal>index</literal></entry> + <entry><literal>index_name</literal></entry> + <entry>(다중-컬럼) 인덱스의 이름을 지정한다 </entry> + </row> + <row> + <entry><literal>unique-key</literal></entry> + <entry><literal>unique_key_name</literal></entry> + <entry>다중-컬럼 유일 컨스트레인트의 이름을 지정한다</entry> + </row> + <row> + <entry><literal>foreign-key</literal></entry> + <entry><literal>foreign_key_name</literal></entry> + <entry> + 하나의 연관에 대해, <literal>&lt;one-to-one&gt;</literal>, + <literal>&lt;many-to-one&gt;</literal>, + <literal>&lt;key&gt;</literal>, 또는 <literal>&lt;many-to-many&gt;</literal> + 매핑 요소에 대해 foreign key 컨스트레인트의 이름을 지정한다.<literal>inverse="true"</literal> + 측들은 <literal>SchemaExport</literal>에 의해 고려되지 않을 것임을 노트하라. + </entry> + </row> + <row> + <entry><literal>sql-type</literal></entry> + <entry><literal>SQL column type</literal></entry> + <entry> + 디폴트 컬럼 타입을 오버라이드 시킨다 + (<literal>&lt;column&gt;</literal> 요소의 속성에만) + </entry> + </row> + <row> + <entry><literal>default</literal></entry> + <entry>SQL expression</entry> + <entry> + 컬럼에 대한 디폴트 값을 지정한다 + </entry> + </row> + <row> + <entry><literal>check</literal></entry> + <entry>SQL expression</entry> + <entry> + 컬럼 또는 테이블에 대한 SQL check 컨스트레인트를 생성시킨다 + </entry> + </row> + </tbody> + </tgroup> + </table> + + <para> + <literal>&lt;comment&gt;</literal> 요소는 생성된 스키마에 대한 주석들을 지정하는 것을 당신에게 허용해준다. + </para> + + <programlisting><![CDATA[<class name="Customer" table="CurCust"> + <comment>Current customers only</comment> + ... +</class>]]></programlisting> + + <programlisting><![CDATA[<property name="balance"> + <column name="bal"> + <comment>Balance in USD</comment> + </column> +</property>]]></programlisting> + + <para> + 이것은 (지원되는 경우) 생성된 DDL에서 <literal>comment on table</literal> 또는 + <literal>comment on column</literal> 문장으로 귀결된다. + </para> + + </sect2> + + <sect2 id="toolsetguide-s1-3" revision="2"> + <title>도구 실행하기</title> + + <para> + <literal>SchemaExport</literal> 도구는 DDL 스크립트를 표준 출력으로 기록 하고/하거나 DDL 문장들을 실행시킨다. + </para> + + <para> + <literal>java -cp </literal><emphasis>hibernate_classpaths</emphasis> + <literal>org.hibernate.tool.hbm2ddl.SchemaExport</literal> <emphasis>options mapping_files</emphasis> + </para> + + <table frame="topbot"> + <title><literal>SchemaExport</literal> 명령 라인 옵션들</title> + <tgroup cols="2"> + <colspec colwidth="1.5*"/> + <colspec colwidth="2*"/> + <thead> + <row> + <entry>옵션</entry> + <entry>설명</entry> + </row> + </thead> + <tbody> + <row> + <entry><literal>--quiet</literal></entry> + <entry>스크립트를 표준출력으로 출력하지 않는다</entry> + </row> + <row> + <entry><literal>--drop</literal></entry> + <entry>오직 테이블들을 드롭시킨다</entry> + </row> + <row> + <entry><literal>--create</literal></entry> + <entry>오직 테이블들을 생성시킨다</entry> + </row> + <row> + <entry><literal>--text</literal></entry> + <entry>데이터베이스로 내보내기 하지 않는다</entry> + </row> + <row> + <entry><literal>--output=my_schema.ddl</literal></entry> + <entry>ddl 스크립트를 파일로 출력한다</entry> + </row> + <row> + <entry><literal>--naming=eg.MyNamingStrategy</literal></entry> + <entry>하나의 <literal>NamingStrategy</literal>를 선택한다</entry> + </row> + <row> + <entry><literal>--config=hibernate.cfg.xml</literal></entry> + <entry>XML 파일로부터 Hibernate 구성을 읽어들인다</entry> + </row> + <row> + <entry><literal>--properties=hibernate.properties</literal></entry> + <entry>파일로부터 데이터베이스 프로퍼티들을 읽어들인다</entry> + </row> + <row> + <entry><literal>--format</literal></entry> + <entry>생성된 SQL을 스크립트 내에 좋게 형식지운다</entry> + </row> + <row> + <entry><literal>--delimiter=;</literal></entry> + <entry>스크립트를 위한 라인 경계의 끝을 설정한다 </entry> + </row> + </tbody> + </tgroup> + </table> + + <para> + 당신은 당신의 어플리케이션 내에 <literal>SchemaExport</literal>를 삽입시킬 수도 있다: + </para> + + <programlisting><![CDATA[Configuration cfg = ....; +new SchemaExport(cfg).create(false, true);]]></programlisting> + + </sect2> + + <sect2 id="toolsetguide-s1-4"> + <title>프로퍼티들</title> + + <para> + 데이터베이스 프로퍼티들은 다음과 같이 지정될 수 있다 + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para><literal>-D</literal><emphasis>&lt;property&gt;</emphasis>를 가진 시스템 프로퍼티로서</para> + </listitem> + <listitem> + <para><literal>hibernate.properties</literal> 내에서</para> + </listitem> + <listitem> + <para><literal>--properties</literal>를 가진 명명된 프로퍼티들 내에서</para> + </listitem> + </itemizedlist> + + <para> + 필요한 프로퍼티들은 다음과 같다: + </para> + + <table frame="topbot"> + <title>SchemaExport 커넥션 프로퍼티들</title> + <tgroup cols="2"> + <colspec colwidth="1.5*"/> + <colspec colwidth="2*"/> + <thead> + <row> + <entry>프로퍼티 이름</entry> + <entry>설명</entry> + </row> + </thead> + <tbody> + <row> + <entry><literal>hibernate.connection.driver_class</literal></entry> + <entry>jdbc 드라이버 클래스</entry> + </row> + <row> + <entry><literal>hibernate.connection.url</literal></entry> + <entry>jdbc url</entry> + </row> + <row> + <entry><literal>hibernate.connection.username</literal></entry> + <entry>데이터베이스 사용자</entry> + </row> + <row> + <entry><literal>hibernate.connection.password</literal></entry> + <entry>사용자 패스워드</entry> + </row> + <row> + <entry><literal>hibernate.dialect</literal></entry> + <entry>dialect</entry> + </row> + </tbody> + </tgroup> + </table> + + </sect2> + + <sect2 id="toolsetguide-s1-5"> + <title>Ant 사용하기</title> + + <para> + 당신은 당신의 Ant 빌드 스크립트에서 <literal>SchemaExport</literal>를 호출할 수 있다: + </para> + + <programlisting><![CDATA[<target name="schemaexport"> + <taskdef name="schemaexport" + classname="org.hibernate.tool.hbm2ddl.SchemaExportTask" + classpathref="class.path"/> + + <schemaexport + properties="hibernate.properties" + quiet="no" + text="no" + drop="no" + delimiter=";" + output="schema-export.sql"> + <fileset dir="src"> + <include name="**/*.hbm.xml"/> + </fileset> + </schemaexport> +</target>]]></programlisting> + + </sect2> + + <sect2 id="toolsetguide-s1-6" revision="2"> + <title>점증하는 스키마 업데이트들</title> + + <para> + <literal>SchemaUpdate</literal> 도구는 "점증하는" 변경들을 가진 기존 스키마를 변경시킬 것이다. <literal>SchemaUpdate</literal>는 + JDBC 메타데이터 API에 무겁게 의존하여서, 그것은 모든 JDBC 드라이버들에 동작하지 않을 것임을 주목하라. + </para> + + <para> + <literal>java -cp </literal><emphasis>hibernate_classpaths</emphasis> + <literal>org.hibernate.tool.hbm2ddl.SchemaUpdate</literal> <emphasis>options mapping_files</emphasis> + </para> + + <table frame="topbot"> + <title><literal>SchemaUpdate</literal> 명령 라인 옵션들</title> + <tgroup cols="2"> + <colspec colwidth="1.5*"/> + <colspec colwidth="2*"/> + <thead> + <row> + <entry>옵션</entry> + <entry>설명</entry> + </row> + </thead> + <tbody> + <row> + <entry><literal>--quiet</literal></entry> + <entry>스크립트를 표준출력으로 출력하지 않는다</entry> + </row> + <row> + <entry><literal>--text</literal></entry> + <entry>스크립트를 데이터베이스로 내보내기 하지 않는다</entry> + </row> + <row> + <entry><literal>--naming=eg.MyNamingStrategy</literal></entry> + <entry>하나의 <literal>NamingStrategy</literal>를 선택한다</entry> + </row> + <row> + <entry><literal>--properties=hibernate.properties</literal></entry> + <entry>파일로부터 데이터베이스 프로퍼티들을 읽어 들인다</entry> + </row> + <row> + <entry><literal>--config=hibernate.cfg.xml</literal></entry> + <entry><literal>.cfg.xml</literal> 파일을 지정한다</entry> + </row> + </tbody> + </tgroup> + </table> + + <para> + 당신은 당신의 어플리케이션 내에 <literal>SchemaUpdate</literal>를 삽입시킬 수 있다: + </para> + + <programlisting><![CDATA[Configuration cfg = ....; +new SchemaUpdate(cfg).execute(false);]]></programlisting> + + </sect2> + + <sect2 id="toolsetguide-s1-7"> + <title>점증하는 스키마 업데이트들에 Ant 사용하기</title> + + <para> + 당신은 Ant 스크립트에서<literal>SchemaUpdate</literal>를 호출할 수 있다: + </para> + + <programlisting><![CDATA[<target name="schemaupdate"> + <taskdef name="schemaupdate" + classname="org.hibernate.tool.hbm2ddl.SchemaUpdateTask" + classpathref="class.path"/> + + <schemaupdate + properties="hibernate.properties" + quiet="no"> + <fileset dir="src"> + <include name="**/*.hbm.xml"/> + </fileset> + </schemaupdate> +</target>]]></programlisting> + + </sect2> + + <sect2 id="toolsetguide-s1-8" revision="1"> + <title>스키마 유효성 검사</title> + + <para> + <literal>SchemaValidator</literal> 도구는 기존의 데이터베이스 스키마가 당신의 매핑 문서들과 "일치하는지"를 유효성 + 검사할 것이다. <literal>SchemaValidator</literal>가 JDBC 메타데이터 API에 무겁게 의존하므로 그것은 모든 + JDBC 드라이버들에 대해 동작하지 않을 것이다. 이 도구는 테스팅에 극히 유용하다. + </para> + + <para> + <literal>java -cp </literal><emphasis>hibernate_classpaths</emphasis> + <literal>org.hibernate.tool.hbm2ddl.SchemaValidator</literal> <emphasis>options mapping_files</emphasis> + </para> + + <table frame="topbot"> + <title><literal>SchemaValidator</literal> 명령 라인 옵션들</title> + <tgroup cols="2"> + <colspec colwidth="1.5*"/> + <colspec colwidth="2*"/> + <thead> + <row> + <entry>옵션</entry> + <entry>설명</entry> + </row> + </thead> + <tbody> + <row> + <entry><literal>--naming=eg.MyNamingStrategy</literal></entry> + <entry>하나의 <literal>NamingStrategy</literal>를 선택한다</entry> + </row> + <row> + <entry><literal>--properties=hibernate.properties</literal></entry> + <entry>파일로부터 데이터베이스 프로퍼티들을 읽어들인다</entry> + </row> + <row> + <entry><literal>--config=hibernate.cfg.xml</literal></entry> + <entry><literal>.cfg.xml</literal> 파일을 지정한다</entry> + </row> + </tbody> + </tgroup> + </table> + + <para> + 당신은 당신의 어플리케이션 내에 <literal>SchemaValidator</literal>을 삽입시킬 수 도 있다: + </para> + + <programlisting><![CDATA[Configuration cfg = ....; +new SchemaValidator(cfg).validate();]]></programlisting> + + </sect2> + + <sect2 id="toolsetguide-s1-9"> + <title>스키마 유효성 검사를 위해 Ant 사용하기</title> + + <para> + 당신은 Ant 스크립트에서 <literal>SchemaValidator</literal>를 호출할 수 있다: + </para> + + <programlisting><![CDATA[<target name="schemavalidate"> + <taskdef name="schemavalidator" + classname="org.hibernate.tool.hbm2ddl.SchemaValidatorTask" + classpathref="class.path"/> + + <schemavalidator + properties="hibernate.properties"> + <fileset dir="src"> + <include name="**/*.hbm.xml"/> + </fileset> + </schemavalidator> +</target>]]></programlisting> + + </sect2> + + </sect1> + +</chapter> + Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/transactions.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/transactions.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/transactions.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/transactions.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,1004 @@ +<chapter id="transactions" revision="2"> + <title>트랜잭션들과 동시성</title> + + <para> + Hibernate와 동시성 제어에 대한 가장 중요한 점은 이해하기가 매우 쉽다는 점이다. Hibernate는 어떤 추가적인 잠금 행위 없이 + JDBC 커넥션들과 JTA 리소스들을 직접 사용한다. 우리는 당신의 데이터베이스 관리 시스템의 JDBC, ANSI, 그리고 트랜잭션 격리 명세에 + 약간의 시간을 할애할 것을 매우 권장한다. + </para> + + <para> + Hibernate는 메모리 내에서 객체들을 잠그지 않는다. 당신의 어플리케이션은 격리 레벨에 의해 정의된 대로 행위를 기대할 수 있다. + 또한 transaction-영역의 캐시인 <literal>Session</literal> 덕분에, Hibernate는 (스칼라 값들을 반환하는 질의들을 보고하지 않는) + 식별자와 엔티티 질의들에 의한 룩업을 위해 반복 가능한 읽기를 제공한다. + </para> + + <para> + 자동적인 optimistic 동시성 제어를 위한 버전화에 덧붙여, Hibernate는 또한 <literal>SELECT FOR UPDATE</literal> + 구문을 사용하여 행들에 대한 pessimistic 잠금을 위한 하나의 (마이너)API를 제공한다. optimistic 동시성 제어와 이 API는 + 이 장의 뒷부분에서 논의된다. + </para> + + <para> + 우리는 <literal>Configuration</literal>, <literal>SessionFactory</literal>, <literal>Session</literal>, + 알갱이를 가진 Hibernate에서의 동시성 제어 뿐만 아니라 데이터베이스 트랜잭션과 장기간에 걸친 (컴퓨터와의)대화들에 대한 논의를 시작한다. + </para> + + <sect1 id="transactions-basics" revision="1"> + <title>세션 영역과 트랜잭션 영역</title> + + <para> + <literal>SessionFactory</literal>는 모든 어플리케이션 쓰레드들에 의해 공유되도록 고안된 생성에 비용이 드는, + 쓰레드안전(threadsafe) 객체이다. 그것은 대개 어플리케이션 시작 시에 <literal>Configuration</literal> 인스턴스로부터 + 한번 생성된다. + </para> + + <para> + <literal>Session</literal>은 하나의 요청, 하나의 대화 , 하나의 작업 단위를 위해 한번만 사용되고 나서 폐기될 예정인, + 비용이 들지 않는, 쓰레드 안전하지 않은 객체이다. <literal>Session</literal>은 커넥션이 필요하지 않으면 하나의 JDBC + <literal>Connection</literal>(또는 <literal>Datasource</literal>)를 얻지 않을 것이므로, 사용될 때까지 + 리소스들을 소비하지 않는다. + </para> + + <para> + 이 그림을 완성하기 위해 당신은 또한 데이터베이스 트랜재션들에 대해 생각해야 한다. 데이터베이스 트랜잭션은 데이터베이스에서 + 잠금 다툼을 줄이기 위해 가능한 짧아야 한다. 긴 데이터베이스 트랜잭션들은 당신의 어플리케이션이 고도의 동시성 로드로의 가용성을 + 높이는 것을 방해할 것이다. 그러므로 사용자가 생각하는 시간 동안 단위 작업이 완료될 때까지 데이터베이스 트랜잭션을 열려진채로 + 소유하는 것은 대개 결코 좋은 설계는 아니다. + </para> + + <para> + 하나의 작업 단위의 영역은 무엇인가? 하나의 Hibernate <literal>Session</literal>은 몇몇 데이터베이스 트랜잭션들에 + 걸칠 수 있는가 또는 이것은 영역들의 one-to-one 관계인가? 당신은 언제 <literal>Session</literal>을 열고 닫는가 + 그리고 당신은 데이터베이스 트랜잭션 경계들을 어떻게 한정하는가? + </para> + + <sect2 id="transactions-basics-uow" revision="1"> + <title>작업 단위</title> + + <para> + 첫번째로, <emphasis>session-per-operation</emphasis> anti-패턴을 사용하지 말라. 즉, 단일 쓰레드 내에서 + 모든 간단한 데이터베이스 호출에 대해 <literal>Session</literal>을 열고 닫지 말라! 물론 같은 것이 데이터베이스 + 트랜잭션들에 대해서도 참이다. 어플리케이션 내의 데이터베이스 호출들은 계획된 순서를사용하여 행해지며, 그것들은 원자 + 작업 단위 속으로 그룹지워진다. (이것은 또한 모든 하나의 SQL 문장 뒤의 auto-commit(자동-커밋)이 어플리케이션 내에서 + 무용지물임을 의미하고, 이 모드가 SQL 콘솔 작업을 돕도록 고안되었음을 노트하라. Hibernate는 + 의미하고, 이 모드는 Hibernate는 즉시 자동-커밋 모드를 사용 불가능하게 하거나, 어플리케이션 서버가 그렇게 행하고, + 즉시 자동-커밋시키는 것을 사용불가능하게 하거나 ,그렇게 행하는 것을 기대한다.) 데이터베이스 트랜잭션들은 결코 옵션이 아니며, + 하나의 데이터베이스와의 모든 통신은 당신이 데이터를 읽든 쓰단간에 상관없이 하나의 트랜잭션 내에서 발생해야 한다. + 설명하였듯이, 데이터 읽기를 위한 auto-commit 특징을 피해야 할 것이며, 많은 작은 트랜잭션들은 하나의 명료하게 정의된 + 작업 단위보다 더 좋게 수행될 것 같지 않다. 후자가 또한 훨씬 더 유지가능하고 확장적이다. + </para> + + <para> + 다중 사용자 클라이언트/서버 어플리케이션에서 가장 공통된 패턴은 <emphasis>session-per-request</emphasis>이다. + 이 모형에서, 클라이언트로부터의 요청은 (Hibernate 영속 계층이 실행되는) 서버로 전송되고, 새로운 Hibernate + <literal>Session</literal>이 열려지고, 모든 데이터베이스 오퍼레이션들이 이 작업 단위 내에서 실행된다. 일단 그 작업이 + 완료되었다면(그리고 클라이언트에 대한 응답이 준비되었다면), 그 세션은 flush 되고 닫혀진다. 당신은 또한 당신이 + <literal>Session</literal>을 열고 닫을 때 그것을 시작하고 커밋시켜서 클라이언트 요청에 서비스하는데 한 개의 데이터베이스 + 트랜잭션을 사용하게 될 것이다. 둘 사이의 관계는 일대일 대응이고 이 모형은 많은 어플리케이션들에서 완전하게 적합하다. + </para> + + <para> + 난제는 구현에 놓여있다: Hibernate는 이 패턴을 단순화 시키기 위해 "현재 세션"에 관한 미리 빌드된 관리를 제공한다. 당신이 + 행해야할 모든 것은 서버 요청이 처리되어야 할 때 트랜잭션을 시작하고, 그 응답이 클라이언트로 전송되기 전에 트랜잭션을 끝내는 + 것이다. 당신은 당신이 좋아하는 임의의 방법으로 이것을 행할 수 있으며, 공통된 해결책들은 서비스 메소드들 상의 첨단, 또는 + 하나의 프락시/인터셉션 컨테이너를 가진 APO 인터셉터인, <literal>ServletFilter</literal>이다. 하나의 EJB + 컨테이너는 CMT의 경우에 선언적으로 EJB session beans 상에 트랜잭션 경계구분과 같은 동시 대조 측면들을 구현하는 + 표준 방법이다. 만일 당신이 프로그램 상의 트랜잭션 경계구분을 사용하고자 결정한다면, 사용의 용이성과 코드 이식성을 위해 + 이 장의 뒷 부분에서 보여진 Hibernate <literal>Transaction</literal>을 선호하라. + </para> + + <para> + 당신의 어플리케이션 코드는 어디서든 필요할 때 종종 <literal>sessionFactory.getCurrentSession()</literal>을 + 간단히 호출함으로써 요청을 처리할 "현재 세션"에 접근할 수 있다. 당신은 현재 데이터베이스 트랜잭션으로 영역화된 하나의 + <literal>Session</literal>을 항상 얻게 될 것이다. 이것은 resource-local 환경 또는 JTA 환경에 대해 구성되어야 + 하며, <xref linkend="architecture-current-session"/>을 보라. + </para> + + <para> + 때때로 "뷰가 렌더링될 때까지" 하나의 <literal>Session</literal> 과 데이터베이스 트랜잭션의 영역을 확장시키는 것이 + 편리하다. 이것은 요청이 처리된 후에 하나의 별도의 렌더링 단계를 활용하는 서블릿 어플리케이션들에서 특히 유용하다. + 뷰 렌더링이 완료될 때까지 데이터베이스 트랜잭션을 확장하는 것은 당신이 당신 자신의 인터셉터를 구현하는 경우에 행하기가 쉽다. + 하지만 만일 당신이 컨테이너에 의해 관리되는 트랜잭션들을 가진 EJB들에 의존할 경우에, 하나의 EJB 메소드가 반환될 때 + 임의의 뷰 렌더링이 시작될 수 있기 전에 하나의 트랜잭션이 완료되기 때문에, 행하는 것이 쉽지 않다. 이 + <emphasis>Open Session in View</emphasis> 패턴을 둘러싼 팁들과 예제들은 Hibernate 웹 사이트와 포럼을 보라. + </para> + + </sect2> + + <sect2 id="transactions-basics-apptx" revision="1"> + <title>장기간의 대화</title> + + <para> + session-per-request 패턴은 당신이 작업 단위들을 설계하는데 사용할 수 있는 유일한 유용한 개념이 아니다. 많은 비지니스 + 프로세스들은 데이터베이스 접근들을 중재하는 사용자 사이의 전체 일련의 상호작용들을 필요로 한다. 웹과 엔터프라이즈 + 어플리케이션에서 사용자 상호작용에 걸치는 것은 데이터베이스 트랜잭션에 허용되지 않는다. 다음 예제를 검토하자: + </para> + + <itemizedlist> + <listitem> + <para> + 대화상자의 첫 번째 화면이 열리고, 사용자에게 보여진 데이터는 특정 <literal>Session</literal>과 데이터베이스 + 트랜잭션 속에 로드되었다. 사용자가 객체들을 변경시키는 것이 자유롭다. + </para> + </listitem> + <listitem> + <para> + + 사용자는 5분 후에 "저장"을 클릭하고 그의 변경들이 영속화 되기를 기대한다; 그는 또한 그가 이 정보를 편집하는 유일한 + 개인이고 변경 충돌이 발생하지 않기를 기대한다. + </para> + </listitem> + </itemizedlist> + + <para> + 우리는 사용자의 관점에서, 이것을 작업 단위, 장기간 실행되는 <emphasis>대화</emphasis> + (또는 <emphasis>어플리케이션 트랜잭션</emphasis>)이라고 명명한다. + 당신이 당신의 어플리케이션에서 이것을 어떻게 구현할 수 있는 많은 방법들이 존재한다. + </para> + + <para> + 첫 번째 naive 구현은 동시성 변경을 방지하고, 격리와 atomicity(원자 단위성)을 보장하기 위해 데이터베이스에 의해 + 소유된 잠금으로 사용자가 생각하는동안 <literal>Session</literal>과 데이터베이스 트랜잭션을 유지할 수도 있다. + 이것은 물론 anti-패턴이다. 왜냐하면 잠금 다툼은 어플리케이션이 동시 사용자들의 가용 숫자를 높이는 것을 허용하지 + 않을 것이기 때문이다. + </para> + + <para> + 명료하게, 우리는 대화(<emphasis>어플리케이션 트랜잭션</emphasis>)를 구현하는데 몇몇 데이터베이스 트랜잭션들을 + 사용해야 한다. 이 경우에, 비지니스 프로세스들의 격리를 유지하는 것은 어플리케이션 티어의 부분적인 책임이 된다. + 단일 대화는 대개 여러 개의 데이터베이스 트랜잭션들에 걸친다. 그것은 이들 데이터베이스 트랜잭션들 중 + 오직 한 개(마지막 트랜잭션)가 업데이트된 데이터를 저장하고, 모든 다른 트랜잭션들이 단순히 데이터를 읽는 (예를 들면, + 몇몇 요청/응답 주기에 걸치는 마법사 스타일의 대화 상자에서) 경우에만 원자단위가 될 것이다. 특히 당신이 Hibernate의 + 특징들을 사용할 경우에 , 이것은 들리는 것보다 구현하기가 더 쉽다: + </para> + + <itemizedlist> + <listitem> + <para> + <emphasis>자동적인 버전화</emphasis> - Hibernate는 당신을 위해 자동적인 optimistic + 동시성 제어를 행할 수 있고, 그것은 사용자가 생각하는 시간 동안 동시적인 변경이 발생했는지를 자동적으로 검출할 수 있다. + 대개 우리는 오직 대화의 끝에서 체크한다. + </para> + </listitem> + <listitem> + <para> + <emphasis>Detached 객체들</emphasis> - 만일 당신이 이미 논의된 <emphasis>session-per-request</emphasis> + 패턴을 사용하고자 결정하는 경우, 모든 로드된 인스턴스들은 사용자가 생각하는 시간 동안 detached 상태에 있을 것이다. + Hibernate는 그 객체들을 재첨부시키고 변경들을 영속화 시키는 것을 허용해주며, 그 패턴은 + <emphasis>session-per-request-with-detached-objects(detached-객체들을 가진 요청 당 세션)</emphasis>으로 명명된다. + 자동적인 버전화는 동시성 변경들을 격리시키는데 사용된다. + </para> + </listitem> + <listitem> + <para> + <emphasis>확장된 (또는 Long) Session</emphasis> - Hibernate <emphasis>Session</emphasis>은 데이터베이스 + 트랜잭션이 커밋된 후에 기본 JDBC 커넥션이 연결 해제될 수도 있고, 새로운 클라이언트 요청이 발생할 때 다시 연결될 수 + 있다. 이 패턴은 <emphasis>session-per-conversation(대화 당 세션)</emphasis>으로 + 알려져 있고 재첨부를 불필요하게 만든다. 자동적인 버전화는 동시성 변경들을 격리시키는데 사용되고 <literal>Session</literal>은 + 자동적으로 flush되는 것이 허용되지 않지만 명시적으로 flush되는 것은 허용된다. + </para> + </listitem> + </itemizedlist> + + <para> + <emphasis>session-per-request-with-detached-objects</emphasis>과 + <emphasis>session-per-conversation</emphasis> 양자는 장점들과 단점들을 갖는데, 우리는 이 장의 + 뒷 부분에서 optimistic 동시성 제어 단락에서 그것들을 논의한다. + </para> + + </sect2> + + <sect2 id="transactions-basics-identity"> + <title>객체 identity 고려하기</title> + + <para> + 어플리케이션은 두 개의 다른 <literal>Session</literal>들 내에 있는 동일한 영속 상태에 동시에 접근할 수도 있다. + 하지만 영속 클래스의 인스턴스는 두 개의 <literal>Session</literal> 인스턴스들 사이에 결코 공유되지 않는다. + 그러므로 identity에 대한 두 개의 다른 개념들이 존재한다: + </para> + + <variablelist spacing="compact"> + <varlistentry> + <term>데이터베이스 Identity</term> + <listitem> + <para> + <literal>foo.getId().equals( bar.getId() )</literal> + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>JVM Identity</term> + <listitem> + <para> + <literal>foo==bar</literal> + </para> + </listitem> + </varlistentry> + </variablelist> + + <para> + 그때 (예를 들어 <literal>Session</literal> 영역에서) <emphasis>특정</emphasis> <literal>Session</literal>에 + 첨부된 객체들의 경우 두 개의 개념들은 동등한 것이고, 데이터베이스 identity에 대한 JVM identity가 Hibernate에 의해 보장된다. + 하지만, 어플리케이션이 두 개의 다른 세션들에서 "동일한" (영속 identity) 비지니스 객체에 동시에 접근하는 동안, 두 개의 인스턴스들은 + 실제로 "다르다"(JVM identity). 충돌들은 flush/커밋 시에 (자동적인 버전화)를 사용하여, optimistic 접근법을 사용하여 해결된다. + </para> + + <para> + 이 접근법은 Hibernate와 데이터베이스가 동시성에 대해 걱정하지 않도록 해준다; 그것은 또한 최상의 scalability를 제공한다. + 왜냐하면 단일 쓰레드-작업 단위 내에서 identity 보장은 단지 비용이 드는 잠금이나 다른 동기화 수단들을 필요로 하지 않기 때문이다. + 어플리케이션은 그것이 <literal>Session</literal> 당 단일 쓰레드를 강제하는 한, 어떤 비지니스 객체에 대해 결코 동기화 시킬 + 필요가 없다. 하나의 <literal>Session</literal> 내에서 어플리케이션은 객체들을 비교하는데 <literal>==</literal>를 + 안전하게 사용할 수가 있다. + </para> + + <para> + 하지만, 하나의 <literal>Session</literal> 외부에서 <literal>==</literal>를 사용하는 어플리케이션은 예기치 않은 + 결과들을 보게 될 수도 있다. 이것은 어떤 예기치 않은 장소들에서, 예를 들어 당신이 두 개의 detached 인스턴스들을 동일한 + <literal>Set</literal> 내에 집어넣을 경우에 발생할 수도 있다. 둘 다 동일한 데이터베이스 identity를 가질 수 있지만 + (예를 들어 그것들은 동일한 행을 표현한다), JVM identity는 정의 상 detached 상태에 있는 인스턴스들을 보장하지 않는다. + 개발자는 영속 클래스들내에 <literal>equals()</literal> 메소드와 <literal>hashCode()</literal> 메소드를 오버라이드 시켜야 하고 + 객체 equality에 대한 그 자신의 개념을 구현해야 한다. 하나의 경고가 존재한다: equality를 구현하는데 데이터베이스 identifier를 결코 + 사용하지 말고, 하나의 비지니스 키, 유일한, 대개 불변인 속성들의 조합을 사용하라. 데이터베이스 식별자는 만일 transient 객체가 영속화되는 + 경우에 변경될 것이다. 만일 transient 인스턴스가(대개 detached 인스턴스들과 함께) <literal>Set</literal> 내에 보관되는 경우에, + hashcode 변경은 <literal>Set</literal>의 계약을 파기시킨다. 비지니스 키들에 대한 속성들은 데이터베이스 프라이머리 키들 만큼 + 안정적이어서는 안되며, 당신은 오직 객체들이 동일한 <literal>Set</literal> 내에 있는 한에서 안정성을 보장해야만 한다. + 이 쟁점에 관한 논의에 대한 더 많은 것을 Hibernate 웹 사이트를 보라. 또한 이것이 Hibernate 쟁점이 아니며, 단지 자바 객체 + identity와 equality가 구현되어야 하는 방법임을 노트하라. + </para> + + </sect2> + + <sect2 id="transactions-basics-issues"> + <title>공통된 쟁점들</title> + + <para> + 안티-패턴들 <emphasis>session-per-user-session</emphasis> 또는 + <emphasis>session-per-application</emphasis>을 결코 사용하지 말라(물론 이 규칙에 대한 드문 예외상황들이 존재한다). + 다음 쟁점들 중 몇몇이 또한 권장되는 패턴들로 나타날 수 있음을 노트하고, 당신이 설계 결정을 내리기 전에 내포된 의미들을 + 확실히 이해하라: + </para> + + <itemizedlist> + <listitem> + <para> + <literal>Session</literal>은 쓰레드-안전하지 않다. HTTP 요청들, 세션 빈즈, 또는 Swing worker들처럼 + 동시에 작업하는 것으로 가정되는 것들은 하나의 <literal>Session</literal> 인스턴스가 공유될 경우에 경쟁 조건들을 + 발생시킬 것이다. 만일 당신이 당신의 <literal>HttpSession</literal> 내에 Hibernate + <literal>Session</literal>을 유지시키는 경우(나중에 논의됨), 당신은 당신의 Http 세션에 대한 접근을 동기화 + 시키는 것을 고려해야 한다. 그 밖의 경우, 충분히 빠르게 reload를 클릭하는 사용자는 두 개의 동시적으로 실행되는 + 쓰레드들 내에서 동일한 <literal>Session</literal>을 사용할 수도 있다. + </para> + </listitem> + <listitem> + <para> + Hibernate에 의해 던져진 예외상황은 당신이 당신의 데이터베이스 트랜잭션을 롤백 시키고 즉시 <literal>Session</literal>을 + 닫아야 함을 의미한다(나중에 상세히 논의됨). 만일 당신의 <literal>Session</literal>이 어플리케이션에 바인드 되어 있는 경우, + 당신은 어플리케이션을 중지시켜야 한다. 데이터베이스 트랜잭션 롤백은 당신의 비지니스 객체들을 그것들이 트랜잭션의 시작 시에 + 머물렀던 상태로 되돌리지는 않는다. 이것은 데이터베이스 상태와 비지니스 객체들이 동기화를 벗어남을 의미한다. 대개 이것은 문제가 아니다. + 왜냐하면 예외상황들은 회복가능한 것이 아니고 당신이 어떻게든 롤백 후에 시작해야 하기 때문이다. + </para> + </listitem> + <listitem> + <para> + <literal>Session</literal>은 (Hibernate에 의해 dirty 상태로 관찰되었거나 체크된) 영속 상태에 있는 + 모든 객체를 캐시 시킨다. 이것은 당신이 오랜 시간 동안 <literal>Session</literal>을 열어둔 채로 유지하거나 + 단순하게 너무 많은 데이터를 로드시킬 경우에, 당신이 OutOfMemoryException을 얻기 전까지, 그것이 끝없이 + 성장한다는 점을 의미한다. 이것에 대한 하나의 해결책은 <literal>Session</literal> 캐시를 관리하기 위해 + <literal>clear()</literal>와 <literal>evict()</literal>를 호출하는 것이지만, 당신이 대용량 데이터 + 오퍼레이션들을 필요로 하는 경우에 당신은 대개 내장 프로시저를 고려해야 할 것이다. 몇몇 해결책들이 + <xref linkend="batch"/>에 보여져 있다. 사용자 세션 동안에 <literal>Session</literal>을 열려진 채로 + 유지하는 것은 또한 실효성이 떨어진 데이터에 대한 높은 확률을 의미한다. + </para> + </listitem> + </itemizedlist> + + </sect2> + + </sect1> + + <sect1 id="transactions-demarcation"> + <title>데이터베이스 트랜잭션 경계 설정</title> + + <para> + 데이터베이스 (또는 시스템) 트랜잭션 경계들은 항상 필수적이다. 데이터베이스와의 통신은 데이터베이스 트랜잭션의 외부에서 발생할 수 + 없다(이것은 자동-커밋 모드로 사용되는 많은 개발자들에게는 혼동스러워 보인다). 항상 심지어 읽기 전용 오퍼레이션들에 대해서도 명료한 + 트랜잭션 경계들을 사용하라. 당신의 격리 레벨과 데이터베이스 가용성들에 따라, 이것은 필요하지 않을 수 있지만, 만일 당신이 항상 + 트랜잭션들을 명시적으로 경계 설정할 경우에는 하강하는 결점들이 존재하지 않는다. 확실히, 하나의 데이터베이스 트랜잭션은 심지어 + 데이터 읽기조차도 많은 작은 트랜잭션들의 경우보다는 더 좋게 수행될 것이다. + </para> + + <para> + Hibernate 어플리케이션은 관리되지 않는 환경(예를 들면. 스탠드얼론, 간단히 웹 어플리케이션들 또는 Swing 어플리케이션들)과 + 관리되는 J2EE 환경에서 실행될 수 있다. 관리되지 않는 환경에서, Hibernate는 대개 그것 자신의 데이터베이스 커넥션 풀에 대한 + 책임이 있다. 어플리케이션 개발자는 트랜잭션 경계들을 손수 설정해야 한다. 달리 말해, 개발자 스스로 데이터베이스 트랜잭션들을 + 시작하고, 커밋시키거나 롤백시켜야 한다. 관리되는 환경은 대개 예를 들어 EJB 세션 빈즈의 배치 디스크립터 속에 선언적으로 정의된 + 트랜잭션 어셈블리를 가진, 컨테이너에 의해-관리되는 트랜잭션들(CMT)을 제공한다. 그때 프로그램 상의 트랜잭션 경계 설정은 더 이상 필요하지 + 않다. + </para> + + <para> + 하지만, CMT 대신 BMT를 사용하는 JTA에 의존할 수 있는 시스템들, 그리고 관리되지 않는 resource-local 환경들 사이에서 + 당신의 영속 계층에 이식성을 유지시키는 것이 자주 희망된다. 두 경우들에서 당신은 프로그램 상의 트랜잭션 경계설정을 사용할 것이다. + Hibernate는 당신의 배치 환경의 고유한 트랜잭션 시스템 속으로 변환되는 <literal>Transaction</literal>이라 명명되는 + wrapper API 를 제공한다. 이 API는 실제로 옵션이지만 우리는 당신이 CMT session bean 속에 있지 않는 한 그것의 사용을 + 강력하게 권장한다. + </para> + + <para> + 대개 <literal>Session</literal> 종료는 네 개의 구분되는 단계들을 수반한다: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + 세션을 flush 시킨다 + </para> + </listitem> + <listitem> + <para> + 트랜잭션을 커밋 시킨다 + </para> + </listitem> + <listitem> + <para> + 세션을 닫는다 + </para> + </listitem> + <listitem> + <para> + 예외상황들을 처리한다 + </para> + </listitem> + </itemizedlist> + + <para> + 세션을 flush 시키는 것은 앞서 논의되었고, 우리는 이제 관리되는 환경과 관리되지 않는 환경 양자에서 트랜잭션 경계 설정과 예외상황을 + 더 자세히 살펴볼 것이다. + </para> + + + <sect2 id="transactions-demarcation-nonmanaged" revision="2"> + <title>관리되지 않는 환경</title> + + <para> + 만일 Hibernate 영속 계층이 관리되지 않는(non-managed) 환경에서 실행될 경우, 데이터베이스 커넥션들은 대개 Hibernate가 + 필요로할 때 커넥션들을 획득하는 간단한 (예를 들면 DataSource가 아닌) 커넥션 풀(pool)들로부터 처리된다. + session/transaction 처리 관용구는 다음과 같다: + </para> + + <programlisting><![CDATA[// Non-managed environment idiom +Session sess = factory.openSession(); +Transaction tx = null; +try { + tx = sess.beginTransaction(); + + // do some work + ... + + tx.commit(); +} +catch (RuntimeException e) { + if (tx != null) tx.rollback(); + throw e; // or display error message +} +finally { + sess.close(); +}]]></programlisting> + + <para> + 당신은 <literal>Session</literal>을 명시적으로 <literal>flush()</literal> 하지 말아야 한다 - + <literal>commit()</literal>에 대한 호출은 (그 세션에 대한 + <xref linkend="objectstate-flushing">FlushMode</xref>에 따라)자동적으로 동기화를 트리거시킨다. + <literal>close()</literal>에 대한 호출은 세션의 끝을 마크한다. <literal>close()</literal>의 + 주된 구현은 JDBC 커넥션이 그 세션에 의해 포기될 것이라는 점이다. 이 Java 코드는 관리되지 않는 환경과 + JTA 환경 양자에서 이식성이 있고 실행된다. + </para> + + <para> + 보다 더 유연한 해결책은 앞서 설명했듯이 Hibernate의 미리 빌드되어 있는 "현재 세션" 컨텍스트 관리이다: + </para> + + <programlisting><![CDATA[// Non-managed environment idiom with getCurrentSession() +try { + factory.getCurrentSession().beginTransaction(); + + // do some work + ... + + factory.getCurrentSession().getTransaction().commit(); +} +catch (RuntimeException e) { + factory.getCurrentSession().getTransaction().rollback(); + throw e; // or display error message +}]]></programlisting> + + <para> + 당신은 통상의 어플리케이션에서 비지니스 코드 속에 이 관용구를 결코 보지 않을 것이다; 치명적인(시스템) 예외상황들은 항상 + "상단"에서 잡혀야 한다. 달리 말해, (영속 계층에서) Hibernate 호출들을 실행시키는 코드와 <literal>RuntimeException</literal>을 + 처리하(고 대개 오직 제거하고 빠져나갈 수 있는) 코드는 다른 계층들 속에 있다. Hibernate에 의한 현재 컨텍스트 관리는 이 설계를 + 현격하게 단순화시켜서, 당신이 필요로 하는 모든 것은 <literal>SessionFactory</literal>에 대한 접근이다.예외상황 + 처리는 이 장의 뒷부분에서 논의된다. + </para> + + <para> + 당신은 (디폴트인) <literal>org.hibernate.transaction.JDBCTransactionFactory</literal>를 선택해야 하고, + 두번째 예제의 경우 당신의 <literal>hibernate.current_session_context_class</literal>를 선택해야 함을 노트하라. + </para> + + </sect2> + + <sect2 id="transactions-demarcation-jta" revision="3"> + <title>JTA 사용하기</title> + + <para> + 만일 당신의 영속 계층이 어플리케이션 서버에서(예를 들어, EJB 세션 빈즈 이면에서) 실행될 경우, Hibernate에 의해 + 획득된 모든 데이터소스 커넥션은 자동적으로 전역 JTA 트랜잭션의 부분일 것이다. 당신은 또한 스탠드얼론 JTA 구현을 + 설치할 수 있고 EJB 없이 그것을 사용할 수 있다. Hibernate는 JTA 통합을 위한 두 개의 방도들을 제공한다. + </para> + + <para> + 만일 당신이 bean-managed transactions(BMT)를 사용할 경우 Hibernate는 당신이 <literal>Transaction</literal> + API를 사용할 경우에 BMT 트랜잭션을 시작하고 종료하도록 어플리케이션 서버에게 알려줄 것이다. 따라서 트랜잭션 관리 코드는 + non-managed 환경과 동일하다. + </para> + + <programlisting><![CDATA[// BMT idiom +Session sess = factory.openSession(); +Transaction tx = null; +try { + tx = sess.beginTransaction(); + + // do some work + ... + + tx.commit(); +} +catch (RuntimeException e) { + if (tx != null) tx.rollback(); + throw e; // or display error message +} +finally { + sess.close(); +}]]></programlisting> + + <para> + 만일 당신이 트랜잭션에 묶인 <literal>Session</literal>, 즉 쉬운 컨텍스트 보급을 위한 + <literal>getCurrentSession()</literal> 기능을 사용하고자 원할 경우, 당신은 + JTA <literal>UserTransaction</literal> API를 직접 사용해야 할 것이다: + </para> + + <programlisting><![CDATA[// BMT idiom with getCurrentSession() +try { + UserTransaction tx = (UserTransaction)new InitialContext() + .lookup("java:comp/UserTransaction"); + + tx.begin(); + + // Do some work on Session bound to transaction + factory.getCurrentSession().load(...); + factory.getCurrentSession().persist(...); + + tx.commit(); +} +catch (RuntimeException e) { + tx.rollback(); + throw e; // or display error message +}]]></programlisting> + + <para> + CMT의 경우, 트랜잭션 관할[경계 설정]은 프로그램 상이 아닌, session bean 배치 디스크립터들 속에서 행해진다. + 그러므로 코드는 다음으로 감소된다: + </para> + + <programlisting><![CDATA[// CMT idiom + Session sess = factory.getCurrentSession(); + + // do some work + ... +]]></programlisting> + + <para> + 왜냐하면 하나의 세션 빈 메소드에 의해 던져진 처리되지 않은 <literal>RuntimeException</literal>이 + 글로벌 트랜잭션을 rollback으로 설정하도록 컨테이너에게 알려주기 때문에, CMT/EJB에서조차 롤백은 자동적으로 발생된다. + <emphasis>이것은 당신이 BMT 이든 CMT이든 모두에서 Hibernate <literal>Transaction</literal> API를 사용할 필요가 + 없으며, 당신은 그 트랜잭션에 묶인 "현재" Session의 자동적인 보급(propagation)을 얻게 됨을 의미한다.</emphasis> + </para> + + <para> + 당신이 Hibernate의 트랜잭션 팩토리를 구성할 때, 당신이 JTA를 직접 사용할 경우(BMT) 당신은 + <literal>org.hibernate.transaction.JTATransactionFactory</literal>를 선택해야하고, CMT session bean에서는 + <literal>org.hibernate.transaction.CMTTransactionFactory</literal>를 선택해야 함을 노트하라. 또한 + <literal>org.hibernate.transaction.manager_lookup_class</literal>를 설정하는 것을 염두에 두라. 게다가 + 반드시 당신의 <literal>hibernate.current_session_context_class</literal>이 설정되지 않도록 하거나(역호환성), + 또는 <literal>"jta"</literal>로 설정되도록 하라. + </para> + + <para> + <literal>getCurrentSession()</literal> 오퍼레이션들은 JTA 환경에서 한 가지 단점을 갖고 있다. + 디폴트로 사용되는, <literal>after_statement</literal> 커넥션 해제 모드 사용에 대한 하나의 보류 통보가 존재한다. + JTA 명세서의 어리석은 제한으로 인해, Hibernate가 <literal>scroll()</literal> 또는 <literal>iterate()</literal>에 + 의해 반환되는 임의의 닫혀지지 않은 <literal>ScrollableResults</literal> 또는 <literal>Iterator</literal> + 인스턴스들을 자동적으로 제거하는 것이 불가능하다. 당신은 <literal>finally</literal> 블록 내에서 명시적으로 + <literal>ScrollableResults.close()</literal> 또는 <literal>Hibernate.close(Iterator)</literal>를 + 호출하여 기본 데이터베이스 커서를 해제<emphasis>시켜야 한다</emphasis>.(물론 대부분의 어플리케이션들은 JTA 또는 CMT 코드에서 + <literal>scroll()</literal>이나 <literal>iterate()</literal>를 사용하는 것을 쉽게 피할 수 있다.) + </para> + + </sect2> + + <sect2 id="transactions-demarcation-exceptions"> + <title>예외상황 처리</title> + + <para> + 만일<literal>Session</literal>이 (어떤 <literal>SQLException</literal>을 포함하는) 예외상황을 던질 경우, + 당신은 데이터베이스 트랜잭션을 즉시 롤백시키고, <literal>Session.close()</literal>를 호출하고 + <literal>Session</literal> 인스턴스를 폐기시켜야한다. <literal>Session</literal>의 어떤 메소드들은 + 그 세션을 일관된 상태로 남겨두지 <emphasis>않을</emphasis> 것이다. Hibernate에 의해 던져진 예외상황은 복구가능한 + 것으로 취급될 수 없다. 그 <literal>Session</literal>이 <literal>finally</literal> 블록 내에서 + <literal>close()</literal>를 호출하여 닫혀지도록 확실히 하라. + </para> + + <para> + Hibernate 영속 계층에서 발생할 수 있는 대부분의 오류들을 포장하는, <literal>HibernateException</literal>은 + 체크되지 않은 예외상황이다(그것은 Hibernate의 이전 버전에는 없었다). 우리의 의견으로, 우리는 낮은 계층에서 복구불가능한 + 예외상황을 붙잡도록 어플리케이션 개발자에게 강제하지 않을 것이다. 대부분의 시스템들에서, 체크되지 않은 치명적인 예외상황들은 + (예를 들어, 더 높은 계층에서) 메소드 호출 스택의 첫 번째 프레임들 중 하나 속에서 처리되고, 한 개의 오류 메시지가 어플리케이션 + 사용자에게 표시된다(또는 어떤 다른 적절한 액션이 취해진다). Hibernate는 또한 <literal>HibernateException</literal>이 + 아닌, 다른 체크되지 않은 예외상황들을 던질 수도 있음을 노트하라. 다시 이것들은 복구가능하지 않고 적절한 액션이 취해져야 한다. + </para> + + <para> + Hibernate는 데이터베이스와 상호작용하는 동안에 던져진 <literal>SQLException</literal>들을 하나의 + <literal>JDBCException</literal> 속에 포장한다. 사실, Hibernate는 그 예외상황을 + <literal>JDBCException</literal>의 보다 의미있는 서브클래스로 변환하려고 시도할 것이다. 기본 + <literal>SQLException</literal>은 <literal>JDBCException.getCause()</literal>를 통해 항상 이용 가능하다. + Hibernate는<literal>SessionFactory</literal>에 첨부된 <literal>SQLExceptionConverter</literal>를 + 사용하여 <literal>SQLException</literal>을 적당한 하나의 <literal>JDBCException</literal> 서브클래스로 + 변환시킨다. 디폴트로 <literal>SQLExceptionConverter</literal>는 구성된 dialect에 의해 정의된다; 하지만 + 맞춤 구현 속에 플러그인 시키는 것이 또한 가능하다(상세한 것은 <literal>SQLExceptionConverterFactory</literal> + 클래스에 관한 javadocs를 보라). 표준 <literal>JDBCException</literal> 서브타입은 다음과 같다: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + <literal>JDBCConnectionException</literal> - 기본 JDBC 통신에 대한 오류를 나타낸다. + </para> + </listitem> + <listitem> + <para> + <literal>SQLGrammarException</literal> - 생겨난 SQL에 대한 문법 또는 구문 문제점을 나타낸다. + </para> + </listitem> + <listitem> + <para> + <literal>ConstraintViolationException</literal> - 무결성 제약 위반에 관한 어떤 형식을 나타낸다. + </para> + </listitem> + <listitem> + <para> + <literal>LockAcquisitionException</literal> - 요청된 오퍼레이션을 실행하는데 필수적인 잠금 레벨을 + 획득하는 오류를 나타낸다. + </para> + </listitem> + <listitem> + <para> + <literal>GenericJDBCException</literal> - 다른 카테고리들 중 어떤 것으로 분류되지 않았던 일반적인 예외상황. + </para> + </listitem> + </itemizedlist> + + </sect2> + + <sect2 id="transactions-demarcation-timeout"> + <title>트랜잭션 타임아웃</title> + + <para> + 관리되지 않는 코드에 대해서는 결코 제공되지 않는 EJB와 같이 관리되는 환경에 의해 제공되는 한 가지 극히 + 중요한 특징은 트랜잭션 타임아웃이다. 트랜잭션 타임아웃은 사용자에게 응답을 반환하지 않는 동안에 + 무례한 행동을 행하는 트랜잭션이 자원들을 무한정 묶어둘 수 없음을 보증해준다. 관리되는 (JTA) 환경 + 외부에서, Hibernate는 이 기능을 온전하게 제공할 수 없다. 하지만 Hibernate는 데이터베이스 + 레벨 데드락들과 거대한 결과 셋들을 가진 질의들이 정의된 타임아웃에 의해 제약되는 것을 보장함으로써 + 최소한 데이터 접근 오퍼레이션들을 제어할 수 있다. 관리되는 환경에서, Hibernate는 트랜잭션 타임아웃을 + JTA에게 위임시킬 수 있다. 이 기능은 Hibernate <literal>Transaction</literal> 객체에 의해 + 추상화 된다. + </para> + + <programlisting><![CDATA[ +Session sess = factory.openSession(); +try { + //set transaction timeout to 3 seconds + sess.getTransaction().setTimeout(3); + sess.getTransaction().begin(); + + // do some work + ... + + sess.getTransaction().commit() +} +catch (RuntimeException e) { + sess.getTransaction().rollback(); + throw e; // or display error message +} +finally { + sess.close(); +}]]></programlisting> + + <para> + <literal>setTimeout()</literal>은 CMT bean 내에서 호출도리 수 없음을 노트하라. + 여기서 트랜잭션 타임아웃들은 선언적으로 정의되어야 한다. + </para> + + </sect2> + + </sect1> + + <sect1 id="transactions-optimistic"> + <title>Optimistic 동시성 제어</title> + + <para> + 고도의 동시성과 고도의 가용성을 일치시키는 유일한 접근법은 버전화를 가진 optimistic동시성 제어이다. 버전 체킹은 업데이트 충돌을 + 검출하기 위해(그리고 업데이트 손실을 방지하기 위해) 버전 번호들 또는 timestamp들을 사용한다. Hibernate는 optimistic 동시성을 + 사용하는 어플리케이션 코드 작성에 세 가지 가능한 접근법들을 제공한다. 우리가 보여주는 쓰임새들은 장시간의 대화의 상황 + 속에 있지만, 버전 체킹 또한 단일 데이터베이스 트랜잭션들에서 업데이트 손실을 방지하는 이점을 갖고 있다. + </para> + + <sect2 id="transactions-optimistic-manual"> + <title>어플리케이션 버전 체킹</title> + + <para> + 하나의 구현에서 Hibernate로부터 많은 도움이 없이, 데이터베이스에 대한 각각의 상호작용은 새로운 <literal>Session</literal> + 내에서 일어나고, 개발자는 영속 인스턴스들을 처리하기 전에 데이터베이스로부터 모든 영속 인스턴스들을 다시 로드시킬 책임이 있다. + 이 접근법은 대화 트랜잭션을 확실히 격리시키기 위해 그것 자신의 버전 체킹을 수행하도록 어플리케이션에게 강제시킨다. + </para> + + <programlisting><![CDATA[// foo is an instance loaded by a previous Session +session = factory.openSession(); +Transaction t = session.beginTransaction(); + +int oldVersion = foo.getVersion(); +session.load( foo, foo.getKey() ); // load the current state +if ( oldVersion != foo.getVersion() ) throw new StaleObjectStateException(); +foo.setProperty("bar"); + +t.commit(); +session.close();]]></programlisting> + + <para> + version 프로퍼티는 <literal>&lt;version&gt;</literal>을 사용하여 매핑되고, Hibernate는 만일 엔티티가 dirty일 경우 + flush 동안에 그것을 자동적으로 증가시킬 것이다. + </para> + + <para> + 물론, 당신이 낮은 데이터 동시성 환경에서 작업하고 있고 버전 체킹을 필요로 하지 않을 경우에, 당신은 이 접근법을 사용할 수 도 있고 + 단지 버전 체크를 생략할 수도 있다. 그 경우에, <emphasis>마지막의 커밋 성공</emphasis>은 당신의 장시간의 대화에 + 대한 디폴트 방도가 될 것이다. 이것이 어플리케이션의 사용자들을 혼동시킬 수 있음을 염두에 두라. 왜냐하면 사용자들은 오류 메시지들 + 또는 충돌 변경들을 병합시킬 기회 없이 업데이트들 손실을 겪을 수도 있기 때문이다. + </para> + + <para> + 명료하게 수작업 버전 체킹은 매우 사소한 환경들에서도 공포적이고 대부분의 어플리케이션들에 대해 실제적이지 않다. 흔히 단일 + 인스턴스 뿐만 아니라 변경된 객체들의 전체 그래프들이 체크되어야 한다. Hibernate는 설계 패러다임으로서 하나의 확장된 <literal>Session</literal> + 또는 detached 인스턴스들에 대해 자동적인 버전 체킹을 제공한다. + </para> + + </sect2> + + <sect2 id="transactions-optimistic-longsession"> + <title>확장된 세션과 자동적인 버전화</title> + + <para> + 하나의 <literal>Session</literal> 인스턴스와 그것의 영속 인스턴스들은 전체 어플리케이션 트랜잭션에 사용된다. Hibernate는 + flush 할 때 인스턴스 버전들을 체크하고 만일 동시성 변경이 검출될 경우에 예외상황을 던진다. 이 예외상황을 잡아내고 처리하는 것을 + 개발자의 몫이다(공통된 옵션들은 변경들을 병합시키거나 또는 쓸모가 없지 않은 데이터로 비지니스 프로세스를 다시 시작하는 기회를 + 사용자에게 주는 것이다). + 하나의 <literal>Session</literal> 인스턴스와 그것의 영속 인스턴스들은 <emphasis>session-per-conversation</emphasis>로 + 알려진 전체 대화에 사용된다. Hibernate는 flush 시점에서 인스턴스 버전들을 체크하며, 만일 동시적인 변경이 검출될 경우에 + 하나의 예외상황을 던진다. 이 예외상황을 포착하고 처리하는 것은 개발자의 몫이다(공통된 옵션들은 사용자가 변경들을 병합하거나 + 손실되지 않은 데이터를 가지고 비지니스 대화를 재시작하는 기회이다). + </para> + + <para> + <literal>Session</literal>은 사용자 상호작용을 기다릴 때 어떤 기본 JDBC 커넥션으로부터 연결해제된다. 이 접근법은 + 데이터베이스 접근의 관점에서 보면 가장 효율적이다. 어플리케이션은 버전 체킹 또는 detached 인스턴스들을 재첨부하는 것에 + 그 자체 관계할 필요가 없거나 그것은 모든 데이터베이스 트랜잭션에서 인스턴스들을 다시 로드시킬 필요가 없다. + </para> + + <programlisting><![CDATA[// foo is an instance loaded earlier by the old session +Transaction t = session.beginTransaction(); // Obtain a new JDBC connection, start transaction + +foo.setProperty("bar"); + +session.flush(); // Only for last transaction in conversation +t.commit(); // Also return JDBC connection +session.close(); // Only for last transaction in conversation]]></programlisting> + <para> + <literal>foo</literal> 객체는 그것이 로드되었던 <literal>Session</literal>이 어느 것인지를 여전히 알고 있다. + 이전 세션 상에서 하나의 새로운 데이터베이스 트랜잭션을 시작하는 것은 하나의 새로운 커넥션을 획득하고 그 세션을 소비한다. + 데이터베이스 트랜잭션을 커밋(확약)시키는 것은 그 JDBC 커넥션으로부터 하나의 세션을 연결해제시키고 그 커넥션을 풀(pool)로 + 반환시킬 것이다. 재연결 후에, 당신이 업데이트하고 있지 않은 데이터에 대한 버전 체크를 강제시키기 위해서, 당신은 + 또 다른 트랜잭션에 의해 업데이트되었을 수도 있는 임의의 객체들에 대해 <literal>LockMode.READ</literal>로서 + <literal>Session.lock()</literal>을 호출할 수도 있다. 당신은 당신이 업데이트 중인 임의의 데이터를 잠금할 필요가 없다. + 대개 당신은 마지막 데이터베이스 트랜잭션 주기만이 이 대화 내에서 행해진 모든 변경들을 실제로 영속화시키는 것이 허용되도록 하기 위해, + 하나의 확장된 <literal>Session</literal>에 대해 <literal>FlushMode.MANUAL</literal>를 설정할 것이다. + 그러므로 오직 이 마지막 데이터베이스 트랜잭션 만이 <literal>flush()</literal> 오퍼레이션을 포함할 것이고, 또한 + 대화를 종료시키기 위해 세션을 <literal>close()</literal>할 것이다. + </para> + + <para> + 만일 사용자가 생각하는시간 동안 <literal>Session</literal>이 저장되기에 너무 큰 경우 이 패턴은 문제성이 있다. 예를 들어 + <literal>HttpSession</literal>은 가능한 작은 것으로 유지되어야 한다. 또한 <literal>Session</literal>은 (필수의) + 첫 번째 레벨 캐시이고 모든 로드된 객체들을 포함하기 때문에, 우리는 아마 적은 요청/응답 주기들에 대해서만 이 방도를 사용할 수 있다. + 당신은 하나의 대화에 대해서만 하나의 <literal>Session</literal>을 사용해야 한다. 왜냐하면 그것은 또한 곧 실없는 데이터가 + 될 것이기 때문이다. + </para> + + <para> + (초기의 Hibernate 버전들은 <literal>Session</literal>에 대한 명시적인 연결해제와 재연결을 필요로 했음을 + 노트하라. 트랜잭션을 시작하고 끝내는 것이 동일한 효과를 가지므로, 이들 방법들은 진부하게 되었다.) + </para> + + <para> + 또한 당신은 영속 계층에 대해 연결해제된 <literal>Session</literal>을 닫혀진채로 유지해야함을 노트하라. 달 + 리말해, 하나의 3-tier 환경에서 <literal>Session</literal>을 소유하는데 EJB stateful session bean을 + 사용하고, <literal>HttpSession</literal> 내에 그것을 저장하기 위해 그것을 웹 계층에 전송하지 말라 + (또는 그것을 별도의 티어에 직렬화 시키지도 말라). + </para> + + <para> + 확장된 세션 패턴, 또는 <emphasis>session-per-conversation</emphasis>은 자동적인 현재 세션 컨텍스트 관리에 대해 + 구현하기가 더 어렵다. 당신은 이를 위해 당신 자신의 <literal>CurrentSessionContext</literal> 구현을 공급할 필요가 + 있으며, 예제들은 Hibernate Wiki를 보라. + </para> + + </sect2> + + <sect2 id="transactions-optimistic-detached"> + <title>Detached 객체들과 자동적인 버전화</title> + + <para> + 영속 저장소에 대한 각각의 상호작용은 새로운 <literal>Session</literal>에서 일어난다. 하지만 동일한 영속 인스턴스들은 + 데이터베이스와의 각각의 상호작용에 재사용된다. 어플리케이션은 원래 로드되었던 detached 인스턴스들의 상태를 또 다른 + <literal>Session</literal> 내에서 처리하고 나서 <literal>Session.update()</literal>, + <literal>Session.saveOrUpdate()</literal>, <literal>Session.merge()</literal>를 사용하여 그것들을 + 다시 첨부시킨다. + </para> + + <programlisting><![CDATA[// foo is an instance loaded by a previous Session +foo.setProperty("bar"); +session = factory.openSession(); +Transaction t = session.beginTransaction(); +session.saveOrUpdate(foo); // Use merge() if "foo" might have been loaded already +t.commit(); +session.close();]]></programlisting> + + <para> + 다시, Hibernate는 flush 동안에 인스턴스 버전들을 체크할 것이고 업데이트 충돌이 발생할 경우에 예외상황을 던질 것이다. + </para> + + <para> + 당신은 또한 <literal>update()</literal>대신에 <literal>lock()</literal>을 호출할 수도 있고 만일 그 객체가 + 변경되지 않았음을 당신이 확신하는 경우에 (버전 체킹을 수행하고 모든 캐시들을 무시하는) <literal>LockMode.READ</literal>를 + 사용할 수 있다. + </para> + + </sect2> + + <sect2 id="transactions-optimistic-customizing"> + <title>자동적인 버전화를 맞춤화 시키기</title> + + <para> + 당신은 <literal>optimistic-lock</literal> 매핑 속성을 <literal>false</literal>로 설정함으로써 특정 프로퍼티들과 + 콜렉션들에 대한 Hibernate의 자동적인 버전 증가를 불가능하도록 할 수도 있다. 그때 Hibernate는 그 프로퍼티가 dirty 일 경우에 + 더 이상 버전을 증가시키지 않을 것이다. + </para> + + <para> + 리거시 데이터베이스 스키마들은 자주 static이고 변경될 수 없다. 또는 다른 어플리케이션들은 또한 동일한 데이터베이스에 접근하고 + 버전 번호들 또는 심지어 timestamp들을 처리하는 방법을 모를 수도 있다. 두 경우들에서, 버전화는 테이블 내의 특정 컬럼에 의지할 수 + 없다. version 또는 timestamp 프로퍼티 매핑 없이 행 내의 모든 필드들에 대한 상태를 비교하여 버전 체크를 강제시키기 위해서, + <literal>&lt;class&gt;</literal> 매핑 속에 <literal>optimistic-lock="all"</literal>을 표시하라. 만일 + Hibernate가 이전 상태와 새로운 상태를 비교할 수 있을 경우에, 예를 들면 당신이 하나의 긴 <literal>Session</literal>을 + 사용하고 session-per-request-with-detached-objects을 사용하지 않을 경우 이것은 개념적으로만 동작함을 노트하라. + </para> + + <para> + 때때로 행해졌던 변경들이 중첩되지 않는 한 동시적인 변경이 허용될 수 있다. 만일 <literal>&lt;class&gt;</literal>를 + 매핑할 때 당신이 <literal>optimistic-lock="dirty"</literal>를 설정하면, Hibernate는 flush 동안에 dirty 필드들을 + 비교만 할 것이다. + </para> + + <para> + 두 경우들에서, 전용 version/timestamp 컬럼의 경우 또는 full/dirty 필드 비교의 경우, Hibernate는 법전 체크를 실행하고 + 정보를 업데이트하는데 엔티티 당 (적절한 <literal>WHERE</literal> 절을 가진) 한 개의<literal>UPDATE</literal> + 문장을 사용한다. 만일 당신이 연관된 엔티티들에 대한 재첨부를 케스케이드 하는데 transitive 영속을 사용할 경우, + Hibernate는 불필요하게 업데이트들을 실행할 수도 있다. 이것은 대개 문제가 아니지만, 심지어 변경들이 detached 인스턴스들에 + 대해 행해지지 않았을 때에도 데이터베이스 내에서 <emphasis>on update</emphasis> 트리거들이 실행될 수도 있다. 그 행을 + 업데이트하기 전에 변경들이 실제로 일어났음을 확인하기 위해 인스턴스를 <literal>SELECT</literal>하는 것을 Hibernate에게 + 강제시키는, <literal>&lt;class&gt;</literal> 매핑 속에 <literal>select-before-update="true"</literal>를 + 설정함으로써 당신은 이 특징을 맞춤화 시킬 수 있다. + </para> + + </sect2> + + </sect1> + + <sect1 id="transactions-locking"> + <title>Pessimistic 잠금</title> + + <para> + 사용자들은 잠금 방도에 대해 걱정하는데 많은 시간을 할애하하려고 생각하지 않는다. 대개 JDBC 커넥션들에 대한 격리 레벨을 지정하는 + 것으로 충분하고 그런 다음 단순히 데이터베이스로 하여금 모든 작업을 행하도록 한다. 하지만 진일보한 사용자들은 때때로 배타적인 + pessimistic 잠금들을 얻거나 또는 새로운 트랜잭션의 시작 시에 잠금들을 다시 얻고자 원할 수도 있다. + </para> + + <para> + Hibernate는 결코 메모리 내에 있는 객체들이 아닌, 데이터베이스의 잠금 메커니즘을 항상 사용할 것이다! + </para> + + <para> + <literal>LockMode</literal> 클래스는 Hibernate에 의해 획득될 수 있는 다른 잠금 레벨들을 정의한다. 잠금은 다음 메커니즘들에 + 의해 얻어진다: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + <literal>LockMode.WRITE</literal>는 Hibernate가 한 행을 업데이트 하거나 insert 할 때 자동적으로 획득된다. + </para> + </listitem> + <listitem> + <para> + <literal>LockMode.UPGRADE</literal>는 <literal>SELECT ... FOR UPDATE</literal> 구문을 지원하는 + 데이터베이스 상에서 <literal>SELECT ... FOR UPDATE</literal>를 사용하여 명시적인 사용자 요청 상에서 + 얻어질 수 있다. + </para> + </listitem> + <listitem> + <para> + <literal>LockMode.UPGRADE_NOWAIT</literal>는 오라클에서 <literal>SELECT ... FOR UPDATE NOWAIT</literal>를 + 사용하여 명시적인 사용자 요청 상에서 얻어질 수도 있다. + </para> + </listitem> + <listitem> + <para> + <literal>LockMode.READ</literal>는 Hibernate가 반복 가능한 읽기(Repeatable Read) 또는 Serialization + 격리 레벨에서 데이터를 읽어들일 때 자동적으로 얻어질 수도 있다. 명시적인 사용자 요청에 의해 다시 얻어질 수도 있다. + </para> + </listitem> + <listitem> + <para> + <literal>LockMode.NONE</literal>은 잠금이 없음을 나타낸다. 모든 객체들은 <literal>Transaction</literal>의 끝에서 + 이 잠금 모드로 전환된다. <literal>update()</literal> 또는 <literal>saveOrUpdate()</literal>에 대한 호출을 통해 + 세션과 연관된 객체들이 또한 이 잠금 모드로 시작된다. + </para> + </listitem> + </itemizedlist> + + <para> + "명시적인 사용자 요청"은 다음 방법들 중 하나로 표현된다: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + <literal>LockMode</literal>를 지정한 <literal>Session.load()</literal>에 대한 호출. + </para> + </listitem> + <listitem> + <para> + <literal>Session.lock()</literal>에 대한 호출. + </para> + </listitem> + <listitem> + <para> + <literal>Query.setLockMode()</literal>에 대한 호출. + </para> + </listitem> + </itemizedlist> + + <para> + 만일 <literal>Session.load()</literal>가 <literal>UPGRADE</literal> 또는 <literal>UPGRADE_NOWAIT</literal> + 모드로 호출되고 ,요청된 객체가 아직 이 세션에 의해 로드되지 않았다면, 그 객체는 <literal>SELECT ... FOR UPDATE</literal>를 + 사용하여 로드된다. 만일 요청된 것이 아닌 다소 제한적인 잠금으로 이미 로드되어 있는 객체에 대해 <literal>load()</literal>가 + 호출될 경우, Hibernate는 그 객체에 대해 <literal>lock()</literal>을 호출한다. + </para> + + <para> + 만일 지정된 잠금 모드가 <literal>READ</literal>, <literal>UPGRADE</literal> 또는 + <literal>UPGRADE_NOWAIT</literal> 일 경우에 <literal>Session.lock()</literal>은 버전 번호 체크를 수행한다. + (<literal>UPGRADE</literal> 또는 <literal>UPGRADE_NOWAIT</literal> 인 경우에, + <literal>SELECT ... FOR UPDATE</literal>가 사용된다.) + </para> + + <para> + 만일 데이터베이스가 요청된 잠금 모드를 지원하지 않을 경우, (예외상황을 던지는 대신에) Hibernate는 적절한 대체 모드를 사용할 것이다. + 이것은 어플리케이션이 이식 가능할 것임을 확실히 해준다. + </para> + + </sect1> + + <sect1 id="transactions-connection-release"> + <title>연결 해제 모드들</title> + + <para> + JDBC 커넥션 관리에 관한 Hibernate의 리거시(2.x) 특징은 그것이 처음으로 필요로 했을 때 + 하나의 <literal>Session</literal>이 하나의 커넥션을 획득할 것이고, 그런 다음 그 커넥션은 그 세션이 + 닫혀질때까지 보관된다는 것이었다. + Hibernate 3.x는 세션에게 그것의 JDBC 커넥션들을 처리하는 방법을 알려주기 위해 연결 해제 모드들에 관한 + 개념을 도입했다. 다음 논의는 구성된 <literal>ConnectionProvider</literal>를 통해 제공되는 커넥션들에 + 대해서만 적절하다는 점을 노트하라; 사용자가 제공하는 커넥션들은 + <literal>org.hibernate.ConnectionReleaseMode</literal>의 열거된 값들에 의해 식별된다: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + <literal>ON_CLOSE</literal> - 는 본질적으로 위에 설명된 리거시 특징이다. Hibernate 세션은 그것이 + 어떤 JDBC 접근을 수행하고 세션이 닫혀질 때까지 그 커넥션을 보관할 필요가 있을 때 하나의 커넥션을 획득한다. + </para> + </listitem> + <listitem> + <para> + <literal>AFTER_TRANSACTION</literal> - 은 하나의 + <literal>org.hibernate.Transaction</literal>이 완료된 후에 연결들을 해제하라고 말한다. + </para> + </listitem> + <listitem> + <para> + <literal>AFTER_STATEMENT</literal> (또한 적극적인 해제라고 언급됨) - 는 각각의 모든 문장 실행 후에 + 커넥션들을 해제하라고 말한다. 이 적극적인 해제는 그 문장이 주어진 세션과 연관된 리소스들을 열려진채로 남겨둘 + 경우에는 건너뛰게(skip) 된다; 현재 이것이 일어나는 유일한 상황은 + <literal>org.hibernate.ScrollableResults</literal>의 사용을 통해서이다. + </para> + </listitem> + </itemizedlist> + + <para> + 사용할 해제 모드를 지정하기 위해 구성 파라미터 <literal>hibernate.connection.release_mode</literal>가 사용된다. + 가능한 값들은 다음과 같다: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para> + <literal>auto</literal> (디폴트) - 이 선택은 + <literal>org.hibernate.transaction.TransactionFactory.getDefaultReleaseMode()</literal> + 메소드에 의해 반환된 해제 모드로 위임시킨다. JTATransactionFactory인 경우, 이것은 + ConnectionReleaseMode.AFTER_STATEMENT를 반환한다; JDBCTransactionFactory인 경우, 이것은 + ConnectionReleaseMode.AFTER_TRANSACTION을 반환한다. 이 설정의 값이 사용자 코드 내의 버그들 그리고/또는 + 유효하지 않은 가정들을 가리키는 경향이 있음으로 인해 이 디폴트 특징을 실패로 변경하는 것은 거의 좋은 생각이 아니다. + </para> + </listitem> + <listitem> + <para> + <literal>on_close</literal> - 는 ConnectionReleaseMode.ON_CLOSE를 사용하라고 말한다. 이 설정은 + 역호환성을 위해 남겨졌지만, 그것의 사용은 매우 권장되지 않는다. + </para> + </listitem> + <listitem> + <para> + <literal>after_transaction</literal> - 은 ConnectionReleaseMode.AFTER_TRANSACTION을 사용하라고 말한다. + 이 설정은 JTA 환경들에서 사용되지 않을 것이다. 또한 + ConnectionReleaseMode.AFTER_TRANSACTION인 경우에 만일 세션이 auto-commit 모드에 있도록 고려될 경우, + 커넥션들은 마치 해제 모드가 AFTER_STATEMENT인 것처럼 해제될 것임을 또한 노트하라. + </para> + </listitem> + <listitem> + <para> + <literal>after_statement</literal> - 는 ConnectionReleaseMode.AFTER_STATEMENT를 사용하라고 말한다. + 추가적으로 구성된 <literal>ConnectionProvider</literal>는 그것이 이 설정 + (<literal>supportsAggressiveRelease()</literal>)을 지원하는지 여부를 알기 위해 참고된다. + 만일 지원하지 않을 경우, 해제 모드는 ConnectionReleaseMode.AFTER_TRANSACTION으로 재설정된다. 이 설정은 + 우리가 <literal>ConnectionProvider.getConnection()</literal>을 호출할 때마다 우리가 동일한 기본 JDBC + 커넥션을 다시 필요로 할 수 있는 환경들에서 또는 우리가 동일한 커넥션을 얻는 것에 상관없는 auto-commit 환경에서 오직 + 안전하다. + </para> + </listitem> + </itemizedlist> + + </sect1> + +</chapter> + Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/tutorial.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/tutorial.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/tutorial.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/tutorial.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,1486 @@ +<chapter id="tutorial"> + <title>Hibernate 개요</title> + + <sect1 id="tutorial-intro" revision="1"> + <title>머리말</title> + + <para> + 이 장은 Hibernate 초심자를 위한 개론적인 튜토리얼이다. 우리는 메모리-내 데이터베이스를 + 사용하는 간단한 명령 라인 어플리케이션으로 시작하고 단계들을 이해하도록 쉽게 그것을 개발한다. + </para> + + <para> + 이 튜토리얼은 Hibernate 신규 사용자들을 의도하고 있지만 Java와 SQL 지식을 필요로 한다. + 그것은 Michael Gloegl이 작성한 튜토리얼에 기초하며, 우리가 명명하는 제 3의 라이브러리들은 + JDK 1.4와 5.0 버전용이다. 당신은 JDK1.3에 대해 다른 라이브러리들을 필요로 할 수도 있다. + </para> + + <para> + 튜토리얼용 소스는 <literal>doc/reference/tutorial/</literal> 디렉토리 내에 있는 + 배포본 내에 포함되어 있다. + </para> + + </sect1> + + <sect1 id="tutorial-firstapp" revision="2"> + <title>파트 1 - 첫 번째 Hibernate 어플리케이션</title> + + <para> + 먼저, 우리는 한 개의 간단한 콘솔-기반 Hibernate 어플리케이션을 생성시킬 것이다. 우리는 메모리-내 + 데이터베이스(HSQL DB)를 사용하므로, 우리는 어떤 데이터베이스 서버를 설치하지 않아도 된다. + </para> + + <para> + 우리가 우리가 수반하고자 원하는 이벤트들을 저장할 수 있는 작은 데이터베이스 어플리케이션과 이들 + 이벤트들의 호스트들에 대한 정보를 필요로 한다고 가정하자. + </para> + + <para> + 우리가 행할 첫 번째 것은 우리의 개발 디렉토리를 설정하고, 우리가 필요로 하는 모든 Java 라이브러리들을 + 그것 속에 집어 넣는 것이다. Hibernate 웹 사이트로부터 Hibernate 배포본을 내려 받아라. 패키지를 + 추출해내고 <literal>/lib</literal> 속에서 발견되는 모든 필요한 라이브러리들을 당신의 새로운 개발 작업 + 디렉토리의 <literal>/lib</literal> 디렉토리 속에 위치지워라. 그것은 다음과 같을 것이다: + </para> + + <programlisting><![CDATA[. ++lib + antlr.jar + cglib.jar + asm.jar + asm-attrs.jars + commons-collections.jar + commons-logging.jar + hibernate3.jar + jta.jar + dom4j.jar + log4j.jar ]]></programlisting> + + <para> + 이것은 <emphasis>글의 작성 시점에서</emphasis> Hibernate에 필수적인 최소한의 세트이다(우리는 + 또한 메인 아카이브인 hibernate3.jar를 복사했음을 노트하라). 당신이 사용 중인 Hibernate 배포본이 + 더 많거나 보다 적은 라이브러리들을 필요로 할 수도 있다. 필수 라이브러리들과 선택적인 제3의 라이브러리들에 대한 + 추가 정보는 Hibernate 배포본의 <literal>lib/</literal> 디렉토리 내에 있는 <literal>README.txt</literal> + 파일을 보라. (실제로, Log4j는 필수는 아니지만 많은 개발자들에 의해 선호된다.) + </para> + + <para> + 다음으로 우리는 우리가 데이터베이스 속에 저장시키고자 원하는 이벤트를 표현하는 한 개의 클래스를 생성시킨다. + </para> + + <sect2 id="tutorial-firstapp-firstclass" revision="1"> + <title>첫 번째 클래스</title> + + <para> + 우리의 첫 번째 영속 클래스는 몇몇 프로퍼티들을 가진 간단한 자바빈즈 클래스이다: + </para> + + <programlisting><![CDATA[package events; + +import java.util.Date; + +public class Event { + private Long id; + + private String title; + private Date date; + + public Event() {} + + public Long getId() { + return id; + } + + private void setId(Long id) { + this.id = id; + } + + public Date getDate() { + return date; + } + + public void setDate(Date date) { + this.date = date; + } + + public String getTitle() { + return title; + } + + public void setTitle(String title) { + this.title = title; + } +}]]></programlisting> + + <para> + 당신은 이 클래스가 프로퍼티 getter와 setter 메소드들에 대한 표준 자바빈즈 명명법들 뿐만 아니라 필드들에 대한 + private 가시성을 사용하고 있음을 알 수 있다. 이것은 권장되는 설계이지만, 필수적이지는 않다. Hibernate는 + 또한 필드들에 직접 접근할 수 있으며, accessor 메소드들의 이점은 강건한 리팩토링이다. 아규먼트 없는 생성자는 + reflection을 통해 이 클래스의 객체를 초기화 시킬 필요가 있다. + </para> + + <para> + <literal>id</literal> 프로퍼티는 특별한 이벤트를 위한 유일 식별자를 소유한다. 모든 영속 엔티티 클래스들 + (보다 덜 중요한 종속 클래스들도 존재한다)은 우리가 Hibernate의 전체 특징 집합을 사용하고자 원할 경우에 + 그런 식별자 프로퍼티를 필요로 할 것이다. 사실 대부분의 어플리케이션들(특히 웹 어플리케이션들)은 식별자에 의해 + 객체들을 구분지을 필요가 있어서, 당신은 이것을 어떤 제약점이라기 보다는 하나의 특징으로 간주할 것이다. 하지만 + 우리는 대개 객체의 항등(identity)를 처리하지 않으므로, setter 메소드는 private이어야 한다. 객체가 저장될 때, + Hibernate는 단지 식별자들을 할당할 것이다. 당신은 Hibernate가 public, private, protected 접근자 메소드들 + 뿐만 아니라 (public, private, protected) 필드들에도 직접 접근할 수 있음을 알 수 있다. 선택은 당신에게 달려 + 있으며, 당신은 당신의 어플리케이션 설계에 적합하도록 그것을 부합시킬 수 있다. + </para> + + <para> + 아규먼트 없는 생성자는 모든 영속 클래스들에 대한 필요조건이다; Hibernate는 당신을 위해 Java Reflection을 + 사용하여 객체들을 생성시켜야 한다. 하지만 생성자는 private 일 수 있고, 패키지 가시성은 런타임 프락시 생성과 + 바이트코드 방편 없는 효율적인 데이터 검색에 필요하다. + </para> + + <para> + 이 Java 소스 파일을 개발 폴더 내의 <literal>src</literal>로 명명된 디렉토리 속에 있는 위치지워라. 이제 + 그 디렉토리는 다음과 같을 것이다: + </para> + + <programlisting><![CDATA[. ++lib + <Hibernate and third-party libraries> ++src + +events + Event.java]]></programlisting> + + <para> + 다음 단계에서, 우리는 Hiberante에게 이 영속 클래스에 대해 알려 준다. + </para> + + </sect2> + + <sect2 id="tutorial-firstapp-mapping" revision="1"> + <title>The mapping file</title> + + <para> + Hibernate는 영속 크래스들에 대한 객체들을 로드시키고 저장시키는 방법을 알 필요가 있다. + 이곳은 Hibernate 매핑 파일이 역할을 행하는 곳이다. 매핑 파일은 Hibernate가 접근해야 하는 + 데이터베이스 내의 테이블이 무엇인지, 그리고 그것이 사용해야 하는 그 테이블 내의 컬럼들이 + 무엇인지를 Hibernate에게 알려준다. + </para> + + <para> + 매핑 파일의 기본 구조는 다음과 같다: + </para> + + <programlisting><![CDATA[<?xml version="1.0"?> +<!DOCTYPE hibernate-mapping PUBLIC + "-//Hibernate/Hibernate Mapping DTD 3.0//EN" + "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> + +<hibernate-mapping> +[...] +</hibernate-mapping>]]></programlisting> + + <para> + Hibernate DTD는 매우 정교하다. 당신은 당신의 편집기 또는 IDE 내에서 XML 매핑 요소들과 속성들에 + 대한 자동 완성 기능을 위해 그것을 사용할 수 있다. 당신은 또한 당신의 텍스트 편집기 내에 DTD 파일을 + 열 수 있을 것이다 - 그것은 모든 요소들과 속성들에 대한 전체상을 얻고 디폴트들 뿐만 아니라 몇몇 주석들을 + 보는 가장 손쉬운 방법이다. Hibernate는 웹으로부터 DTD 파일을 로드시키지 않지만, 먼저 어플리케이션의 + classpath 경로로부터 그것을 먼저 룩업할 것임을 노트하라. DTD 파일은 <literal>hibernate3.jar</literal> + 속에 포함되어 있을 뿐만 아니라 Hibernate 배포본의 <literal>src/</literal> 디렉토리 속에 포함되어 + 있다. + </para> + + <para> + 우리는 코드를 간략화 시키기 위해 장래의 예제에서 DTD 선언을 생략할 것이다. 그것은 물론 옵션이 아니다. + </para> + + <para> + 두 개의 <literal>hibernate-mapping</literal> 태그들 사이에 <literal>class</literal> 요소를 + 포함시켜라. 모든 영속 엔티티 클래스들(다시금 종속 클래스들일 수 있고, 그것은 첫번째-급의 엔티티들이 아니다)은 + SQL 데이터베이스 내의 테이블에 대한 그런 매핑을 필요로 한다: + </para> + + <programlisting><![CDATA[<hibernate-mapping> + + <class name="events.Event" table="EVENTS"> + + </class> + +</hibernate-mapping>]]></programlisting> + + <para> + 지금까지 우리는 그 테이블 내에 있는 한 행에 의해 표현된 각각의 인스턴스인, 클래스의 객체를 영속화 시키고 + 로드시키는 방법을 Hibernate에게 알려주었다. 이제 우린느 테이블 프라이머리 키에 대한 유일 식별자 프로퍼티 매핑을 + 계속 행한다. 게다가 우리는 이 식별자를 처리하는 것에 주의를 기울이고자 원하지 않으므로, 우리는 대용 키 프라이머리 키 + 컬럼에 대한 Hibernate의 식별자 생성 방도를 구성한다: + </para> + + <programlisting><![CDATA[<hibernate-mapping> + + <class name="events.Event" table="EVENTS"> + <id name="id" column="EVENT_ID"> + <generator class="native"/> + </id> + </class> + +</hibernate-mapping>]]></programlisting> + + <para> + <literal>id</literal> 요소는 식별자 프로퍼티의 선언이고, <literal>name="id"</literal>는 + Java 프로퍼티의 이름을 선언한다 - Hibernate는 그 프로퍼티에 접근하는데 getter 및 setter 메소드들을 + 사용할 것이다. column 속성은 우리가 <literal>EVENTS</literal> 테이블의 어느 컬럼을 이 프라이머리 키로 + 사용하는지를 Hibernate에게 알려준다. 내포된 <literal>generator</literal> 요소는 식별자 생성 방도를 + 지정하며, 이 경우에 우리는 <literal>increment</literal>를 사용했고, 그것은 대개 테스팅(과 튜토리얼들)에 + 유용한 매우 간단한 메모리-내 숫자 증가 방법이다. Hibernate는 또한 전역적으로 유일한 데이터베이스에 의해 생성된 + 식별자 뿐만 아니라 어플리케이션에 의해 할당된 식별자(또는 당신이 확장으로 작성한 어떤 방도)를 지원한다. + </para> + + <para> + 마지막으로 우리는 매핑 파일 속에서 클래스의 영속 프로퍼티들에 대한 선언들을 포함한다. 디폴트로, 클래스의 + 프로퍼티들은 영속적인 것으로 간주되지 않는다: + </para> + + <programlisting><![CDATA[ +<hibernate-mapping> + + <class name="events.Event" table="EVENTS"> + <id name="id" column="EVENT_ID"> + <generator class="native"/> + </id> + <property name="date" type="timestamp" column="EVENT_DATE"/> + <property name="title"/> + </class> + +</hibernate-mapping>]]></programlisting> + + <para> + <literal>id</literal> 요소의 경우처럼, <literal>property</literal> 요소의 <literal>name</literal> + 속성은 사용할 getter 및 setter 메소드들이 어느 것인지를 Hibernate에게 알려준다. 따라서 이 경우에 Hibernate는 + <literal>getDate()/setDate()</literal> 뿐만 아니라 <literal>getTitle()/setTitle()</literal>을 + 찾게 될 것이다. + </para> + + <para> + <literal>date</literal> 프로퍼티 매핑은 <literal>column</literal> 속성을 포함하는데, + 왜 <literal>title</literal>은 <literal>column</literal> 속성을 포함하지 않는가? + <literal>column</literal> 속성이 없을 경우 Hibernate는 디폴트로 컬럼 이름으로서 프로퍼티 이름을 + 사용한다. 이것은 에 대해 잘 동작한다. 하지만 <literal>date</literal>는 대부분의 데이터베이스에서 + 예약된 키워드이어서, 우리는 그것을 다른 이름으로 더 좋게 매핑 시킨다. + </para> + + <para> + 다음 흥미로운 점은 <literal>title</literal> 매핑 또한 <literal>type</literal> 속성을 갖지 않는다. + 우리가 매핑파일들 속에서 선언하고 사용하는 타입들은 당신이 예상하는 Java 데이터 타입들이 아니다. 그것들은 + 또한 SQL 데이터베이스 타입들도 아니다. 이들 타입들은 이른바 <emphasis>Hibernate 매핑 타입들</emphasis>, + 즉 Java 타입들로부터 SQL 타입들로 변환될 수 있고 반대로 SQL 타입들로부터 Java 타입들로 매핑될 수 있는 컨버터들이다. + 다시말해, <literal>type</literal> 속성이 매핑 속에 존재하지 않을 경우 Hibernate는 정확환 변환 및 매핑 타입 + 그 자체를 결정하려고 시도할 것이다. 몇몇 경우들에서 (Java 클래스에 대한 Reflection을 사용하는) 이 자동적인 검출은 + 당신이 예상하거나 필요로 하는 디폴트를 갖지 않을 수도 있다. 이것은 <literal>date</literal> 프로퍼티를 가진 + 경우이다. Hibernate는 그 프로퍼티가 SQL <literal>date</literal> 컬럼, <literal>timestamp</literal> + 컬럼 또는 <literal>time</literal> 컬럼 중 어느 것으로 매핑되어야 하는지를 알 수가 없다. 우리는 + <literal>timestamp</literal> 컨버터를 가진 프로퍼티를 매핑함으로써 전체 날짜와 시간 정보를 보존하고 싶다고 + 선언한다. + </para> + + <para> + 다음 매핑 파일은 <literal>Event</literal> Java 클래스 소스 파일과 같은 디렉토리 속에 + <literal>Event.hbm.xml</literal>로서 저장될 것이다. 매핑 파일들에 대한 네이밍은 임의적일 수 + 있지만, 접미사 <literal>hbm.xml</literal>은 Hibernate 개발자 공동체 내에서 컨벤션이 되었다. + 디렉토리 구조는 이제 다음과 같을 것이다: + </para> + + <programlisting><![CDATA[. ++lib + <Hibernate and third-party libraries> ++src + +events + Event.java + Event.hbm.xml]]></programlisting> + + <para> + 우리는 Hibernate의 메인 구성을 계속 행한다. + </para> + + </sect2> + + <sect2 id="tutorial-firstapp-configuration" revision="2"> + <title>Hibernate 구성</title> + + <para> + 우리는 이제 적절한 곳에 한 개의 영속 클래스와 그것의 매핑 파일을 갖고 있다. Hibernate를 구성할 차례이다. + 우리가 이것을 행하기 전에, 우리는 데이터베이스를 필요로 할 것이다. 자바 기반의 메모리-내 SQL DBMS인 + HSQL DB는 HSQL DB 웹 사이트에서 내려받을 수 있다. 실제로, 당신은 이 다운로드에서 오직 <literal>hsqldb.jar</literal> + 만을 필요로 한다. 개발 폴더의 <literal>lib/</literal> 디렉토리 속에 이 파일을 위치지워라. + </para> + + <para> + 개발 디렉토리의 루트에 <literal>data</literal>로 명명된 디렉토리를 생성시켜라 - 이 디렉토리는 + HSQL DB가 그것의 데이터 파일들을 저장하게 될 장소이다. 이제 이 데이터 디렉토리에서 + <literal>java -classpath ../lib/hsqldb.jar org.hsqldb.Server</literal>를 실행시켜서 + 데이터베이스를 시작시켜라. 당신은 그것이 시작되고 이것은 우리의 어플리케이션이 나중에 연결하게 될 장소인, + 하나의 TCP/IP 소켓에 바인드 되는 것을 볼 수 있다. 만일 이 튜토리얼 동안에 당신이 새 데이터베이스로 + 시작하고자 원할 경우, HSQL DB를 셧다운시키고(왼도우에서 <literal>CTRL + C</literal>를 눌러라), + <literal>data/</literal> 디렉토리 내에 있는 모든 파일들을 삭제하고 다시 HSQL DB를 시작하라. + </para> + + <para> + Hibernate는 당신의 어플리케이션 내에서 이 데이터베이스에 연결하는 계층이고, 따라서 그것은 커넥션 정보를 + 필요로 한다. 커넥션들은 마찬가지로 구성되어야 하는 하나의 JDBC 커넥션 풀을 통해 행해진다. Hibernate + 배포본은 몇몇 오픈 소스 JDBC 커넥션 풀링 도구들을 포함하고 있지만, 이 튜토리얼에서는 Hibernate에 의해 + 미리 빌드된 커넥션 풀링을 사용할 것이다. 당신이 필수 라이브러리를 당신의 classpath 속에 복사해야 하고 + 만일 당신이 제품-특징의 제3의 JDBC 풀링 소프트웨어를 사용하고자 원할 경우에는 다른 커넥션 풀링 설정들을 + 사용해야 함을 노트하라. + </para> + + <para> + Hibernate의 구성을 위해, 우리는 한 개의 간단한 <literal>hibernate.properties</literal> 파일, + 한 개의 약간 더 세련된 <literal>hibernate.cfg.xml</literal> 파일, 또는 심지어 완전한 프로그램 + 상의 설정을 사용할 수 있다. 대부분의 사용자들은 XMl 구성 파일을 선호한다: + </para> + + <programlisting><![CDATA[<?xml version='1.0' encoding='utf-8'?> +<!DOCTYPE hibernate-configuration PUBLIC + "-//Hibernate/Hibernate Configuration DTD 3.0//EN" + "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd"> + +<hibernate-configuration> + + <session-factory> + + <!-- Database connection settings --> + <property name="connection.driver_class">org.hsqldb.jdbcDriver</property> + <property name="connection.url">jdbc:hsqldb:hsql://localhost</property> + <property name="connection.username">sa</property> + <property name="connection.password"></property> + + <!-- JDBC connection pool (use the built-in) --> + <property name="connection.pool_size">1</property> + + <!-- SQL dialect --> + <property name="dialect">org.hibernate.dialect.HSQLDialect</property> + + <!-- Enable Hibernate's automatic session context management --> + <property name="current_session_context_class">thread</property> + + <!-- Disable the second-level cache --> + <property name="cache.provider_class">org.hibernate.cache.NoCacheProvider</property> + + <!-- Echo all executed SQL to stdout --> + <property name="show_sql">true</property> + + <!-- Drop and re-create the database schema on startup --> + <property name="hbm2ddl.auto">create</property> + + <mapping resource="events/Event.hbm.xml"/> + + </session-factory> + +</hibernate-configuration>]]></programlisting> + + <para> + 이 XML 구성이 다른 DTD를 사용함을 노트하라. 우리는 Hibernate의 <literal>SessionFactory</literal> + -특정 데이터베이스에 대해 책임이 있는 전역 팩토리-를 구성한다. 만일 당신이 여러 데이터베이스들을 + 갖고 있다면, (보다 쉬운 시작을 위해) 몇 개의 구성 파일들 속에 여러 개의 <literal>&lt;session-factory&gt;</literal> + 구성들을 사용하라. + </para> + + <para> + 처음 네 개의 <literal>property</literal> 요소들은 JDBC 커넥션을 위한 필수 구성을 포함한다. + dialect <literal>property</literal> 요소는 Hibernate가 발생시키는 특별한 SQL 이형(異形)을 + 지정한다. + <literal>hbm2ddl.auto</literal> 옵션은 -직접 데이터베이스 속으로- 데이터베이스 스키마의 자동적인 + 생성을 활성화 시킨다. 물론 이것은 (config 옵션을 제거함으로써) 비활성화 시킬 수 있거나 + <literal>SchemaExport</literal> Ant 태스크의 도움으로 파일로 리다이렉트 될 수 있다. 마지막으로 + 우리는 영속 클래스들을 위한 매핑 파일(들)을 추가시킨다. + </para> + + <para> + 이 파일을 소스 디렉토리 속으로 복사하고, 따라서 그것은 classpath의 루트에서 끝날 것이다. Hibernate는 + 시작 시에 classpath의 루트에서 <literal>hibernate.cfg.xml</literal>로 명명된 파일을 자동적으로 + 찾는다. + </para> + + </sect2> + + <sect2 id="tutorial-firstapp-ant" revision="1"> + <title>Ant로 빌드하기</title> + + <para> + 우리는 이제 Ant로 튜토리얼을 빌드할 것이다. 당신은 Ant를 설치할 필요가 있을 것이다 - + <ulink url="http://ant.apache.org/bindownload.cgi">Ant 내려받기 페이지</ulink>에서 + Ant를 얻어라. Ant를 설치하는 방법은 여기서 다루지 않을 것이다. <ulink url="http://ant.apache.org/manual/index.html">Ant 매뉴얼</ulink>을 + 참조하길 바란다. 당신이 Ant를 설치한 후에, 우리는 빌드파일 생성을 시작할 수 있다. 그것은 <literal>build.xml</literal>로 + 명명되고 개발 디렉토리 속에 직접 위치될 것이다. + </para> + + <para> + 기본 빌드 파일은 다음과 같다: + </para> + + <programlisting><![CDATA[<project name="hibernate-tutorial" default="compile"> + + <property name="sourcedir" value="${basedir}/src"/> + <property name="targetdir" value="${basedir}/bin"/> + <property name="librarydir" value="${basedir}/lib"/> + + <path id="libraries"> + <fileset dir="${librarydir}"> + <include name="*.jar"/> + </fileset> + </path> + + <target name="clean"> + <delete dir="${targetdir}"/> + <mkdir dir="${targetdir}"/> + </target> + + <target name="compile" depends="clean, copy-resources"> + <javac srcdir="${sourcedir}" + destdir="${targetdir}" + classpathref="libraries"/> + </target> + + <target name="copy-resources"> + <copy todir="${targetdir}"> + <fileset dir="${sourcedir}"> + <exclude name="**/*.java"/> + </fileset> + </copy> + </target> + +</project>]]></programlisting> + + <para> + 이것은 <literal>.jar</literal>로 끝나는 lib 디렉토리 내에 있는 모든 파일들을 컴파일에 사용되는 classpath에 + 추가하도록 Ant에게 알려줄 것이다. 그것은 또한 모든 비-Java 소스 파일들을 대상 디렉토리로 복사할 것이다. 예를 들면, + 구성 및 Hibernate 매핑 파일들. 만일 당신이 Ant를 이제 실행할 경우, 당신은 다음 출력을 얻게 될 것이다: + </para> + + <programlisting><![CDATA[C:\hibernateTutorial\>ant +Buildfile: build.xml + +copy-resources: + [copy] Copying 2 files to C:\hibernateTutorial\bin + +compile: + [javac] Compiling 1 source file to C:\hibernateTutorial\bin + +BUILD SUCCESSFUL +Total time: 1 second ]]></programlisting> + + </sect2> + + <sect2 id="tutorial-firstapp-helpers" revision="3"> + <title>시작과 helper들</title> + + <para> + 몇몇 <literal>Event</literal> 객체들을 로드시키고 저장할 차례이지만, 먼저 우리는 어떤 인프라스트럭처 + 코드로 설정을 완료해야 한다. 우리는 Hibernate를 시작해야 한다. 이 시작은 전역 <literal>SessionFactory</literal> + 객체를 빌드하고 어플리케이션 내에서 용이한 접근을 위해 그것을 어떤 곳에 저장하는 것을 포함한다. + <literal>SessionFactory</literal>는 새로운 <literal>Session</literal>들을 열 수 있다. + <literal>Session</literal>은 작업의 단일-쓰레드 단위를 표현하며, <literal>SessionFactory</literal>는 + 한번 초기화 되는 하나의 thread-safe 전역 객체이다. + </para> + + <para> + 우리는 시작을 처리하고 <literal>Session</literal> 처리를 편리하게 해주는 <literal>HibernateUtil</literal> + helper 클래스를 생성시킬 것이다. 이른바 <emphasis>ThreadLocal Session</emphasis> 패턴이 여기서 + 유용하며, 우리는 현재의 작업 단위를 현재의 쓰레드와 연관지워 유지한다. 구현을 살펴보자: + </para> + + <programlisting><![CDATA[package util; + +import org.hibernate.*; +import org.hibernate.cfg.*; + +public class HibernateUtil { + + private static final SessionFactory sessionFactory; + + static { + try { + // Create the SessionFactory from hibernate.cfg.xml + sessionFactory = new Configuration().configure().buildSessionFactory(); + } catch (Throwable ex) { + // Make sure you log the exception, as it might be swallowed + System.err.println("Initial SessionFactory creation failed." + ex); + throw new ExceptionInInitializerError(ex); + } + } + + public static SessionFactory getSessionFactory() { + return sessionFactory; + } + +}]]></programlisting> + + <para> + 이 클래스는 (클래스가 로드될 때 JVM에 의해 한번 호출되는) 그것의 static 초기자 내에 전역 <literal>SessionFactory</literal>를 + 산출할 뿐만 아니라 또한 현재 쓰레드에 대한 <literal>Session</literal>을 소유하는 <literal>ThreadLocal</literal> 변수를 + 갖는다. 당신이 <literal>HibernateUtil.getCurrentSession()</literal>을 호출하는 시점에는 문제가 없으며, + 그것은 항상 동일 쓰레드 내에 동일한 Hibernate 작업 단위를 반환할 것이다. <literal>HibernateUtil.closeSession()</literal>에 + 대한 호출은 쓰레드와 현재 연관되어 있는 작업 단위를 종료시킨다. + </para> + + <para> + 당신이 이 helper를 사용하기 전에 thread-local 변수들에 대한 Java 개념을 확실히 이해하도록 하라. + 보다 강력한 <literal>HibernateUtil</literal> helper는 http://caveatemptor.hibernate.org/에 + 있는 <literal>CaveatEmptor</literal> 뿐만 아니라 "Java Persistence with Hibernate" 책에서 찾을 수 있다. + 당신이 J2EE 어플리케이션 서버 내에 Hibernate를 배치할 경우에 이 클래스는 필수적이지 않다: 하나의 + <literal>Session</literal>은 현재의 JTA 트랜잭션에 자동적으로 바인드 될 것이고 당신은 JNDI를 통해 + <literal>SessionFactory</literal>를 룩업할 수 있다. 만일 당신이 JBoss AS를 사용할 경우, + Hibernate는 관리되는 시스템 서비스로서 배치될 수 있고 <literal>SessionFactory</literal>를 + JNDI 이름에 자동적으로 바인드시킬 수 있을 것이다. + </para> + + <para> + 개발 소스 디렉토리 속에 <literal>HibernateUtil.java</literal> 를 위치지우고, 다음으로 <literal>Event.java</literal>를 + 위치지워라: + </para> + + <programlisting><![CDATA[. ++lib + <Hibernate and third-party libraries> ++src + +events + Event.java + Event.hbm.xml + +util + HibernateUtil.java + hibernate.cfg.xml ++data +build.xml]]></programlisting> + + <para> + 이것은 문제 없이 다시 컴파일 될 것이다. 우리는 마지막으로 로깅 시스템을 구성할 필요가 있다 - Hibernate는 + commons logging를 사용하고 Log4j와 JDK 1.4 사이의 선택은 당신의 몫으로 남겨둔다. 대부분의 개발자들은 + Log4j를 선호한다: Hibernate 배포본에 있는 <literal>log4j.properties</literal>(이것은 디렉토리 + <literal>etc/</literal> 내에 있다)를 <literal>src</literal> 디렉토리로 복사하고, 다음으로 + <literal>hibernate.cfg.xml</literal>을 복사하라. 예제 구성을 살펴보고 당신이 더 많은 verbose 출력을 + 원할 경우에 설정들을 변경하라. 디폴트로 Hibernate 시작 메시지는 stdout 상에 보여진다. + </para> + + <para> + 튜토리얼 인프라스트럭처는 완전하다 - 그리고 우리는 Hibernate로 어떤 실제 작업을 행할 준비가 되어 있다. + </para> + + </sect2> + + <sect2 id="tutorial-firstapp-workingpersistence" revision="5"> + <title>객체 로딩과 객체 저장</title> + + <para> + 마지막으로 우리는 객체들을 로드시키고 저장하는데 Hibernate를 사용할 수 있다. 우리는 한 개의 <literal>main()</literal> + 메소드를 가진 한 개의 <literal>EventManager</literal> 클래스를 작성한다: + </para> + + <programlisting><![CDATA[package events; +import org.hibernate.Session; + +import java.util.Date; + +import util.HibernateUtil; + +public class EventManager { + + public static void main(String[] args) { + EventManager mgr = new EventManager(); + + if (args[0].equals("store")) { + mgr.createAndStoreEvent("My Event", new Date()); + } + + HibernateUtil.getSessionFactory().close(); + } + + private void createAndStoreEvent(String title, Date theDate) { + + Session session = HibernateUtil.getSessionFactory().getCurrentSession(); + + session.beginTransaction(); + + Event theEvent = new Event(); + theEvent.setTitle(title); + theEvent.setDate(theDate); + + session.save(theEvent); + + session.getTransaction().commit(); + } + +}]]></programlisting> + + <para> + 우리는 한 개의 새로운 <literal>Event</literal> 객체를 생성시키고, 그것을 Hibernate에게 건네준다. + Hibernate는 이제 SQL을 처리하고 데이터베이스 상에서 <literal>INSERT</literal>들을 실행시킨다. + -우리가 이것을 실행하기 전에 코드를 처리하는- <literal>Session</literal>과 <literal>Transaction</literal>을 + 살펴보자. + </para> + + <para> + <literal>Session</literal>은 한 개의 작업 단위이다. 지금부터 우리는 단숨함을 유지할 것이고 + Hibernate <literal>Session</literal>과 데이터베이스 트랜잭션 사이의 일-대-일 과립형(granularity)을 가정할 것이다. + 실제 기반 트랜잭션 시스템으로부터 우리의 소스를 은폐시키기 위해(이 경우 통상의 JDBC이지만, 그것은 또한 JTA에도 실행된다) + 우리는 Hibernate <literal>Session</literal> 상에서 이용 가능한 <literal>Transaction</literal> API를 + 사용한다. + </para> + + <para> + + <literal>sessionFactory.getCurrentSession()</literal>은 무엇을 행하는가? 먼저 + 당신은 당신이 (<literal>HibernateUtil</literal> 덕분에 쉽게) <literal>SessionFactory</literal>을 + 당신이 소유하고 있다면, 원하는 만큼 어디서든 여러번 그것을 호출할 수 있다. + <literal>getCurrentSession()</literal> 메소드는 항상 "현재의" 작업 단위를 반환한다. 우리가 + <literal>hibernate.cfg.xml</literal> 내에서 이 매커니즘에 대한 구성 옵션을 "thread"로 전환시켰음을 기억하는가? + 그러므로 작업의 현재 단위는 우리의 어플리케이션을 실행시키는 현재 자바 쓰레드에 묶여 있다. 하지만 + 이것은 전체 그림이 아니며, 당신은 또한 scope(영역), 작업 단위가 시작될 때와 작업 단위가 종료될 때를 + 고려해야 한다. + </para> + + <para> + <literal>Session</literal>은 그것이 처음으로 필요로 되고 <literal>getCurrentSession()</literal>에 대한 + 첫 번째 호출이 이루어질 때 시작된다. 그때 그것은 Hibernate에 의해 현재의 쓰레드에 바인드 된다. + 커밋되든 롤백되든 간에 트랜잭션이 종료되고, Hibernate가 자동적으로 그 쓰레드로부터 <literal>Session</literal>을 + 바인드 해제시키고 당신을 위해 세션을 닫는다. 만일 당신이 <literal>getCurrentSession()</literal>을 다시 + 호출한다면, 당신은 새로운 <literal>Session</literal>을 얻고 새로운 작업단위를 시작할 수 있다. + 이 <emphasis>thread-bound</emphasis> 프로그래밍 모형은 Hibernate를 사용하는 가장 대중적인 방법이다. + 왜냐하면 그것은 당신의 코드를 유연하게 계층화시키는 것을 허용해주기 때문이다(트랜잭션 경계 분할 코드는 + 데이트 접근 코드와 구별지워질 수 있는데, 우리는 이 튜토리얼의 뒷부분에서 이것을 다룰 것이다.). + </para> + + <para> + 작업 영역의 단위와 관련하여, Hibernate <literal>Session</literal>은 하나 또는 여러 개의 데이터베이스 + 오퍼레이션들을 실행시키는데 사용될 수 있는가? 위의 예제는 하나의 오퍼레이션에 한 개의 <literal>Session</literal>을 + 사용하고 있다. 이것은 순진한 일치이며, 예제는 어떤 다른 접근법을 보여주기에는 충분히 복잡하지 않다. + Hibernate <literal>Session</literal>의 scope(영역)은 유연하지만 당신은 결코 <emphasis>모든</emphasis> + 데이터베이스 오퍼레이션 각각에 대해 새로운 Hibernate <literal>Session</literal>을 사용하도록 + 당신의 어플리케이션을 설계할 수 없다. 따라서 심지어 당신이 다음의 (매우 사소한) 예제들에서 여러 번 + 그것을 볼 수 있을지라도 <emphasis>session-per-operation</emphasis>을 하나의 안티-패턴으로 간주하라. + 실제 (웹) 어플리케이션은 이 튜토리얼의 뒷부분에 보여진다. + </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}"/> + <arg value="${action}"/> + </java> +</target>]]></programlisting> + + <para> + <literal>action</literal> 아규먼트의 값은 대상을 호출할 때 명령 라인 상에서 설정된다: + </para> + + <programlisting><![CDATA[C:\hibernateTutorial\>ant run -Daction=store]]></programlisting> + + <para> + 컴파일, 구성에 따른 Hibernate 시작 후에, 당신은 많은 로그 출력을 보게 될 것이다. 끝에서 당신은 + 다음 라인을 발견할 것이다: + </para> + + <programlisting><![CDATA[[java] Hibernate: insert into EVENTS (EVENT_DATE, title, EVENT_ID) values (?, ?, ?)]]></programlisting> + + <para> + 이것은 Hibernate에 의해 실행된 <literal>INSERT</literal>이고, 물음표 기호는 JDBC 바인드 + 파라미터들을 나타낸다. 아규먼트로서 바인드 된 값들을 보거나 장황한 로그를 줄이려면 당신의 + <literal>log4j.properties</literal>를 체크하라. + </para> + + <para> + 이제 우리는 마찬가지로 저장된 이벤트들을 열거하고자 원하며, 우리는 main 메소드에 한 개의 옵션을 + 추가한다: + </para> + + <programlisting><![CDATA[if (args[0].equals("store")) { + mgr.createAndStoreEvent("My Event", new Date()); +} +else if (args[0].equals("list")) { + List events = mgr.listEvents(); + for (int i = 0; i < events.size(); i++) { + Event theEvent = (Event) events.get(i); + System.out.println("Event: " + theEvent.getTitle() + + " Time: " + theEvent.getDate()); + } +}]]></programlisting> + + <para> + 우리는 또한 새로운 <literal>listEvents() method</literal> 메소드를 추가 시킨다: + </para> + + <programlisting><![CDATA[private List listEvents() { + + Session session = HibernateUtil.getSessionFactory().getCurrentSession(); + + session.beginTransaction(); + + List result = session.createQuery("from Event").list(); + + session.getTransaction().commit(); + + return result; +}]]></programlisting> + + <para> + 여기서 우리가 행할 것은 데이터베이스로부터 모든 존재하는 <literal>Event</literal> 객체들을 로드시키기 + 위해 HQL (Hibernate Query Language) 질의를 사용하는 것이다. Hibernate는 적절한 SQL을 생성시킬 + 것이고, 그것을 데이터베이스로 전송하고 데이터를 <literal>Event</literal> 객체들에 거주시킬 것이다. + 당신은 물론 HQL로서 보다 복잡한 질의들을 생성시킬 수 있다. + </para> + + <para> + 이제 이 모든 것을 실행하고 테스트하기 위해, 다음 단계들을 따르라: + </para> + + <itemizedlist> + <listitem> + <para> + 데이터베이스 속으로 어떤 것을 저장하고 물론 앞서 hbm2ddl을 통해 데이터베이스 스키마를 산출시키기 위해 + <literal>ant run -Daction=store</literal>를 실행하라. + </para> + </listitem> + <listitem> + <para> + 이제 당신의 <literal>hibernate.cfg.xml</literal> 파일 속에서 그 프로퍼티를 주석처리함으로써 hbm2ddl을 + 사용불가능하게 하라. 대개 당신은 지속되는 단위 테스팅에서는 그것을 사용 가능하게 내버려두어도 되지만, 또 다른 + hbm2ddl의 실행은 당신이 저장했던 모든 것을 <emphasis>drop</emphasis>시킬 것이다 - <literal>create</literal> + 구성 설정은 실제로 "스키마로부터 모든 테이블들을 드롭시키고 나서, SessionFactory가 빌드될 때 모든 테이블들을 + 다시 생성시키는 것"으로 변환된다. + </para> + </listitem> + </itemizedlist> + + <para> + 만일 당신이 지금 <literal>-Daction=list</literal>로 Ant를 호출할 경우, 당신은 당신이 지금까지 저장했던 이벤트들을 + 보게 될 것이다. 물론 당신은 또한 여러 번 <literal>store</literal> 액션을 호출할 수 있다. + </para> + + <para> + 노트 : 대부분의 Hibernate 사용자들은 이 지점에서 실패하고 우리는 정기적으로 <emphasis>Table not found</emphasis> + 오류 메시지들에 관한 질문을 받는다. 하지만 만일 당신이 위에 조명된 단게들을 따를 경우 당신은 이 문제를 겪지 않을 것이고, + hbm2ddl이 처음 실행 시에 데이터베이스 스키마를 생성시키므로, 차후의 어플리케이션 재시작은 이 스키마를 사용할 것이다. + 만일 당신이 매핑 그리고/또는 데이터베이스 스키마를 변경할 경우에, 당신은 다시 한번 더 hbm2ddl을 이용 가능하도록 해야 한다. + </para> + + </sect2> + + </sect1> + + <sect1 id="tutorial-associations"> + <title>파트 2 - 연관들을 매핑하기</title> + + <para> + 우리는 한 개의 영속 엔티티 클래스를 한 개의 테이블로 매핑했다. 이것 위에서 빌드하고 몇몇 클래스 연관들을 추가시키자. 먼저 + 우리는 우리의 어플리케이션에 사람들을 추가하고 그들이 참여하는 이벤트들의 목록을 저장할 것이다. + </para> + + <sect2 id="tutorial-associations-mappinguser" revision="1"> + <title>Person 클래스 매핑하기</title> + + <para> + 클래스의 첫 번째 장면은 간단하다: + </para> + + <programlisting><![CDATA[package events; + +public class Person { + + private Long id; + private int age; + private String firstname; + private String lastname; + + public Person() {} + + // Accessor methods for all properties, private setter for 'id' + +}]]></programlisting> + + <para> + <literal>Person.hbm.xml</literal>로 명명되는 새로운 매핑 파일을 생성시켜라 + (맨위에 DTD 참조를 잊지말라): + </para> + + <programlisting><![CDATA[<hibernate-mapping> + + <class name="events.Person" table="PERSON"> + <id name="id" column="PERSON_ID"> + <generator class="native"/> + </id> + <property name="age"/> + <property name="firstname"/> + <property name="lastname"/> + </class> + +</hibernate-mapping>]]></programlisting> + + <para> + 마지막으로 새로운 매핑을 Hibernate의 구성에 추가하라: + </para> + + <programlisting><![CDATA[<mapping resource="events/Event.hbm.xml"/> +<mapping resource="events/Person.hbm.xml"/>]]></programlisting> + + <para> + 이제 우리는 이들 두 개의 엔티티들 사이에 한 개의 연관을 생성시킬 것이다. 명백하게, 개인들은 이벤트들에 + 참여할 수 있고, 이벤트들은 참여자들을 갖는다. 우리가 다루어야 하는 설계 질문들은 다음과 같다 : + 방향성(directionality), 다중성(multiplicity), 그리고 콜렉션 특징. + </para> + + </sect2> + + <sect2 id="tutorial-associations-unidirset" revision="3"> + <title>단방향 Set-기반의 연관</title> + + <para> + 우리는 <literal>Person</literal> 클래스에 이벤트들을 가진 한 개의 콜렉션을 추가할 것이다. 그 방법으로 우리는 + 명시적인 질의-<literal>aPerson.getEvents()</literal>를 호출함으로써-를 실행시키지 않고서 특정 개인에 대한 + 이벤트들을 쉽게 네비게이트할 수 있다. 우리는 하나의 Java 콜렉션, 하나의 <literal>Set</literal>를 사용한다. 왜냐하면 + 그 콜렉션은 중복 요소들을 포함하기 않을 것이고 그 순서가 우리와 관련되어 있지 않기 때문이다. + </para> + + <para> + 우리는 하나의 <literal>Set</literal>으로 구현된, 하나의 단방향, 다중값 연관들을 필요로 한다. Java 클래스들 내에 + 이를 위한 코드를 작성하고 그런 다음 그것을 매핑시키자: + </para> + + <programlisting><![CDATA[public class Person { + + private Set events = new HashSet(); + + public Set getEvents() { + return events; + } + + public void setEvents(Set events) { + this.events = events; + } +}]]></programlisting> + + <para> + 우리가 이 연관을 매핑하기 전에, 다른 측에 대해 생각하라. 명백하게 우리는 이것을 단지 단방향으로 유지시킬 수 있다. + 또는 우리가 그것을 양방향으로 네비게이트하는 것-예를 들어 <literal>anEvent.getParticipants()</literal>-이 + 가능하도록 원할 경우에, <literal>Event</literal>측 상에 또 다른 콜렉션을 생성시킬 수 있다. 이것은 당신에게 + 남겨진 설계 선택이지만, 이 논의에서 명료한 점은 연관의 다중성이다: 양 측 상에서 "다중" 값을 갖는 경우, 우리는 이것을 + <emphasis>many-to-many</emphasis> 연관이라고 명명한다. 그러므로 우리는 Hibernate의 many-to-many 매핑을 + 사용한다: + </para> + + <programlisting><![CDATA[<class name="events.Person" table="PERSON"> + <id name="id" column="PERSON_ID"> + <generator class="native"/> + </id> + <property name="age"/> + <property name="firstname"/> + <property name="lastname"/> + + <set name="events" table="PERSON_EVENT"> + <key column="PERSON_ID"/> + <many-to-many column="EVENT_ID" class="events.Event"/> + </set> + +</class>]]></programlisting> + + <para> + Hibernate는 모든 종류의 콜렉션 매핑들, 가장 공통적인 <literal>&lt;set&gt;</literal>을 지원한다. many-to-many + 연관 (또는 <emphasis>n:m</emphasis> 엔티티 관계)의 경우, 한 개의 연관 테이블이 필요하다. 이 테이블 내에 있는 각각의 + 행은 한 명의 개인과 한 개의 이벤트 사이의 링크를 표현한다. 테이블 이름은 <literal>set</literal> 요소의 <literal>table</literal> + 속성으로 구성된다. 연관 내의 식별자 컬럼 이름은 개인 측에 대해 <literal>&lt;key&gt;</literal> 요소로 정의되고 + 이벤트 측에 대한 컬럼 이름은 <literal>&lt;many-to-many&gt;</literal>의 <literal>column</literal> 속성으로 + 정의된다. 당신은 또한 당신의 콜렉션 내에 있는 객체들의 클래스(정확하게 : 참조들을 가진 콜렉션의 다른 측 상에 있는 클래스)를 + Hibernate에게 알려주어야 한다. + </para> + + <para> + 따라서 이 매핑을 위한 데이터베이스 스키마는 다음과 같다: + </para> + + <programlisting><![CDATA[ + _____________ __________________ + | | | | _____________ + | EVENTS | | PERSON_EVENT | | | + |_____________| |__________________| | PERSON | + | | | | |_____________| + | *EVENT_ID | <--> | *EVENT_ID | | | + | EVENT_DATE | | *PERSON_ID | <--> | *PERSON_ID | + | TITLE | |__________________| | AGE | + |_____________| | FIRSTNAME | + | LASTNAME | + |_____________| + ]]></programlisting> + + </sect2> + + <sect2 id="tutorial-associations-working" revision="2"> + <title>연관들에 작업하기</title> + + <para> + <literal>EventManager</literal> 속에 있는 한 개의 새로운 메소드 내에 몇몇 사람들과 이벤트들을 함께 가져오자: + </para> + + <programlisting><![CDATA[private void addPersonToEvent(Long personId, Long eventId) { + + Session session = HibernateUtil.getSessionFactory().getCurrentSession(); + session.beginTransaction(); + + Person aPerson = (Person) session.load(Person.class, personId); + Event anEvent = (Event) session.load(Event.class, eventId); + + aPerson.getEvents().add(anEvent); + + session.getTransaction().commit(); +}]]></programlisting> + + <para> + <literal>Person</literal>과 <literal>Event</literal>를 로드시킨 후에, 정규 콜렉션 메소드들을 사용하여 + 콜렉션을 간단하게 변경하라. 당신이 알 수 있듯이, <literal>update()</literal> 또는 <literal>save()</literal>에 + 대한 명시적인 호출이 존재하지 않고, 변경되었고 저장할 필요가 있는 콜렉션을 Hibernate가 자동적으로 검출해낸다. 이것은 + <emphasis>자동적인 dirty 체킹</emphasis>이라 불려지며, 당신은 또한 당신의 임의의 객체들에 대한 name 또는 date + 프로퍼티를 변경함으로써 그것을 시도할 수 있다. 그것들이 <emphasis>영속(persistent)</emphasis> 상태에 있는 동안, 즉 특정 Hibernate + <literal>Session</literal>에 바인드되어 있는 동안(예를 들면. 그것들은 작업 단위 속에 방금 로드되었거나 저장되었다), + Hibernate는 임의의 변경들을 모니터링하고 쓰기 이면의 형태로 SQL을 실행시킨다. 메모리 상태를 데이터베이스와 동기화 시키는 + 과정은 대개 오직 작업 단위의 끝에서이고, <emphasis>flushing</emphasis>이라 명명된다. 우리의 코드에서, 작업 단위는 + <literal>CurrentSessionContext</literal> 클래스에 대한 <literal>thread</literal> 구성 옵션에 의해 정의된 + 대로 - 데이터베이스 트랜잭션의 커밋(또는 롤백)으로 끝이난다. + </para> + + <para> + 물론 당신은 다른 작업 단위 속에 개인과 이벤트를 로드시킬 수 도 있다. 또는 당신은 하나의 객체그 영속 상태에 있지 않을 때 + <literal>Session</literal>의 외부에서 객체를 변경시킬 수도 있다(만일 객체가 이전에 영속화 되었다면, 우리는 이 상태를 + <emphasis>detached</emphasis>라고 부른다). (매우 사실적이지 않은) 코드 내에서 이것은 다음과 같을 수 있다: + </para> + + <programlisting><![CDATA[private void addPersonToEvent(Long personId, Long eventId) { + + Session session = HibernateUtil.getSessionFactory().getCurrentSession(); + session.beginTransaction(); + + Person aPerson = (Person) session + .createQuery("select p from Person p left join fetch p.events where p.id = :pid") + .setParameter("pid", personId) + .uniqueResult(); // Eager fetch the collection so we can use it detached + + Event anEvent = (Event) session.load(Event.class, eventId); + + session.getTransaction().commit(); + + // End of first unit of work + + aPerson.getEvents().add(anEvent); // aPerson (and its collection) is detached + + // Begin second unit of work + + Session session2 = HibernateUtil.getSessionFactory().getCurrentSession(); + session2.beginTransaction(); + + session2.update(aPerson); // Reattachment of aPerson + + session2.getTransaction().commit(); +}]]></programlisting> + + <para> + <literal>update</literal>에 대한 호출은 한 개의 detached 객체를 다시 영속화 시키고, 당신은 그것이 새로운 작업 단위에 + 바인드된다고 말할 수 있고, 따라서 detached 동안에 당신이 그것에 대해 행한 임의의 변경들이 데이터베이스에 저장될 수 있다. + 이것은 당신이 그 엔티티 객체의 콜렉션에 대해 행했던 임의의 변경들(추가/삭제)를 포함한다. + </para> + + <para> + 물론, 우리의 현재 상황에서 이것은 많이 사용되지 않지만, 그것은 당신이 당신 자신의 어플리케이션 내로 설계할 수 있는 중요한 + 개념이다. 지금 <literal>EventManager</literal>의 main 메소드에 한 개의 새로운 액션을 추가하고 명령 라인에서 그것을 + 호출하여 이 연습을 완료하라. 만일 당신이 한명의 개인과 한 개의 이벤트에 대한 식별자들을 필요로 할 경우 - <literal>save()</literal> + 메소드가 그것을 반환시킨다(당신은 그 식별자를 반환시키는 앞의 메소드들 중 몇몇을 변경시켜야 할 것이다): + </para> + + <programlisting><![CDATA[else if (args[0].equals("addpersontoevent")) { + Long eventId = mgr.createAndStoreEvent("My Event", new Date()); + Long personId = mgr.createAndStorePerson("Foo", "Bar"); + mgr.addPersonToEvent(personId, eventId); + System.out.println("Added person " + personId + " to event " + eventId); +}]]></programlisting> + + <para> + 이것은 두 개의 동등하게 중요한 클래스들, 두 개의 엔티티들 사이에서 한 개의 연관에 관한 예제였다. 앞서 언급했듯이, 전형적인 모형 내에는 + 다른 클래스들과 타이들이 존재하는데, 대개 "덜 중요하다". 당신은 이미 <literal>int</literal> 또는 <literal>String</literal>과 + 같은 어떤 것을 이미 보았다. 우리는 이들 클래스들을 <emphasis>값 타입들(value types)</emphasis>이라 명명하고, 그들 인스턴스들은 + 특정 엔티티에 <emphasis>의존한다(depend)</emphasis>. 이들 타입들을 가진 인스턴스들은 그것들 자신의 식별성(identity)를 갖지 않거나, + 그것들은 엔티티들 사이에서 공유되지도 않는다(두개의 person들은 심지어 그것들이 같은 첫 번째 이름을 갖는 경우에도 동일한 <literal>firstname</literal>을 + 참조하지 않는다 ). 물론 값 타입들은 JDK 내에서 발견될 뿐만 아니라(사실, Hibernate 어플리케이션에서 모든 JDK 클래스들은 값 타입들로 간주된다), + 당신은 또한 당신 스스로 종속 클래스들, 예를 들면 <literal>Address</literal> 또는 <literal>MonetaryAmount</literal>을 작성할 수 있다. + </para> + + <para> + 당신은 또한 값 타입들을 설계할 수 있다. 이것은 다른 엔티티들에 대한 참조들을 가진 콜렉션과는 개념적으로 매우 다르지만, + Java에서는 대개 동일한 것으로 보여진다. + </para> + + </sect2> + + <sect2 id="tutorial-associations-valuecollections"> + <title>값들을 가진 콜렉션</title> + + <para> + 우리는 값 타입의 객체들을 가진 한 개의 콜렉션을 <literal>Person</literal> 엔티티에 추가시킨다. 우리는 email 주소를 + 저장하고자 원하므로, 우리가 사용하는 타입은 <literal>String</literal>이고, 그 콜렉션은 다시 한 개의 <literal>Set</literal>이다: + </para> + <programlisting><![CDATA[private Set emailAddresses = new HashSet(); + +public Set getEmailAddresses() { + return emailAddresses; +} + +public void setEmailAddresses(Set emailAddresses) { + this.emailAddresses = emailAddresses; +}]]></programlisting> + + <para> + 이 <literal>Set</literal>에 대한 매핑은 다음과 같다: + </para> + + <programlisting><![CDATA[<set name="emailAddresses" table="PERSON_EMAIL_ADDR"> + <key column="PERSON_ID"/> + <element type="string" column="EMAIL_ADDR"/> +</set>]]></programlisting> + + <para> + 앞의 매핑과 비교한 차이점은 <literal>element</literal> 부분인데, 그것은 그 콜렉션이 또 다른 엔티티에 대한 + 참조들을 포함하지 않을 것이지만 <literal>String</literal>(소문자 이름은 그것이 Hibernate 매핑 타입/변환자임을 + 당신에게 말해준다) 타입의 요소들을 가진 한 개의 콜렉션을 포함할 것임을 Hibernate에게 알려준다. 일단 다시 <literal>set</literal> + 요소의 <literal>table</literal> 속성은 그 콜렉션에 대한 테이블 이름을 결정한다. <literal>key</literal> 요소는 + 콜렉션 테이블 내에서 foreign-key 컬럼 이름을 정의한다. <literal>element</literal> 요소 내에 있는 <literal>column</literal> + 속성은 <literal>String</literal> 값들이 실제로 저장될 컬럼 이름을 정의한다. + </para> + + <para> + 업데이트된 스키마를 살펴보라: + </para> + + <programlisting><![CDATA[ + _____________ __________________ + | | | | _____________ + | EVENTS | | PERSON_EVENT | | | ___________________ + |_____________| |__________________| | PERSON | | | + | | | | |_____________| | PERSON_EMAIL_ADDR | + | *EVENT_ID | <--> | *EVENT_ID | | | |___________________| + | EVENT_DATE | | *PERSON_ID | <--> | *PERSON_ID | <--> | *PERSON_ID | + | TITLE | |__________________| | AGE | | *EMAIL_ADDR | + |_____________| | FIRSTNAME | |___________________| + | LASTNAME | + |_____________| + ]]></programlisting> + + <para> + 당신은 콜렉션 테이블의 프라이머리 키가 사실은 두 컬럼들을 사용하는 한 개의 합성 키(composite key)임을 알 수 있다. + 이것은 또한 개인에 대해 email 주소가 중복될 수 없음을 의미하며, 그것은 정확하게 우리가 Java에서 set을 필요로 하는 + 의미론이다. + </para> + + <para> + 마치 개인들과 이벤트들을 링크시켜서 이전에 우리가 행했던 것처럼 이제 당신은 요소들을 시도하고 이 콜렉션에 추가할 수 있다. + 그것은 Java에서 동일한 코드이다. + </para> + + <programlisting><![CDATA[private void addEmailToPerson(Long personId, String emailAddress) { + + Session session = HibernateUtil.getSessionFactory().getCurrentSession(); + session.beginTransaction(); + + Person aPerson = (Person) session.load(Person.class, personId); + + // The getEmailAddresses() might trigger a lazy load of the collection + aPerson.getEmailAddresses().add(emailAddress); + + session.getTransaction().commit(); +}]]></programlisting> + + <para> + 지금 우리는 콜렉션을 초기화 시키는데 <emphasis>fetch</emphasis> 질의를 사용하지 않았다. + 그러므로 콜렉션의 getter 메소드에 대한 호출은 콜렉션을 초기화 시키기 위해 추가적인 select를 트리거 시킬 + 것이어서, 우리는 그것에 요소를 추가시킬 수 있다. SQL 로그를 관찰하고 이것을 eager fetch로 최적화 시키려고 + 시도하라. + </para> + + </sect2> + + <sect2 id="tutorial-associations-bidirectional" revision="1"> + <title>Bi-directional associations</title> + + <para> + 다음으로 우리는 양방향 연관을 매핑시킬 예정이다-개인과 이벤트 사이에 연관을 만드는 것은 Java에서 양 측들에서 동작한다. + 물론 데이터베이스 스키마는 변경되지 않고, 우리는 여전히 many-to-many 다중성을 갖는다. 관계형 데이터베이스는 + 네트웍 프로그래밍 언어 보다 훨씬 더 유연하여서, 그것은 네비게이션 방향과 같은 어떤 것을 필요로 하지 않는다 - 데이터는 + 어떤 가능한 바업ㅂ으로 보여질 수 있고 검색될 수 있다. + </para> + + <para> + 먼저, 참여자들을 가진 한 개의 콜렉션을 <literal>Event</literal> Event 클래스에 추가시켜라: + </para> + + <programlisting><![CDATA[private Set participants = new HashSet(); + +public Set getParticipants() { + return participants; +} + +public void setParticipants(Set participants) { + this.participants = participants; +}]]></programlisting> + + <para> + 이제 <literal>Event.hbm.xml</literal> 내에 연관의 이 쪽도 매핑하라. + </para> + + <programlisting><![CDATA[<set name="participants" table="PERSON_EVENT" inverse="true"> + <key column="EVENT_ID"/> + <many-to-many column="PERSON_ID" class="events.Person"/> +</set>]]></programlisting> + + <para> + 당신이 볼 수 있듯이, 이것들은 두 매핑 문서들 내에서 정규 <literal>set</literal> 매핑들이다. <literal>key</literal>와 + <literal>many-to-many</literal>에서 컬럼 이름들은 두 매핑 문서들에서 바뀌어진다. 여기서 가장 중요한 부가물은 + <literal>Event</literal>의 콜렉션 매핑에 관한 <literal>set</literal> 요소 내에 있는 <literal>inverse="true"</literal> + 속성이다. + </para> + + <para> + 이것이 의미하는 바는 Hibernate가 둘 사이의 링크에 대한 정보를 알 필요가 있을 때 다른 측-<literal>Person</literal> 클래스-를 취할 + 것이라는 점이다. 일단 당신이 우리의 두 엔티티들 사이에 양방향 링크가 생성되는 방법을 안다면 이것은 이해하기가 훨씬 더 쉬울 것이다. + </para> + + </sect2> + + <sect2 id="tutorial-associations-usingbidir"> + <title>양방향 링크들에 작업하기</title> + + <para> + 첫 번째로 Hibernate가 정규 Java 의미론에 영향을 주지 않음을 염두에 두라. 우리는 단방향 예제에서 <literal>Person</literal>과 + <literal>Event</literal> 사이에 어떻게 한 개의 링크를 생성시켰는가? 우리는 <literal>Event</literal> 타입의 인스턴스를 + <literal>Person</literal> 타입의 이벤트 참조들을 가진 콜렉션에 추가시켰다. 따라서 명백하게 우리가 이 링크를 양방향으로 + 동작하도록 만들고자 원한다면, 우리는 다른 측 상에서 -하나의 <literal>Person</literal> 참조를 하나의 <literal>Event</literal> + 내에 있는 콜렉션에 추가시킴으로써- 동일한 것을 행해야 한다. 이 "양 측 상에 링크 설정하기"는 절대적으로 필수적이고 당신은 그것을 행하는 + 것을 결코 잊지 말아야 한다. + </para> + + <para> + 많은 개발자들은 방비책을 프로그램하고 양 측들을 정확하게 설정하기 위한 하나의 링크 관리 메소드들을 생성시킨다. 예를 들면 <literal>Person</literal>에서 : + </para> + + <programlisting><![CDATA[protected Set getEvents() { + return events; +} + +protected void setEvents(Set events) { + this.events = events; +} + +public void addToEvent(Event event) { + this.getEvents().add(event); + event.getParticipants().add(this); +} + +public void removeFromEvent(Event event) { + this.getEvents().remove(event); + event.getParticipants().remove(this); +}]]></programlisting> + + <para> + 콜렉션에 대한 get 및 set 메소드드은 이제 protected임을 인지하라 - 이것은 동일한 패키지 내에 있는 클래스들과 서브클래스들이 + 그 메소드들에 접근하는 것을 허용해주지만, 그 밖의 모든 것들이 그 콜렉션들을 (물론, 대개) 직접 만지는 것을 금지시킨다. 당신은 + 다른 측 상에 있는 콜렉션에 대해 동일한 것을 행할 것이다. + </para> + + <para> + <literal>inverse</literal> 매핑 속성은 무엇인가? 당신의 경우, 그리고 Java의 경우, 한 개의 양방향 링크는 단순히 양 측들에 대한 + 참조들을 정확하게 설정하는 문제이다. 하지만 Hibernate는 (컨스트레인트 위배를 피하기 위해서) SQL <literal>INSERT</literal> 문장과 + <literal>UPDATE</literal> 문장을 정확하게 마련하기에 충분한 정보를 갖고 있지 않으며, 양방향 연관들을 올바르게 처리하기 위해 + 어떤 도움을 필요로 한다. 연관의 한 측을 <literal>inverse</literal>로 만드는 것은 기본적으로 그것을 무시하고 그것을 다른 측의 + <emphasis>거울(mirror)</emphasis>로 간주하도록 Hibernate에게 알려준다. 그것은 Hibernate가 하나의 방향성 네비게이션 모형을 + 한 개의 SQL 스키마로 변환시킬 때 모든 쟁점들을 잘 해결하는데 필수적인 모든 것이다. 당신이 염두에 두어야 하는 규칙들은 간단하다 : + 모든 양방향 연관들은 한 쪽이 <literal>inverse</literal>일 필요가 있다. one-to-many 연관에서 그것은 many-측이어야 하고, + many-to-many 연관에서 당신은 어느 측이든 선택할 수 있으며 차이점은 없다. + </para> + + </sect2> + + <para> + Let's turn this into a small web application. + </para> + + </sect1> + + <sect1 id="tutorial-webapp"> + <title>파트 3 - EventManager 웹 어플리케이션</title> + + <para> + Hibernate 웹 어플리케이션은 대부분의 스탠드얼론 어플리케이션과 같이 <literal>Session</literal>과 + <literal>Transaction</literal>을 사용한다. 하지만 몇몇 공통 패턴들이 유용하다. 우리는 이제 + <literal>EventManagerServlet</literal>를 작성한다. 이 서블릿은 데이터베이스 내에 저장된 모든 이벤트들을 나열할 수 있고, + 그것은 새로운 이벤트들을 입력하기 위한 HTML form을 제공한다. + </para> + + <sect2 id="tutorial-webapp-servlet" revision="2"> + <title>기본 서블릿 작성하기</title> + + <para> + 다음 장에서 우리는 Hibernate를 Tomcat 및 WebWork와 통합시킨다. <literal>EventManager</literal>는 우리의 성장하는 + 어플리케이션을 더이상 감당하지 못한다. + 당신의 소스 디렉토리에서 <literal>events</literal> 패키지 내에 새로운 클래스를 생성시켜라: + </para> + + <programlisting><![CDATA[package events; + +// Imports + +public class EventManagerServlet extends HttpServlet { + + // Servlet code +}]]></programlisting> + + <para> + 서블릿은 HTTP <literal>GET</literal> 요청들 만을 처리하므로, 우리가 구현하는 메소드는 <literal>doGet()</literal>이다: + </para> + + <programlisting><![CDATA[protected void doGet(HttpServletRequest request, + HttpServletResponse response) + throws ServletException, IOException { + + SimpleDateFormat dateFormatter = new SimpleDateFormat("dd.MM.yyyy"); + + try { + // Begin unit of work + HibernateUtil.getSessionFactory() + .getCurrentSession().beginTransaction(); + + // Process request and render page... + + // End unit of work + HibernateUtil.getSessionFactory() + .getCurrentSession().getTransaction().commit(); + + } catch (Exception ex) { + HibernateUtil.getSessionFactory() + .getCurrentSession().getTransaction().rollback(); + throw new ServletException(ex); + } + +}]]></programlisting> + + <para> + 우리가 여기서 적용하는 패턴은 <emphasis>session-per-request</emphasis>이다. 하나의 요청이 + 서블릿에 도달할 때, 하나의 새로운 Hibernate <literal>Session</literal>이 + <literal>SessionFactory</literal> 상의 <literal>getCurrentSession()</literal>에 대한 + 첫번째 호출을 통해 열린다. 그때 하나의 데이터베이스 트랜잭션이 시작되고, 모든 데이터 접근이 하나의 트랜잭션 + 내에서 발생하는 한, 데이터가 읽혀지거나 기록되는데 문제가 없다(우리는 어플리케이션들 내에서 auto-commit 모드를 + 사용하지 않는다). + </para> + + <para> + 모든 데이터베이스 오퍼레이션 각각에 대해 새로운 Hibernate <literal>Session</literal>을 사용하지 <emphasis>말라</emphasis>. + 전체 요청에 대해 영역지워진 한 개의 Hibernate <literal>Session</literal>을 사용하라. 그것이 자동적으로 현재의 자바 쓰레드에 바인드되도록 + <literal>getCurrentSession()</literal>을 사용하라. + </para> + + <para> + 다음으로, 요청의 가능한 액션들이 처리되고 응답 HTML이 렌더링된다. 우리는 곧장 그부분으로 갈 것이다. + </para> + + <para> + 마지막으로, 프로세싱과 렌더링이 완료될 때 작업 단위가 종료된다. 만일 어떤 문제가 프로세싱과 렌더링 동안에 발생될 경우, + 하나의 예외상황이 던져질 것이고 데이터베이스 트랜잭션은 롤백될 것이다. 이것은 <literal>session-per-request</literal>을 + 완료시킨다. 모든 서블릿 내에 있는 트랜잭션 구획 코드 대신에 당신은 또한 서블릿 필터를 사용할 수 있다. + <emphasis>Open Session in View</emphasis>로 명명되는 이 패턴에 대한 추가 정보는 Hibernate 웹 사이트와 위키를 보라. + 당신은 서블릿 내에서가 아닌 JSP 내에 당신의 뷰를 렌더링하는 것을 고려할 때 그것을 필요로 할 것이다. + </para> + + </sect2> + + <sect2 id="tutorial-webapp-processing" revision="1"> + <title>프로세싱과 렌더링</title> + + <para> + 요청의 처리와 페이지의 렌더링을 구현하자. + </para> + +<programlisting><![CDATA[// Write HTML header +PrintWriter out = response.getWriter(); +out.println("<html><head><title>Event Manager</title></head><body>"); + +// Handle actions +if ( "store".equals(request.getParameter("action")) ) { + + String eventTitle = request.getParameter("eventTitle"); + String eventDate = request.getParameter("eventDate"); + + if ( "".equals(eventTitle) || "".equals(eventDate) ) { + out.println("<b><i>Please enter event title and date.</i></b>"); + } else { + createAndStoreEvent(eventTitle, dateFormatter.parse(eventDate)); + out.println("<b><i>Added event.</i></b>"); + } +} + +// Print page +printEventForm(out); +listEvents(out, dateFormatter); + +// Write HTML footer +out.println("</body></html>"); +out.flush(); +out.close();]]></programlisting> + + <para> + Java와 HTML이 혼합된 이 코딩이 보다 복잡한 어플리케이션에서 기준이 될 수 없다 할지라도, 우리는 + 단지 이 튜토리얼 내에서 기본 Hibernate 개념들을 설명하고 있음을 염두에 두라. 코드는 + 하나의 HTML 헤더와 하나의 footer를 프린트한다. 이 페이지 내에 이벤트 엔트리를 위한 + 하나의 HTML form과 데이터베이스 내에 있는 모든 이벤트들의 목록이 프린트된다. 첫 번째 메소드는 + 시행적이고 오직 HTML을 출력한다: + </para> + + <programlisting><![CDATA[private void printEventForm(PrintWriter out) { + out.println("<h2>Add new event:</h2>"); + out.println("<form>"); + out.println("Title: <input name='eventTitle' length='50'/><br/>"); + out.println("Date (e.g. 24.12.2009): <input name='eventDate' length='10'/><br/>"); + out.println("<input type='submit' name='action' value='store'/>"); + out.println("</form>"); +}]]></programlisting> + + <para> + <literal>listEvents()</literal> 메소드는 하나의 질의를 실행하기 위해서 현재의 + 쓰레드에 결합된 Hibernate <literal>Session</literal>을 사용한다: + </para> + + <programlisting><![CDATA[private void listEvents(PrintWriter out, SimpleDateFormat dateFormatter) { + + List result = HibernateUtil.getSessionFactory() + .getCurrentSession().createCriteria(Event.class).list(); + if (result.size() > 0) { + out.println("<h2>Events in database:</h2>"); + out.println("<table border='1'>"); + out.println("<tr>"); + out.println("<th>Event title</th>"); + out.println("<th>Event date</th>"); + out.println("</tr>"); + for (Iterator it = result.iterator(); it.hasNext();) { + Event event = (Event) it.next(); + out.println("<tr>"); + out.println("<td>" + event.getTitle() + "</td>"); + out.println("<td>" + dateFormatter.format(event.getDate()) + "</td>"); + out.println("</tr>"); + } + out.println("</table>"); + } +}]]></programlisting> + + <para> + 마지막으로, <literal>store</literal> 액션은 <literal>createAndStoreEvent()</literal> + 메소드로 디스패치된다. 그것은 현재 쓰레드의 <literal>Session</literal>을 사용한다: + </para> + + <programlisting><![CDATA[protected void createAndStoreEvent(String title, Date theDate) { + Event theEvent = new Event(); + theEvent.setTitle(title); + theEvent.setDate(theDate); + + HibernateUtil.getSessionFactory() + .getCurrentSession().save(theEvent); +}]]></programlisting> + + <para> + 즉 서블릿이 완성된다. 서블릿에 대한 요청은 하나의 단일 <literal>Session</literal>과 + <literal>Transaction</literal> 내에서 처리될 것이다. 이전처럼 스탠드얼론 어플리케이션에서, + Hibernate는 이들 객체들을 실행 중인 현재 쓰레드에 자동적으로 바인드시킬 수 있다. 이것은 당신의 코드를 + 계층화 시키고 당신이 좋아하는 임의의 방법으로 <literal>SessionFactory</literal>에 접근하는 자유를 + 당신에게 부여한다. 대개 당신은 보다 세련된 설계를 사용할 것이고 데이터 접근 코드를 데이터 접근 객체들 내로 + 이동시킬 것이다(DAO 패턴). 추가 예제들은 Hibernate 위키를 보라. + </para> + + </sect2> + + <sect2 id="tutorial-webapp-deploy"> + <title>배치하기 그리고 테스트하기</title> + + <para> + 이 어플리케이션을 배치하기 위해서 당신은 하나의 웹 아카이브, WAR를 생성시켜야 한다. 다음 Ant target을 + 당신의 <literal>build.xml</literal> 내에 추가하라: + </para> + +<programlisting><![CDATA[<target name="war" depends="compile"> + <war destfile="hibernate-tutorial.war" webxml="web.xml"> + <lib dir="${librarydir}"> + <exclude name="jsdk*.jar"/> + </lib> + + <classes dir="${targetdir}"/> + </war> +</target>]]></programlisting> + + <para> + 이 target은 당신의 프로젝트 디렉토리 내에 <literal>hibernate-tutorial.war</literal>로 명명된 + 하나의 파일을 생성시킨다. 그것은 당신의 프로젝트의 기본 디렉토리 내에 기대되는 모든 라이브러리들과 + <literal>web.xml</literal> 디스크립터를 패키징한다: + </para> + + <programlisting><![CDATA[<?xml version="1.0" encoding="UTF-8"?> +<web-app version="2.4" + xmlns="http://java.sun.com/xml/ns/j2ee" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> + + <servlet> + <servlet-name>Event Manager</servlet-name> + <servlet-class>events.EventManagerServlet</servlet-class> + </servlet> + + <servlet-mapping> + <servlet-name>Event Manager</servlet-name> + <url-pattern>/eventmanager</url-pattern> + </servlet-mapping> +</web-app>]]></programlisting> + + <para> + 당신이 웹 어플리케이션을 컴파일하고 배치하기 전에, 하나의 부가적인 라이브러리가 필요함을 노트하라: + <literal>jsdk.jar</literal>. 당신이 이미 이 라이브러리를 갖고 있지 않을 경우, 이것은 Java servlet + development kit이며, Sun 웹 사이트로부터 그것을 얻어서 그것을 당신의 라이브러리 디렉토리에 복사하라. + 하지만 그것은 오직 컴파일 시에만 사용될 것이고 WAR 패키지에서는 제외된다. + </para> + + <para> + 빌드하고 배치하기 위해 당신의 프로젝트 디렉토리 내에서 <literal>ant war</literal>를 호출하고 + <literal>hibernate-tutorial.war</literal> 파일을 당신의 Tomcat <literal>webapp</literal> + 디렉토리로 복사하라. 만일 당신이 Tomcat을 설치하지 않았다면, 그것을 내려받아 설치 지침들을 따르라. 당신은 + 이 어플리케이션을 배치하기 위해 임의의 Tomcat 구성을 변경하지 않아야 한다. + </para> + + <para> + 일단 배치했고 Tomcat이 실행중이면, <literal>http://localhost:8080/hibernate-tutorial/eventmanager</literal>로 + 어플리케이션에 접근하라. 첫 번째 요청이 당신의 서블릿에 도달할 때 Hibernate가 초기화(<literal>HibernateUtil</literal> + 내에 있는 static initializer가 호출된다) 되는 것을 보기 위해 그리고 만일 어떤 예외상황들이 발생할 경우 + 상세한 출력을 얻기 위해서 Tomcat 로그를 지켜보도록 하라. + </para> + + </sect2> + </sect1> + + <sect1 id="tutorial-summary" revision="1"> + <title>요약</title> + + <para> + 이 튜토리얼은 간단한 스탠드얼론 Hibernate 어플리케이션과 하나의 작은 웹 어플리케이션을 작성하는 기초를 다루었다. + </para> + + <para> + 만일 당신이 이미 Hibernate에 자신이 있다고 느낀다면, 당신이 흥미를 찾는 주제들에 대한 참조 문서 목차를 계속 브라우징하라 + - 가장 많이 요청되는 것은 트랜잭션 처리(<xref linkend="transactions"/>), 페치 퍼포먼스(<xref linkend="performance"/>), + 또는 API 사용법(<xref linkend="objectstate"/>), 그리고 질의 특징들(<xref linkend="objectstate-querying"/>)이다. + </para> + + <para> + 더 많은(특화된) 튜토리얼들에 대해서는 Hibernate 웹 사이트를 체크하는 것을 잊지 말라. + </para> + + </sect1> + +</chapter> \ No newline at end of file Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/content/xml.xml (from rev 14078, core/trunk/documentation/manual/ko-KR/src/main/docbook/modules/xml.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/content/xml.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/content/xml.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,273 @@ +<chapter id="xml"> + <title>XML 매핑</title> + + <para><emphasis> + 이것은 Hibernate3.0에서 실험적인 특징이고 매우 활동적으로 개발 중에 있음을 노트하라. + </emphasis></para> + + <sect1 id="xml-intro" revision="1"> + <title>XML 데이터로 작업하기</title> + + <para> + Hibernate는 당신이 영속 POJO들로 작업하는 것과 아주 동일한 방법으로 영속 XML 데이터에 작업하도록 해준다. 파싱된 XML 트리는 + 단지 객체 레벨에서 관계형 데이터를 나타내는 또 다른 방법으로 간주될 수 있다. 하나의 파싱된 XML 트리는 POJO들 대신, 객체 레벨에서 + 관계형 데이터를 표현하는 단지 또 다른 방법으로 간주될 수 있다. + </para> + + <para> + Hibernate는 XML 트리들을 처리하는 API로서 dom4j를 지원한다. 당신은 데이터베이스로부터 dom4j 트리들을 검색하고 당신이 그 트리를 + 데이터베이스와 자동적으로 동기화시키기 위해 어떤 변경을 행하도록 하는 질의들을 작성할 수 있다. 당신은 심지어 XML 문서를 취하고, + dom4j를 사용하여 그것을 파싱하고, Hibernate의 다음 기본적인 오퍼레이션들 중 어떤 것으로서 그것을 데이터베이스에 저장시킬 수 있다: + <literal>persist(), saveOrUpdate(), merge(), delete(), replicate()</literal>(merging(병합)은 아직 지원되지 + 않는다). + </para> + + <para> + 이 특징은 데이터 가져오기/내보내기,JMS 또는 SOAP 그리고 XSLT-기반의 레포팅을 통한 엔티티 데이터의 구체화를 포함하는 많은 + 어플리케이션들을 갖는다. + </para> + + <para> + 하나의 매핑은 클래스들의 프로퍼티들과 XML 문서의 노드들을 데이터베이스로 동시에 매핑시키는데 사용될 수 있거나, 만일 매핑할 클래스가 + 존재하지 않을 경우, 그것은 단지 XML을 매핑시키는데 사용될 수도 있다. + </para> + + <sect2 id="xml-intro-mapping"> + <title>XML과 클래스 매핑을 함께 지정하기</title> + + <para> + 다음은 POJO와 XML을 동시에 매핑시키는 예제이다 : + </para> + + <programlisting><![CDATA[<class name="Account" + table="ACCOUNTS" + node="account"> + + <id name="accountId" + column="ACCOUNT_ID" + node="@id"/> + + <many-to-one name="customer" + column="CUSTOMER_ID" + node="customer/@id" + embed-xml="false"/> + + <property name="balance" + column="BALANCE" + node="balance"/> + + ... + +</class>]]></programlisting> + </sect2> + + <sect2 id="xml-onlyxml"> + <title>XML 매핑만을 지정하기</title> + + <para> + 다음은 POJO 클래스가 존재하지 않는 예제이다: + </para> + + <programlisting><![CDATA[<class entity-name="Account" + table="ACCOUNTS" + node="account"> + + <id name="id" + column="ACCOUNT_ID" + node="@id" + type="string"/> + + <many-to-one name="customerId" + column="CUSTOMER_ID" + node="customer/@id" + embed-xml="false" + entity-name="Customer"/> + + <property name="balance" + column="BALANCE" + node="balance" + type="big_decimal"/> + + ... + +</class>]]></programlisting> + + <para> + 이 매핑은 dom4j 트리로서 또는 프로퍼티 name/value 쌍들(java <literal>Map</literal>들)의 그래프로서 데이터에 + 접근하는 것을 당신에게 허용해준다. 프로퍼티 이름들은 HQL 질의들 내에서 참조될 수도 있는 순수하게 논리적인 구조체들이다. + </para> + + </sect2> + + </sect1> + + <sect1 id="xml-mapping" revision="1"> + <title>XML 매핑 메타데이터</title> + + <para> + 많은 Hibernate 매핑 요소들은 <literal>node</literal> 속성을 수용한다. 이것은 당신이 프로퍼티 또는 엔티티 데이터를 소유하는 + XML 속성이나 요소의 이름을 지정하도록 한다. <literal>node</literal> 속성의 포맷은 다음 중 하나이어야 한다: + </para> + + <itemizedlist spacing="compact"> + <listitem> + <para><literal>"element-name"</literal> - 명명된 XML 요소로 매핑시킨다</para> + </listitem> + <listitem> + <para><literal>"@attribute-name"</literal> - 명명된 XML 속성으로 매핑시킨다 </para> + </listitem> + <listitem> + <para><literal>"."</literal> - 부모 요소로 매핑 시킨다</para> + </listitem> + <listitem> + <para> + <literal>"element-name/@attribute-name"</literal> - + 명명된 요소의 명명된 속성으로 매핑시킨다 + </para> + </listitem> + </itemizedlist> + + <para> + 콜렉션들과 단일 값 콜렉션들의 경우, 추가적인 <literal>embed-xml</literal> 속성이 존재한다. 만일 <literal>embed-xml="true"</literal> + 일 경우, 연관된 엔티티(또는 value 타입을 가진 콜렉션)에 대한 디폴트 XML 트리는 그 연관을 소유하는 엔티티에 대한 XML 트리 속에 + 직접 삽입될 것이다. 그 밖의 경우 <literal>embed-xml="false"</literal> 일 경우, 참조된 식별자 값 만이 단일 포인트 연관들에 + 대해 나타날 것이고 콜렉션들은 단순히 전혀 나타나지 않을 것이다. + </para> + + <para> + 당신은 너무 많은 연관들에 대해 <literal>embed-xml="true"</literal>로 남겨두지 말도록 주의해야 한다. 왜냐하면 XML이 + 순환적으로 잘 처리하지 못하기 때문이다! + </para> + + <programlisting><![CDATA[<class name="Customer" + table="CUSTOMER" + node="customer"> + + <id name="id" + column="CUST_ID" + node="@id"/> + + <map name="accounts" + node="." + embed-xml="true"> + <key column="CUSTOMER_ID" + not-null="true"/> + <map-key column="SHORT_DESC" + node="@short-desc" + type="string"/> + <one-to-many entity-name="Account" + embed-xml="false" + node="account"/> + </map> + + <component name="name" + node="name"> + <property name="firstName" + node="first-name"/> + <property name="initial" + node="initial"/> + <property name="lastName" + node="last-name"/> + </component> + + ... + +</class>]]></programlisting> + + <para> + 이 경우에, 우리는 실제 account 데이터가 아닌, account id들을 가진 콜렉션을 삽입시키기로 결정했다. 다음 HQL 질의: + </para> + + <programlisting><![CDATA[from Customer c left join fetch c.accounts where c.lastName like :lastName]]></programlisting> + + <para> + 는 다음과 같은 데이터셋들을 반환할 것이다: + </para> + + <programlisting><![CDATA[<customer id="123456789"> + <account short-desc="Savings">987632567</account> + <account short-desc="Credit Card">985612323</account> + <name> + <first-name>Gavin</first-name> + <initial>A</initial> + <last-name>King</last-name> + </name> + ... +</customer>]]></programlisting> + + <para> + 만일 당신이 <literal>&lt;one-to-many&gt;</literal> 매핑에 대해 <literal>embed-xml="true"</literal>를 설정할 경우, + 데이터는 다음과 같이 보일 수도 있다: + </para> + + <programlisting><![CDATA[<customer id="123456789"> + <account id="987632567" short-desc="Savings"> + <customer id="123456789"/> + <balance>100.29</balance> + </account> + <account id="985612323" short-desc="Credit Card"> + <customer id="123456789"/> + <balance>-2370.34</balance> + </account> + <name> + <first-name>Gavin</first-name> + <initial>A</initial> + <last-name>King</last-name> + </name> + ... +</customer>]]></programlisting> + + </sect1> + + + <sect1 id="xml-manipulation" revision="1"> + <title>XML 데이터 처리하기</title> + + <para> + 우리의 어플리케이션 내에서 XML 문서들을 다시 읽어들이고 업데이트 시키자. 우리는 dom4j 세션을 얻어서 이것을 행한다: + </para> + + <programlisting><![CDATA[Document doc = ....; + +Session session = factory.openSession(); +Session dom4jSession = session.getSession(EntityMode.DOM4J); +Transaction tx = session.beginTransaction(); + +List results = dom4jSession + .createQuery("from Customer c left join fetch c.accounts where c.lastName like :lastName") + .list(); +for ( int i=0; i<results.size(); i++ ) { + //add the customer data to the XML document + Element customer = (Element) results.get(i); + doc.getRootElement().add(customer); +} + +tx.commit(); +session.close();]]></programlisting> + + <programlisting><![CDATA[Session session = factory.openSession(); +Session dom4jSession = session.getSession(EntityMode.DOM4J); +Transaction tx = session.beginTransaction(); + +Element cust = (Element) dom4jSession.get("Customer", customerId); +for ( int i=0; i<results.size(); i++ ) { + Element customer = (Element) results.get(i); + //change the customer name in the XML and database + Element name = customer.element("name"); + name.element("first-name").setText(firstName); + name.element("initial").setText(initial); + name.element("last-name").setText(lastName); +} + +tx.commit(); +session.close();]]></programlisting> + + <para> + XML 기반의 데이터 가져오기/내보내기를 구현하는데 이 특징과 Hibernate의 <literal>replicate()</literal> 오퍼레이션을 + 결합시키는 것이 매우 유용하다. + </para> + + </sect1> + +</chapter> + Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/images/AuthorWork.png (from rev 14073, core/trunk/documentation/manual/en-US/src/main/docbook/images/AuthorWork.png) =================================================================== (Binary files differ) Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/images/AuthorWork.zargo (from rev 14073, core/trunk/documentation/manual/en-US/src/main/docbook/images/AuthorWork.zargo) =================================================================== (Binary files differ) Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/images/CustomerOrderProduct.png (from rev 14073, core/trunk/documentation/manual/en-US/src/main/docbook/images/CustomerOrderProduct.png) =================================================================== (Binary files differ) Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/images/CustomerOrderProduct.zargo (from rev 14073, core/trunk/documentation/manual/en-US/src/main/docbook/images/CustomerOrderProduct.zargo) =================================================================== (Binary files differ) Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/images/EmployerEmployee.png (from rev 14073, core/trunk/documentation/manual/en-US/src/main/docbook/images/EmployerEmployee.png) =================================================================== (Binary files differ) Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/images/EmployerEmployee.zargo (from rev 14073, core/trunk/documentation/manual/en-US/src/main/docbook/images/EmployerEmployee.zargo) =================================================================== (Binary files differ) Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/images/full_cream.png (from rev 14073, core/trunk/documentation/manual/en-US/src/main/docbook/images/full_cream.png) =================================================================== (Binary files differ) Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/images/full_cream.svg (from rev 14073, core/trunk/documentation/manual/en-US/src/main/docbook/images/full_cream.svg) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/images/full_cream.svg (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/images/full_cream.svg 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,429 @@ +<?xml version="1.0" standalone="no"?> +<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" +"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd" +[ + <!ATTLIST svg + xmlns:xlink CDATA #FIXED "http://www.w3.org/1999/xlink"> +]> +<!-- Created with Sodipodi ("http://www.sodipodi.com/") --> +<svg + xmlns="http://www.w3.org/2000/svg" + xmlns:xlink="http://www.w3.org/1999/xlink" + width="354.331" + height="336.614" + id="svg1"> + <defs + id="defs3"> + <linearGradient + x1="0" + y1="0" + x2="1" + y2="0" + id="linearGradient127" + gradientUnits="objectBoundingBox" + spreadMethod="pad"> + <stop + style="stop-color:#000000;stop-opacity:1;" + offset="0" + id="stop128" /> + <stop + style="stop-color:#ffffff;stop-opacity:1;" + offset="1" + id="stop129" /> + </linearGradient> + <linearGradient + x1="0" + y1="0" + x2="1" + y2="0" + id="linearGradient130" + xlink:href="#linearGradient127" + gradientUnits="objectBoundingBox" + spreadMethod="pad" /> + <radialGradient + cx="0.5" + cy="0.5" + fx="0.5" + fy="0.5" + r="0.5" + id="radialGradient131" + xlink:href="#linearGradient127" + gradientUnits="objectBoundingBox" + spreadMethod="pad" /> + </defs> + <g + transform="matrix(0.823795,0,0,0.823795,0.120302,5.25349)" + style="font-size:12;" + id="g659"> + <rect + width="212.257" + height="57.2441" + x="17.9576" + y="100.132" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect137" /> + <rect + width="285.502" + height="118.523" + x="13.4238" + y="95.9309" + transform="matrix(0.743454,0,0,0.482981,6.46949,52.2178)" + style="fill:#d2d2d2;fill-rule:evenodd;stroke-width:1pt;" + id="rect132" /> + </g> + <rect + width="325.86" + height="63.6537" + x="17.4083" + y="15.194" + style="font-size:12;fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect136" /> + <rect + width="325.86" + height="63.6537" + x="13.6713" + y="12.4966" + style="font-size:12;fill:#d2d2d2;fill-rule:evenodd;stroke-width:1pt;" + id="rect126" /> + <g + transform="matrix(1.14345,0,0,0.729078,-1.67818,105.325)" + style="font-size:12;" + id="g164"> + <rect + width="285.502" + height="77.2688" + x="16.6979" + y="222.966" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect138" /> + <rect + width="285.502" + height="77.2688" + x="14.7335" + y="221.002" + transform="translate(-1.30962,-1.30992)" + style="fill:#d2d2d2;fill-rule:evenodd;stroke-width:1pt;" + id="rect133" /> + </g> + <text + x="170.824753" + y="58.402939" + transform="scale(0.823795,0.823795)" + style="font-size:18;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text183"> + <tspan + x="170.824997" + y="58.402901" + id="tspan360"> +Application</tspan> + </text> + <text + x="178.076340" + y="364.281433" + transform="scale(0.823795,0.823795)" + style="font-size:18;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text197"> + <tspan + x="178.076004" + y="364.281006" + id="tspan421"> +Database</tspan> + </text> + <text + x="68.605331" + y="138.524582" + transform="scale(0.823795,0.823795)" + style="font-size:16;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text216"> + <tspan + x="68.605301" + y="138.524994" + id="tspan384"> +SessionFactory</tspan> + </text> + <rect + width="67.0014" + height="101.35" + x="196.927" + y="89.2389" + style="font-size:12;fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect387" /> + <rect + width="67.0014" + height="101.35" + x="194.633" + y="86.4389" + style="font-size:12;fill:#d2d2d2;fill-rule:evenodd;stroke-width:1pt;" + id="rect388" /> + <text + x="249.108841" + y="173.885559" + transform="scale(0.823795,0.823795)" + style="font-size:16;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text389"> + <tspan + x="249.108994" + y="173.886002" + id="tspan392"> +Session</tspan> + </text> + <rect + width="73.0355" + height="101.35" + x="270.995" + y="90.0018" + style="font-size:12;fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect395" /> + <rect + width="73.0355" + height="101.35" + x="267.869" + y="87.2018" + style="font-size:12;fill:#d2d2d2;fill-rule:evenodd;stroke-width:1pt;" + id="rect396" /> + <text + x="328.593658" + y="174.715622" + transform="scale(0.823795,0.823795)" + style="font-size:16;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text397"> + <tspan + x="328.593994" + y="174.716003" + id="tspan563"> +Transaction</tspan> + </text> + <g + transform="matrix(0.29544,0,0,0.397877,9.70533,103.96)" + style="font-size:12;" + id="g565"> + <rect + width="285.502" + height="118.523" + x="16.6979" + y="99.2053" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect566" /> + <rect + width="285.502" + height="118.523" + x="13.4238" + y="95.9309" + style="fill:#d2d2d2;fill-rule:evenodd;stroke-width:1pt;" + id="rect567" /> + </g> + <text + x="25.592752" + y="204.497803" + transform="scale(0.823795,0.823795)" + style="font-size:10;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text568"> + <tspan + x="25.592800" + y="204.498001" + id="tspan662"> +TransactionFactory</tspan> + </text> + <g + transform="matrix(0.298082,0,0,0.397877,99.6898,103.96)" + style="font-size:12;" + id="g573"> + <rect + width="285.502" + height="118.523" + x="16.6979" + y="99.2053" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect574" /> + <rect + width="285.502" + height="118.523" + x="13.4238" + y="95.9309" + style="fill:#d2d2d2;fill-rule:evenodd;stroke-width:1pt;" + id="rect575" /> + </g> + <text + x="134.030670" + y="205.532791" + transform="scale(0.823795,0.823795)" + style="font-size:10;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text576"> + <tspan + x="134.031006" + y="205.533005" + id="tspan664"> +ConnectionProvider</tspan> + </text> + <g + transform="matrix(1.14345,0,0,0.729078,-1.67818,38.9539)" + style="font-size:12;" + id="g587"> + <rect + width="285.502" + height="77.2688" + x="16.6979" + y="222.966" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect588" /> + <rect + width="285.502" + height="77.2688" + x="14.7335" + y="221.002" + transform="translate(-1.30962,-1.30992)" + style="fill:#d2d2d2;fill-rule:evenodd;stroke-width:1pt;" + id="rect589" /> + </g> + <rect + width="90.951" + height="44.4829" + x="25.6196" + y="206.028" + style="font-size:12;fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect594" /> + <rect + width="90.951" + height="44.4829" + x="24.4229" + y="204.135" + style="font-size:12;fill:#b3b3b3;fill-rule:evenodd;stroke-width:1pt;" + id="rect595" /> + <text + x="85.575645" + y="282.300354" + transform="scale(0.823795,0.823795)" + style="font-size:18;font-weight:normal;stroke-width:1pt;font-family:Helvetica;text-anchor:middle;" + id="text596"> + <tspan + x="85.575600" + y="282.299988" + id="tspan607"> +JNDI</tspan> + </text> + <rect + width="90.951" + height="44.4829" + x="236.937" + y="206.791" + style="font-size:12;fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect610" /> + <rect + width="90.951" + height="44.4829" + x="235.741" + y="204.898" + style="font-size:12;fill:#b3b3b3;fill-rule:evenodd;stroke-width:1pt;" + id="rect611" /> + <text + x="342.093201" + y="283.226410" + transform="scale(0.823795,0.823795)" + style="font-size:18;font-weight:normal;stroke-width:1pt;font-family:Helvetica;text-anchor:middle;" + id="text612"> + <tspan + x="342.092987" + y="283.226013" + id="tspan621"> +JTA</tspan> + </text> + <rect + width="90.951" + height="44.4829" + x="130.134" + y="206.791" + style="font-size:12;fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect616" /> + <rect + width="90.951" + height="44.4829" + x="128.937" + y="204.898" + style="font-size:12;fill:#b3b3b3;fill-rule:evenodd;stroke-width:1pt;" + id="rect617" /> + <text + x="212.445343" + y="283.226410" + transform="scale(0.823795,0.823795)" + style="font-size:18;font-weight:normal;stroke-width:1pt;font-family:Helvetica;text-anchor:middle;" + id="text618"> + <tspan + x="212.445007" + y="283.226013" + id="tspan623"> +JDBC</tspan> + </text> + <g + transform="matrix(0.823795,0,0,0.823795,0.120302,6.19341)" + style="font-size:12;" + id="g637"> + <g + transform="matrix(0.499515,0,0,0.415467,-0.237339,5.61339)" + id="g167"> + <rect + width="199.065" + height="61.5532" + x="61.8805" + y="68.4288" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect134" /> + <rect + width="199.065" + height="61.5532" + x="59.2613" + y="65.8095" + style="fill:#e0e0e0;fill-rule:evenodd;stroke-width:1pt;" + id="rect135" /> + </g> + <text + x="33.749969" + y="50.589706" + style="font-size:11;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text188"> + <tspan + x="33.750000" + y="50.589699" + id="tspan635"> +Transient Objects</tspan> + </text> + </g> + <g + transform="matrix(0.823795,0,0,0.823795,0.120302,5.25349)" + style="font-size:12;" + id="g644"> + <g + transform="matrix(0.297486,0,0,0.516482,230.251,36.9178)" + id="g364"> + <rect + width="199.065" + height="61.5532" + x="61.8805" + y="68.4288" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect365" /> + <rect + width="199.065" + height="61.5532" + x="59.2613" + y="65.8095" + style="fill:#e0e0e0;fill-rule:evenodd;stroke-width:1pt;" + id="rect366" /> + </g> + <text + x="277.123230" + y="85.155571" + style="font-size:11;font-weight:normal;stroke-width:1pt;font-family:Helvetica;text-anchor:middle;" + id="text367"> + <tspan + x="277.122986" + y="85.155602" + id="tspan631"> +Persistent</tspan> + <tspan + x="277.122986" + y="96.155602" + id="tspan633"> +Objects</tspan> + </text> + </g> +</svg> Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/images/hibernate_logo_a.png (from rev 14073, core/trunk/documentation/manual/en-US/src/main/docbook/images/hibernate_logo_a.png) =================================================================== (Binary files differ) Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/images/lite.png (from rev 14073, core/trunk/documentation/manual/en-US/src/main/docbook/images/lite.png) =================================================================== (Binary files differ) Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/images/lite.svg (from rev 14073, core/trunk/documentation/manual/en-US/src/main/docbook/images/lite.svg) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/images/lite.svg (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/images/lite.svg 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,334 @@ +<?xml version="1.0" standalone="no"?> +<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" +"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd" +[ + <!ATTLIST svg + xmlns:xlink CDATA #FIXED "http://www.w3.org/1999/xlink"> +]> +<!-- Created with Sodipodi ("http://www.sodipodi.com/") --> +<svg + xmlns="http://www.w3.org/2000/svg" + xmlns:xlink="http://www.w3.org/1999/xlink" + width="318.898" + height="248.031" + id="svg1"> + <defs + id="defs3"> + <linearGradient + x1="0" + y1="0" + x2="1" + y2="0" + id="linearGradient127" + gradientUnits="objectBoundingBox" + spreadMethod="pad"> + <stop + style="stop-color:#000000;stop-opacity:1;" + offset="0" + id="stop128" /> + <stop + style="stop-color:#ffffff;stop-opacity:1;" + offset="1" + id="stop129" /> + </linearGradient> + <linearGradient + x1="0" + y1="0" + x2="1" + y2="0" + id="linearGradient130" + xlink:href="#linearGradient127" + gradientUnits="objectBoundingBox" + spreadMethod="pad" /> + <radialGradient + cx="0.5" + cy="0.5" + fx="0.5" + fy="0.5" + r="0.5" + id="radialGradient131" + xlink:href="#linearGradient127" + gradientUnits="objectBoundingBox" + spreadMethod="pad" /> + </defs> + <rect + width="291.837" + height="57.0074" + x="17.3169" + y="18.646" + style="font-size:12;fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect136" /> + <rect + width="291.837" + height="57.0074" + x="13.9703" + y="16.2302" + style="font-size:12;fill:#d2d2d2;fill-rule:evenodd;stroke-width:1pt;" + id="rect126" /> + <g + transform="matrix(0.326107,0,0,0.765831,9.59261,8.98517)" + style="font-size:12;" + id="g161"> + <rect + width="285.502" + height="118.523" + x="16.6979" + y="99.2053" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect137" /> + <rect + width="285.502" + height="118.523" + x="13.4238" + y="95.9309" + style="fill:#d2d2d2;fill-rule:evenodd;stroke-width:1pt;" + id="rect132" /> + </g> + <g + transform="matrix(1.02406,0,0,0.652953,0.223384,39.9254)" + style="font-size:12;" + id="g164"> + <rect + width="285.502" + height="77.2688" + x="16.6979" + y="222.966" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect138" /> + <rect + width="285.502" + height="77.2688" + x="14.7335" + y="221.002" + transform="translate(-1.30962,-1.30992)" + style="fill:#d2d2d2;fill-rule:evenodd;stroke-width:1pt;" + id="rect133" /> + </g> + <g + transform="matrix(0.449834,0,0,0.338463,-3.15909,9.73319)" + style="font-size:12;" + id="g167"> + <rect + width="199.065" + height="61.5532" + x="61.8805" + y="68.4288" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect134" /> + <rect + width="199.065" + height="61.5532" + x="59.2613" + y="65.8095" + style="fill:#e0e0e0;fill-rule:evenodd;stroke-width:1pt;" + id="rect135" /> + </g> + <text + x="302.277679" + y="65.943230" + transform="scale(0.73778,0.73778)" + style="font-size:18;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text183"> + <tspan + x="302.277954" + y="65.943184" + id="tspan360"> +Application</tspan> + </text> + <text + x="36.235924" + y="63.796055" + transform="scale(0.73778,0.73778)" + style="font-size:14;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text188"> + <tspan + x="36.235950" + y="63.796051" + id="tspan427"> +Transient Objects</tspan> + </text> + <text + x="180.416245" + y="290.543701" + transform="scale(0.73778,0.73778)" + style="font-size:18;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text197"> + <tspan + x="180.415939" + y="290.543549" + id="tspan421"> +Database</tspan> + </text> + <text + x="25.037701" + y="179.154755" + transform="scale(0.73778,0.73778)" + style="font-size:16;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text216"> + <tspan + x="25.037655" + y="179.154648" + id="tspan384"> +SessionFactory</tspan> + </text> + <g + transform="matrix(0.252763,0,0,0.765831,109.104,8.98517)" + style="font-size:12;" + id="g386"> + <rect + width="285.502" + height="118.523" + x="16.6979" + y="99.2053" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect387" /> + <rect + width="285.502" + height="118.523" + x="13.4238" + y="95.9309" + style="fill:#d2d2d2;fill-rule:evenodd;stroke-width:1pt;" + id="rect388" /> + </g> + <g + transform="matrix(0.297394,0,0,0.572692,101.502,21.6359)" + style="font-size:12;" + id="g364"> + <rect + width="199.065" + height="61.5532" + x="61.8805" + y="68.4288" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect365" /> + <rect + width="199.065" + height="61.5532" + x="59.2613" + y="65.8095" + style="fill:#e0e0e0;fill-rule:evenodd;stroke-width:1pt;" + id="rect366" /> + </g> + <text + x="202.746506" + y="102.992203" + transform="scale(0.73778,0.73778)" + style="font-size:14;font-weight:normal;stroke-width:1pt;font-family:Helvetica;text-anchor:middle;" + id="text367"> + <tspan + x="202.746948" + y="102.992249" + id="tspan423"> +Persistent</tspan> + <tspan + x="202.746948" + y="116.992355" + id="tspan425"> +Objects</tspan> + </text> + <text + x="174.458496" + y="180.080795" + transform="scale(0.73778,0.73778)" + style="font-size:16;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text389"> + <tspan + x="174.458618" + y="180.080338" + id="tspan392"> +Session</tspan> + </text> + <g + transform="matrix(0.127369,0,0,0.765831,188.675,8.98517)" + style="font-size:12;" + id="g394"> + <rect + width="285.502" + height="118.523" + x="16.6979" + y="99.2053" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect395" /> + <rect + width="285.502" + height="118.523" + x="13.4238" + y="95.9309" + style="fill:#d2d2d2;fill-rule:evenodd;stroke-width:1pt;" + id="rect396" /> + </g> + <text + x="260.413269" + y="179.154739" + transform="scale(0.73778,0.73778)" + style="font-size:16;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text397"> + <tspan + x="260.412964" + y="179.154343" + id="tspan400"> +JDBC</tspan> + </text> + <g + transform="matrix(0.127369,0,0,0.765831,229.156,8.98517)" + style="font-size:12;" + id="g405"> + <rect + width="285.502" + height="118.523" + x="16.6979" + y="99.2053" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect406" /> + <rect + width="285.502" + height="118.523" + x="13.4238" + y="95.9309" + style="fill:#d2d2d2;fill-rule:evenodd;stroke-width:1pt;" + id="rect407" /> + </g> + <text + x="320.606903" + y="179.154739" + transform="scale(0.73778,0.73778)" + style="font-size:16;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text408"> + <tspan + x="320.606964" + y="179.154343" + id="tspan417"> +JNDI</tspan> + </text> + <g + transform="matrix(0.127369,0,0,0.765831,269.281,8.98517)" + style="font-size:12;" + id="g411"> + <rect + width="285.502" + height="118.523" + x="16.6979" + y="99.2053" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect412" /> + <rect + width="285.502" + height="118.523" + x="13.4238" + y="95.9309" + style="fill:#d2d2d2;fill-rule:evenodd;stroke-width:1pt;" + id="rect413" /> + </g> + <text + x="377.096313" + y="179.154739" + transform="scale(0.73778,0.73778)" + style="font-size:16;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text414"> + <tspan + x="377.096008" + y="179.154999" + id="tspan145"> +JTA</tspan> + </text> +</svg> Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/images/overview.png (from rev 14073, core/trunk/documentation/manual/en-US/src/main/docbook/images/overview.png) =================================================================== (Binary files differ) Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/images/overview.svg (from rev 14073, core/trunk/documentation/manual/en-US/src/main/docbook/images/overview.svg) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/images/overview.svg (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/images/overview.svg 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,250 @@ +<?xml version="1.0" standalone="no"?> +<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" +"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd" +[ + <!ATTLIST svg + xmlns:xlink CDATA #FIXED "http://www.w3.org/1999/xlink"> +]> +<!-- Created with Sodipodi ("http://www.sodipodi.com/") --> +<svg + xmlns="http://www.w3.org/2000/svg" + xmlns:xlink="http://www.w3.org/1999/xlink" + width="248.031" + height="248.031" + id="svg1"> + <defs + id="defs3"> + <linearGradient + x1="0" + y1="0" + x2="1" + y2="0" + id="linearGradient127" + gradientUnits="objectBoundingBox" + spreadMethod="pad"> + <stop + style="stop-color:#000000;stop-opacity:1;" + offset="0" + id="stop128" /> + <stop + style="stop-color:#ffffff;stop-opacity:1;" + offset="1" + id="stop129" /> + </linearGradient> + <linearGradient + x1="0" + y1="0" + x2="1" + y2="0" + id="linearGradient130" + xlink:href="#linearGradient127" + gradientUnits="objectBoundingBox" + spreadMethod="pad" /> + <radialGradient + cx="0.5" + cy="0.5" + fx="0.5" + fy="0.5" + r="0.5" + id="radialGradient131" + xlink:href="#linearGradient127" + gradientUnits="objectBoundingBox" + spreadMethod="pad" /> + </defs> + <g + transform="matrix(0.771934,0,0,0.771934,4.36019,-3.02123)" + style="font-size:12;" + id="g158"> + <rect + width="285.502" + height="77.2688" + x="16.6979" + y="17.3527" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect136" /> + <rect + width="285.502" + height="77.2688" + x="14.7335" + y="15.3883" + transform="translate(-1.30962,-1.30992)" + style="fill:#d2d2d2;fill-rule:evenodd;stroke-width:1pt;" + id="rect126" /> + </g> + <g + transform="matrix(0.771934,0,0,0.771934,4.36019,3.04452)" + style="font-size:12;" + id="g161"> + <rect + width="285.502" + height="118.523" + x="16.6979" + y="99.2053" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect137" /> + <rect + width="285.502" + height="118.523" + x="13.4238" + y="95.9309" + style="fill:#d2d2d2;fill-rule:evenodd;stroke-width:1pt;" + id="rect132" /> + </g> + <g + transform="matrix(0.771934,0,0,0.771934,4.36019,8.0993)" + style="font-size:12;" + id="g164"> + <rect + width="285.502" + height="77.2688" + x="16.6979" + y="222.966" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect138" /> + <rect + width="285.502" + height="77.2688" + x="14.7335" + y="221.002" + transform="translate(-1.30962,-1.30992)" + style="fill:#d2d2d2;fill-rule:evenodd;stroke-width:1pt;" + id="rect133" /> + </g> + <g + transform="matrix(0.771934,0,0,0.543505,2.59104,21.1103)" + style="font-size:12;" + id="g167"> + <rect + width="199.065" + height="61.5532" + x="61.8805" + y="68.4288" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect134" /> + <rect + width="199.065" + height="61.5532" + x="59.2613" + y="65.8095" + style="fill:#e0e0e0;fill-rule:evenodd;stroke-width:1pt;" + id="rect135" /> + </g> + <text + x="105.392174" + y="56.568123" + transform="scale(0.771934,0.771934)" + style="font-size:24;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text183"> + <tspan + x="105.392273" + y="56.568146" + id="tspan186"> +Application</tspan> + </text> + <text + x="81.820183" + y="103.149330" + transform="scale(0.771934,0.771934)" + style="font-size:20;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text188"> + <tspan + x="81.820213" + y="103.149727" + id="tspan206"> +Persistent Objects</tspan> + </text> + <text + x="111.548180" + y="278.927887" + transform="scale(0.771934,0.771934)" + style="font-size:24;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text197"> + <tspan + x="111.547874" + y="278.927551" + id="tspan200"> +Database</tspan> + </text> + <text + x="94.436180" + y="153.805740" + transform="scale(0.771934,0.771934)" + style="font-size:24;font-weight:normal;stroke-width:1pt;font-family:Helvetica;" + id="text216"> + <tspan + x="94.436180" + y="153.805740" + id="tspan221"> +HIBERNATE</tspan> + </text> + <g + transform="matrix(0.771934,0,0,0.771934,2.59083,1.02261)" + style="font-size:12;" + id="g254"> + <g + transform="translate(4.58374,2.61928)" + id="g176"> + <g + transform="matrix(0.571429,0,0,0.67347,-10.6174,117.093)" + id="g170"> + <rect + width="199.065" + height="61.5532" + x="61.8805" + y="68.4288" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect171" /> + <rect + width="199.065" + height="61.5532" + x="59.2613" + y="65.8095" + style="fill:#e0e0e0;fill-rule:evenodd;stroke-width:1pt;" + id="rect172" /> + </g> + <g + transform="matrix(0.571429,0,0,0.67347,138.682,117.093)" + id="g173"> + <rect + width="199.065" + height="61.5532" + x="61.8805" + y="68.4288" + style="fill:#757575;fill-rule:evenodd;stroke-width:1pt;" + id="rect174" /> + <rect + width="199.065" + height="61.5532" + x="59.2613" + y="65.8095" + style="fill:#e0e0e0;fill-rule:evenodd;stroke-width:1pt;" + id="rect175" /> + </g> + </g> + <text + x="47.259438" + y="182.367538" + style="font-weight:bold;stroke-width:1pt;font-family:Courier;" + id="text191"> + <tspan + x="47.259399" + y="182.367996" + id="tspan212"> +hibernate.</tspan> + <tspan + x="47.259399" + y="194.367996" + id="tspan214"> +properties</tspan> + </text> + <text + x="198.523010" + y="188.260941" + style="font-weight:normal;stroke-width:1pt;font-family:helvetica;" + id="text194"> + <tspan + id="tspan195"> +XML Mapping</tspan> + </text> + </g> +</svg> Copied: core/trunk/documentation/manual/ko-KR/src/main/docbook/legal_notice.xml (from rev 14073, core/trunk/documentation/manual/en-US/src/main/docbook/legal_notice.xml) =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/legal_notice.xml (rev 0) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/legal_notice.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -0,0 +1,37 @@ +<?xml version='1.0'?> +<!DOCTYPE legalnotice PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> + +<legalnotice id="Legal_Notice"> + <title>Legal Notice</title> + <para> + <address> + <street>1801 Varsity Drive</street> + <city>Raleigh</city>, <state>NC</state><postcode>27606-2072</postcode><country>USA</country> + <phone>Phone: +1 919 754 3700</phone> + <phone>Phone: 888 733 4281</phone> + <fax>Fax: +1 919 754 3701</fax> + <pob>PO Box 13588</pob><city>Research Triangle Park</city>, <state>NC</state><postcode>27709</postcode><country>USA</country> + </address> + </para> + <para> + Copyright <trademark class="copyright"></trademark> 2007 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, V1.0 or later (the latest version is presently available at <ulink url="http://www.opencontent.org/openpub/">http://www.opencon...>). + </para> + <para> + Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. + </para> + <para> + Distribution of the work or derivative of the work in any standard (paper) book form for commercial purposes is prohibited unless prior permission is obtained from the copyright holder. + </para> + <para> + Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat, Inc. in the United States and other countries. + </para> + <para> + All other trademarks referenced herein are the property of their respective owners. + </para> + <para> + The GPG fingerprint of the security(a)redhat.com key is: + </para> + <para> + CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E + </para> +</legalnotice> \ No newline at end of file Deleted: core/trunk/documentation/manual/ko-KR/src/main/docbook/master.xml =================================================================== --- core/trunk/documentation/manual/ko-KR/src/main/docbook/master.xml 2007-10-09 19:05:51 UTC (rev 14078) +++ core/trunk/documentation/manual/ko-KR/src/main/docbook/master.xml 2007-10-09 19:14:22 UTC (rev 14079) @@ -1,184 +0,0 @@ -<?xml version='1.0' encoding="UTF-8"?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3CR3//EN" - "../support/docbook-dtd/docbookx.dtd" -[ -<!ENTITY tutorial SYSTEM "modules/tutorial.xml"> -<!ENTITY architecture SYSTEM "modules/architecture.xml"> -<!ENTITY configuration SYSTEM "modules/configuration.xml"> -<!ENTITY persistent-classes SYSTEM "modules/persistent_classes.xml"> -<!ENTITY basic-mapping SYSTEM "modules/basic_mapping.xml"> -<!ENTITY collection-mapping SYSTEM "modules/collection_mapping.xml"> -<!ENTITY association-mapping SYSTEM "modules/association_mapping.xml"> -<!ENTITY component-mapping SYSTEM "modules/component_mapping.xml"> -<!ENTITY inheritance-mapping SYSTEM "modules/inheritance_mapping.xml"> -<!ENTITY session-api SYSTEM "modules/session_api.xml"> -<!ENTITY transactions SYSTEM "modules/transactions.xml"> -<!ENTITY events SYSTEM "modules/events.xml"> -<!ENTITY batch SYSTEM "modules/batch.xml"> -<!ENTITY query-hql SYSTEM "modules/query_hql.xml"> -<!ENTITY query-criteria SYSTEM "modules/query_criteria.xml"> -<!ENTITY query-sql SYSTEM "modules/query_sql.xml"> -<!ENTITY filters SYSTEM "modules/filters.xml"> -<!ENTITY xml SYSTEM "modules/xml.xml"> -<!ENTITY performance SYSTEM "modules/performance.xml"> -<!ENTITY toolset-guide SYSTEM "modules/toolset_guide.xml"> -<!ENTITY example-parentchild SYSTEM "modules/example_parentchild.xml"> -<!ENTITY example-weblog SYSTEM "modules/example_weblog.xml"> -<!ENTITY example-mappings SYSTEM "modules/example_mappings.xml"> -<!ENTITY best-practices SYSTEM "modules/best_practices.xml"> -]> - -<book lang="ko"> - - <bookinfo lang="ko"> - <title>HIBERNATE - 개성있는 자바를 위한 관계 영속</title> - <subtitle>하이버네이트 참조 문서</subtitle> - <releaseinfo lang="ko">3.2 cr3</releaseinfo> - </bookinfo> - - <toc lang="ko" /> - - <preface id="preface" revision="2"> - <title>머리말</title> - - <para> - 객체 지향 소프트웨어와 관계형 데이터베이스로 작업하는 것은 오늘날의 엔터프라이즈 환경들에서 성가시고 시간이 - 소비될 수 있다. Hibernate는 자바 환경들을 위한 객체/관계형 매핑 도구이다. - object/relational mapping(ORM) 용어는 객체 모형으로부터 SQL-기반의 스키마를 가진 - 관계형 데이터 모형으로의 데이터 표상을 매핑하는 기술을 언급한다. - </para> - - <para> - Hibernate는 자바 클래스들로부터 데이터베이스로의 매핑(그리고 자바 데이터 타입들로부터 SQL 데이터 - 타입들로의 매핑)을 처리할 뿐만 아니라, 또한 데이터 질의와 검색 편의들을 제공하며, SQL과 JDBC로 - 수작업 데이터 핸들링에 소요되는 개발 시간을 현저하게 단축시켜줄 수 있다. - </para> - - <para> - Hibernate의 목적은 공통된 데이터 영속화 관련 프로그래밍 작업들의 95%를 덜어주는 것이다. - Hibernate는 데이터베이스에서 비지니스 로직을 구현하는데 내장 프로시저들을 전용으로 사용하는 데이터 - 중심적 어플리케이션에 대한 최상의 솔루션이 아닐 수도 있지만, 그것은 자바 기반 미들-티어에서 객체 지향 - 도메인 모형들과 비지니스 로직에 가장 유용하다. 하지만 Hibernate는 벤더 지정적인 SQL 코드를 - 제거하거나 캡슐화 시키는 당신을 확실히 도와줄 수 있고 테이블 형식의 표현으로부터 객체들의 그래프로 결과 - 셋을 변환하는 공통된 태스크를 도와줄 것이다. - </para> - - <para> - 만일 당신이 Hibernate와 Object/Relational 매핑 또는 심지어 자바에 초심자라면, 다음 - 단계들을 따르기 바란다: - </para> - - <orderedlist> - <listitem> - <para> - 더 많은 단계적인 사용 설명서들을 가진 더 긴 튜토리얼은 - <xref linkend="tutorial"/> - 을 읽어라. 튜토리얼을 위한 소스 코드는 <literal>doc/reference/tutorial/</literal> - 디렉토리에 포함되어 있다. - </para> - </listitem> - <listitem> - <para> - Hibernate가 사용될 수 있는 환경을 이해려면 - <xref linkend="architecture" /> - 를 읽어라. - </para> - </listitem> - <listitem> - <para> - Hibernate 배포본 내의 - <literal>eg/</literal> - 디렉토리를 살펴 보라. 이 디렉토리는 간단한 스탠드얼론 어플리케이션을 포함하고 있다. 당신의 - JDBC 드라이버를 - <literal>lib/</literal> - 디렉토리에 복사하고 당신의 데이터베이스에 맞는 정확한 값을 지정하여 - <literal>etc/hibernate.properties</literal> - 를 편집하라. 배보본 디렉토리에서 명령 라인 프롬프트에서 (Ant를 사용하여) - <literal>ant eg</literal> - 를 타이핑 하거나 , Windows 하에서 - <literal>build eg</literal> - 를 타이프 하라. - </para> - </listitem> - <listitem> - <para> - 당신의 주된 정보의 소스로서 이 참조 문서를 사용하라. 만일 어플리케이션 설계에 대해 더 많은 - 도움을 필요로 하거나 당신이 단계적인 튜토리얼을 선호한다면 - <emphasis>Java Persistence with Hibernate</emphasis> - (http://www.manning.com/bauer2)을 읽는 것을 고려하라.또한 - http://caveatemptor.hibernate.org에 방문하여 Java Persistence - with Hibernate용 예제 어플리케이션을 다운로드 하라. - </para> - </listitem> - <listitem> - <para> - FAQ들은 Hibernate 웹 사이트 상에 답변되어 있다. - </para> - </listitem> - <listitem> - <para> - 제 3의 데모들, 예제들, 그리고 튜토리얼들은 Hibernate 웹 사이트 상에 링크되어 - 있다. - </para> - </listitem> - <listitem> - <para> - Hibernate 웹사이트 상의 공동체 영역은 설계 패턴과 다양한 통합 솔루션들(Tomcat, - JBoss AS, Struts, EJB 등.)에 관한 좋은 리소스이다. - </para> - </listitem> - </orderedlist> - - <para> - 질문이 있다면, Hibernate 상에 링크되어 있는 사용자 포럼을 사용하라. 우리는 또한 버그 보고와 특징 - 요청들을 위한 JIRA 쟁점 추적 시스템을 제공한다. 당신이 Hibernate의 개발에 관심이 있다면, - 개발자 메일링 리스트에 참여하라. 만일 당신이 이 문서를 당신의 언어로 번역하는 것에 관심이 있다면, 개발자 - 메일링 리스트에 접촉하라. - </para> - - <para> - Hibernate를 위한 상용 개발 지원, 제품 지원, 그리고 교육은 JBoss Inc를 통해 이용 가능하다 - (http://www.hibernate.org/SupportTraining/를 보라). Hibernate는 - JBoss Professional Open Source product 프로젝트이고 제품들에 대한 JBoss - Enterprise Middleware System (JEMS) suite의 중대한 컴포넌트이다. - </para> - - </preface> - - &tutorial; - - &architecture; - - &configuration; - - &persistent-classes; - - &basic-mapping; - &collection-mapping; - &association-mapping; - &component-mapping; - &inheritance-mapping; - - &session-api; - &transactions; - &events; - &batch; - - &query-hql; - &query-criteria; - &query-sql; - &filters; - &xml; - - &performance; - - &toolset-guide; - - &example-parentchild; - &example-weblog; - &example-mappings; - - &best-practices; - -</book> -