'JAVA/framework'에 해당되는 글 7건

  1. 2010.03.17 오래기다렸다!! htmlUnit 2.7 (1)
  2. 2008.04.18 XSL (eXtensible Stylesheet Language) 이란? (2)
  3. 2008.04.08 튜닝이론
  4. 2007.12.06 Junit 사용법 (2)
  5. 2007.05.17 [JSON] json으로 개발하려면 필요한것들.
  6. 2007.02.01 tiles 타일즈에 대한 빠른 접근
  7. 2007.01.29 Hibernate 한글 Document (1)

사실 더이상 개발이 안되는줄 알았다.
UX의 비중높은 WEB환경의 변화와 ActiveX가 결코 htmlUnit을 호락호락하게
놔둘것 같지 않았기 때문이다.
그런데 2010년02월09일 전격적으로 발표가 났다!!

"javaScript 지원 Native ActiveX 지원"

정말 수고 많았다. 너의 자랑스런 탄생을 기반삼아 이제 새로운 WEB을 보일때가 된것 같구나!
웃샤!!
버닝이다.
저작자 표시 비영리 변경 금지
신고


XSL (eXtensible Stylesheet Language) 이란?


XML 문서를 presentation 해주기 위한 포맷팅 언어.

xml 문서이다.

1. XSL 의 구성

1) XSLT ( XSL Transformation )
   : xml 문서의 구조를 다른 구조로 변환하기 위한 마크업 언어.
2) XPath ( XSL Path Language )
   : xml 문서 내에서 특정 part (엘리먼트 or 속성)을 찾아가기 위한 경로 표기 언어.
3) XSL-FO ( XSL Formatting Objects )
   : Formatter 프로그램을 통해 XML 문서를 비 XML 문서로 변환하기 위한 마크업 언어.


2. XSL 처리 과정

▪ Transformation : XML 문서를 다른 구조의 XML 문서로 구조를 변환하는 과정.
▪ Formatting       : XML 문서를 특정 S/W, H/W에 맞는 비 XML 문서로 변환하는 과정.

사용자 삽입 이미지

XSL Transform 의 결과물은 파일 형태의 문서가 아닌, 메모리 상에서 트리를 이루는 DOM 객체들로 생성된다. 이것을 Result Tree 라 한다.

3. XSLT 문서의 구성

▪ XML 선언 (optional)
▪ XSLT stylesheet 선언
▪ Top-level element
▪ Template과 Literal result element



◆ XSL 문서의 루트 엘리먼트와 최상위 엘리먼트

1. Root Element
: stylesheet or transform

 

<?xml version="1.0" encoding="euc-kr"?>                

<xsl:stylesheet

version="1.0"                          

xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

 

</xsl:stylesheet>


▪ version 필수 선언.
http://www.w3.org/1999/XSL/Transform : XSLT 1.0 의 public namespace URI
  cf. http://www.w3.org/1999/TR/WD-xsl  :  XSLT 1.0 공식 권고안이 나오기 이전 MS에서 사용하던 것.

2. Top-level Element
: 루트 엘리먼트의 자식 엘리먼트

-  xsl 문서의 결합
▪  import 엘리먼트
▪  include 엘리먼트


- result tree 문서 종류 결정
▪ output 엘리먼트

- result tree의 엘리먼트 내용을 담고 있는 Top-level Element
▪ template 엘리먼트

- 기타
▪ strip-space 엘리먼트
▪ preserve-space 엘리먼트
▪ key 엘리먼트
▪ decimal-format 엘리먼트
▪ namespace-alias 엘리먼트
▪ attribute-set 엘리먼트
▪ variable 엘리먼트
▪ param 엘리먼트





◆ output 엘리먼트

: Result Tree 의 문서 종류를 지정한다.
  생략되었거나, 있어도 method 속성이 없으면
  default 값은 xml이다.
  ( result tree 의 root element 이름이 namespace 접두사가 없는 'html'일 경우에만 default 값이 'html' )

<xsl:output 속성명="속성값" 속성명="속성값"/>

ex.
<xsl:output method="xml" version="1.0" encoding="euc-kr" indent="yes"/>



속 성 명

  

속성값 유형

method

Result tree 문서 종류 지정

xml, html, text

version

Result tree XML 문서일 경우 XML 권고안 버전

1.0

encoding

Result tree의 인코딩 방식 지정

String(ex:euc-kr,UTF-8)

omit-xml-declaration

Result tree XML 선언 생략 여부.
출력 방법이 'xml'이면 default는 'no'

yes, no

standalone

Result tree의 외부 문서 참조 여부

yes, no

doctype-public

Result tree가 문서 유형 선언을 포함할 경우 PUBLIC 식별자 지정

String

doctype-system

Result tree 가 문서 유형 선언을 포함할 경우 SYSTEM 식별자 지정

String

cdata-section-elements

Result tree에서 CDATA 섹션으로 사용되어야 할 노드 지정
method="xml" 인 경우만 해당.

Qname

indent

Result tree에 화이트스페이스(태그와 태그 사이의 공백)를 포함할 지 여부

yes, no

media-type

media-type 지정

String



사용자 삽입 이미지















 

◆ 노드 및 노드셋


XML 문서

<?xml version=”1.0”>

<musiclist>

     <title>사랑 하나면 돼</title>

<title>착한 거짓말</title>

<title>물끄러미</title>

</musiclist>

루트 노드 : 문서 자체를 뜻하는 노드

 

루트 엘리먼트 노드

title  

    title     노드 셋 : 같은 엘리먼트 이름을 가진 노드들.

    title                   

 

 




Template Rule


어떤 구조를 다른 구조로 바꾸는 방법.

▪ 원본 XML 문서의 노드(엘리먼트)들을 다른 구조의 노드(엘리먼트)로 바꾸는 역할.


1. 정의
==============================================================================================


<xsl:template match="pattern">   

             <!-- Content: (xsl:param*, template) -->

</xsl:template>

ex.

        <xsl:template match="//book">       ← XSLT 엔진이 소스 트리에서 <book> 엘리먼트 발견할    

             .....                                            때마다 처리한다. node-set에 템플릿 룰을 적용해 변환.

        </xsl:template>


▪ match 속성 : 소스 트리의 하나의 패턴을 규정한다.
                     패턴에 매치하는 어떤 노드에도 적용될 수 있다.

▪ pattern : XML 문서에서 변환되어야 할 대상 노드 지정.

              Xpath 표현식 중, 한 개 노드 or 노드셋을 가리키는 표현식.

   

   

/

루트 노드(문서 자체) 지정.

/노드명/…/노드명

특정 경로의 노드() 지정.

//노드명 or 노드명

경로 상관없이 같은 이름의 노드() 지정.

/노드명/노드명[@속성명=’속성값’]

특정 속성값을 가지는 노드() 지정.

/노드명/노드명[@속성명!=’속성값’]

특정 속성값과 다른 속성값을 가지는 노드() 지정.


▪ Xpath expression Vs Xpath pattern

)  /name/first


1) Xpath express : document root 로 가서 <name> 자식 요소를 찾은 후, <first> 자식 요소로 가라
2) Xpath pattern  : <name> 요소의 한 자식인 어떤 <first> 요소와 일치시켜라. 이것은 document root 의 자식이어야 한다.



2. 적용

==============================================================================================
: 템플릿 룰을 통해 변환된 result tree의 어떤 부분에 포함할 것인지 알려준다.
 
 

<xsl:apply-templates select="node-set-expression">

              <!-- Content: (xsl:sort | xsl:with-param)* -->
<xsl:apply-templates>

ex. <xsl:apply-templates select="book">


▪ select 속성 : 모든 children을 처리하는 대신 선택된 노드만 처리한다.

▪ XSL 변환기의 동작

① select 속성에 지정된 노드와 동일한 노드를 match 속성으로 갖는 템플릿 룰을 찾는다.
② 템플릿 룰을 적용해 변환된 내용을 xsl:apply-templates 엘리먼트와 대치시킨다.

③ select 속성 생략시, 모든 템플릿 룰을 적용해 변환된 내용을 xsl:apply-templates 엘리먼트와 대치시킨다.


3. name 속성
==============================================================================================
: XSL 문서내에서 반복 적용되는 내용을 한 개의 템플릿 룰로 만들고,

  그 템플릿 룰명으로 다른 템플릿 룰에서 참조해서 적용할 경우에 사용된다.
 
템플릿 룰은 match와 name 속성 중 하나를 반드시 기술해야 한다.

1) 정의

<xsl:template name="Template Rule name">

                   <!-- Content: (xsl:param*, template) -->

</xsl:template>


ex.

<xsl:template name="tYear">

         <font color="red">2007년</font>
</xsl:template>  


2) 적용

<xsl:call-template name="Template Rule name">

             <!-- Content: xsl:with-param* -->
<xsl:call-template/>

ex. <xsl:call-template name="tCompany"/>



4. priority 속성
==============================================================================================
: XML 문서의 대상 노드를 변환시키는 템플릿 룰이 여러 개 있을 경우 우선선위가 높은 템플릿 룰이 적용되도록 한다.

priority number 가 클 수록 우선순위가 높다.

name 속성을 갖는 template rule 에서는 사용할 수 없다.


<xsl:template match="pattern" priority="number”>

         <!-- Content: (xsl:param*, template) -->
</xsl:template>


ex.

<xsl:template match="musiclist" priority="1”>

<th>title</th>

</xsl:template>

 

<xsl:template match="/musiclist /music" priority="2">

<th>price</th>

</xsl:template>



5. mode 속성
==============================================================================================
: 소스 트리의 같은 부분이 한 번 이상 처리되어야 할 때 사용한다.
name 속성을 갖는 template rule 에서는 사용할 수 없다.  (match 속성만 가능)

1) 정의

<xsl:template match="pattern" mode="Mode Name">

             <!-- Content: (xsl:param*, template) -->

</xsl:template>


ex.

<xsl:template match="title" mode="modeA">

               <xsl:value-of select="author"/>

</xsl:template>


2) 적용

<xsl:apply-templates select="node-set-expression" mode="Mode Name"/>


ex.
<xsl:apply-templates select="/musiclist/title[@genre=
jazz']" mode="modeA"/>

<xsl:apply-templates select="/musiclist/title[@genre=dance']" mode="modeB"/>





◆ XML 문서의 내용 가져오기


1. 엘리먼트의 컨텐트 내용 or 속성값 가져오기 : value-of

==============================================================================================

1) 엘리먼트의 컨텐트 내용 가져오기

<xsl:template match="대상 노드">

               <xsl:value-of select="대상 노드 자신 or 자식 노드명"
                                 disable-output-escaping="yes or no"/>

</xsl:template>

ex.
<xsl:template match="/musiclist/music">

               <xsl:value-of select="."/>          // title 노드 자신의 컨텐트 내용을 가져와 대치한다.

</xsl:template>


<!-- 컨텐트 내용이 숫자일 경우 -->
<xsl:template match="/musiclist/music">

               <xsl:value-of select="format-number(price, '###,###')"/>         
</xsl:template>



2) 속성값 가져오기

<xsl:template match="대상 노드">

               <xsl:value-of select="@속성명"/>

</xsl:template>

ex.
<xsl:template match="/musiclist/music">

               <xsl:value-of select="@genre"/>        
</xsl:template>


disable-output-escaping 속성
: XSLT processor 에게 이스케이프 문자 ("&amp;", "&lt;") 대신 "&", "<" 문자를 출력하라고 지시한다.
  default는 'no' 로, 보통은 XSLT processor가 출력시 자동으로 이런 문자로 바꾸어준다.
  xsl:value-of 와 xsl:text 엘리먼트의 속성으로 사용된다.

ex. <name>&amp;</name>

<xsl:value-of select="name" disable-output-escaping="yes"/>

→ 결과는 &

<xsl:value-of select="name" disable-output-escaping="no"/>

→ 결과는 &amp;




2. 엘리먼트 or 속성 복사해서 가져오기 : copy-of
==============================================================================================
: 원본 XML 문서의 일부분을 구조 변경 없이 복사해서 변환될 XML 문서에 붙인다.

<xsl:template match="대상 노드">

               <xsl:copy-of select="(복사할)자식노드명 or @속성명"/>

</xsl:template>

ex.

<xsl:template match="music">

               <xsl:copy-of select="title"/>

               <xsl:copy-of select="@genre"/>
</xsl:template>



◆ 정렬 (Sort)

<xsl:apply-templates select="대상 노드">

        <xsl:sort select="자식노드명 or @속성명"
                     data-type="number | text"
                     order="ascending | descending"
                     case-order="upper-first | lower-first"/>

</xsl:apply-templates>


ex.

<xsl:apply-templates select="/musiclist/music">

          <xsl:sort select="price" data-type="number" order="ascending"/>

</xsl:apply-templates>


default
   data-type : text
   order : ascending
   case-order : document에 사용되는 언어를 정의하는 lang 속성에 의존.
                     (upper-first일 경우 "A B a b" -> "A a B b")
▪ xsl:apply-templates 엘리먼트와 xsl:for-each 엘리먼트의 자식엘리먼트로 작성된다.

▪ 2차 정렬
: 1차로 컬럼을 먼저 정렬시키고, 정렬된 상태에서 다른 컬럼을 2차로 정렬시키는 것.

<xsl:apply-templates select="/musiclist/music">

              <!-- 1차 정렬 -->

              <xsl:sort select="@genre"/>

              <!-- 2차 정렬 -->

              <xsl:sort select="price" data-type="number" order="ascending"/>

</xsl:apply-templates>





◆ 번호 매기기

: XSL 변환기는 result tree 생성시 자동으로 번호를 매겨 삽입할 수 있다.
  이 기능을 이용해 XSL 문서에서 번호가 삽입되는 위치에 xsl:number 엘리먼트를 작성한다.

<xsl:template match="대상 노드">
              <xsl:number format="
번호 형식">
</xsl:template>

ex.
<xsl:template match="music">
   <tr>
      <td><xsl:number format="1"></td>
      <td><xsl:value-of select="title"></td>
   </tr>             
</xsl:template>


번호 형식 : '1', 'a', 'A', 'i', 'I', '(1)'




◆ 제어 엘리먼트


1. xsl:if 엘리먼트
==============================================================================================
: 조건식이 참이면 변환 내용을 적용한다.

<xsl:template match="xml 대상 노드">

        <xsl:if test="조건식">

                   <!-- Content: template -->
     
</xsl:if>

</xsl:template>


▪ 조건식에 자주 오는 XPath 표현식

조건식

설명

노드명=’문자열

컨텐트 내용이 문자열을 가지면 참

@속성명=’속성값

주어진 속성값을 가지면 참

@속성명!=’속성값

주어진 속성값이 아닌 다른 값을 가지면 참

start-with(노드명,’문자열’)

컨텐트 내용이 문자열로 시작하면 참

contains(노드명,’문자열’)

컨텐트 내용이 문자열을 포함하면 참




2. xsl:choose 엘리먼트
==============================================================================================

<xsl:template match="music">
     
<xsl:choose>
           
<xsl:when test="조건식1">       

                  <!-- Content: template -->
           
</xsl:when>

                           
           
<xsl:when test="조건식2">

                  <!-- Content: template -->           
            </xsl:when>

                         
           
<xsl:otherwise>                    <!-- 생략 가능 -->

                   <!-- Content: template -->
           
</xsl:otherwise>
     
</xsl:choose>

</xsl:template>

test 표현 중 하나라도 참이 되면 <xsl:choose>를 빠져나간다.


3. xsl:for-each 엘리먼트
==============================================================================================
: 대상 노드 숫자만큼 반복해서 변환시킨다.
  반드시 템플릿 룰 안에서 작성되어야 한다.

<xsl:template match="대상 노드">

     <xsl:for-each select="대상 노드">

       변환 내용
     </xsl:for-each>
</xsl:template>


ex.
<xsl:for-each select="/musiclist/music">

<tr>

<td><xsl:value-of select="title"/></td>

<td><xsl:value-of select="@genre"/></td>

</tr>

</xsl:for-each>





◆ 변수와 파라미터


1. 변수
==============================================================================================

1) 변수 선언

<xsl:variable name="변수명" select="변수값"/> 

<xsl:variable name="변수명">변수명</xsl:variable>

<!-- 변수값으로 빈 문자값을 줄 경우 -->
<xsl:variable name="변수명" select="''"/> 
<xsl:variable name="변수명"/>

ex.

<xsl:variable name="vList" select="'책목록'"/>  <!--select 속성값 지정시, 문자열인 경우 반드시 ''-->

<xsl:variable name="vKind">
       <!-- Content: template -->
</xsl:variable>



2) 변수 사용
▪ 변수값(=단순한 문자열) & result tree의 컨텐트 내용으로 사용될 경우

<엘리먼트> <xsl:value-of select="$변수명"/> </엘리먼트>

ex.
  <xsl:template match="music">
             <xsl:value-of select="$변수명"/>
      </xsl:template>


▪ 변수값(=단순한 문자열) & result tree의 속성값으로 사용될 경우

속성명="{$변수명}"

ex.
<font size="{$vGenre}"> .... </font>


▪ 변수값(=단순한 문자열) & XPath 표현식에서 사용될 경우

[노드명=$변수명] or [@속성명=$변수명]

ex.
<xsl:for-each select="//music[@genre=$vGenre]">


▪ 변수값이 result tree의 일부분을 이루는 엘리먼트들로 구성되어 있을 경우

<엘리먼트> <xsl:copy-of select="$변수명"/> </엘리먼트>

ex. <xsl:copy-of select="$vSize"/>



3) 변수 사용 범위
▪ global variable : top-level Element 로 작성. Template Rule 위에 작성해도 좋고, 아래에 작성해도 좋다.
▪ local variable : Template Rule 내에서 작성


4) 변수 예제
▪ xml 예제

more..


▪ xsl 예제

<?xml version="1.0" encoding="euc-kr"?>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

 

 <!-- 글로벌 변수 선언  -->

 <xsl:variable name="vList" select="'쇼핑목록'"/>

 <xsl:variable name="vKind">computer</xsl:variable>

 <xsl:variable name="vSize" select="10"/>

 <xsl:variable name="vCompany">

       <font color="blue">Cheap</font> Company
 </xsl:variable>

 

 <!-- 시작 템플릿   -->

 <xsl:template match="/">

    <html>

       <body>

          <!-- 컨텐트 내용으로 사용  -->

          <h2><xsl:value-of select="$vList"/></h2> 

                   

          <!-- XPath 표현식에서 사용 -->

          <xsl:for-each select="//product[@kind=$vKind]">

                          

             <!-- 속성값으로 사용  -->

             <font size="{$vSize}"> 

                 <xsl:value-of select="title"/>

             </font>

             <br/>

          </xsl:for-each>

                   

           <!-- result tree 일부분을 이루는 엘리먼트로 구성될 변수값 사용 -->

          <xsl:copy-of select="$vCompany"/>

       </body>

</html>

</xsl:template>

</xsl:stylesheet>


▪ 결과
사용자 삽입 이미지

▪ <xsl:copy-of select="$vCompany"/> → <xsl:value-of select="$vCompany"/> 로 변경하면
font가 적용되지 않고 텍스트만 결과로 출력된다.


2. 파라미터
==============================================================================================

: 현재 템플릿 룰에서 다른 템플릿 룰을 적용할 때 전달하고 싶은 데이터가 있을 경우

1) 파라미터 선언

<xsl:param name="파라미터명" select="파라미터값"/> 

<!-- 파라미터값으로 빈 문자값을 줄 경우 -->
<xsl:param name="파라미터명" select="''"/> 
<xsl:param name="파라미터명"/>


2) 파라미터 전달

▪ xsl:with-param 엘리먼트는 xsl:apply-templates엘리먼트와 xsl:call-template 엘리먼트의 자식 엘리먼트로 작성된다.

▪ select 속성값으로 엘리먼트 노드, 텍스트 노드 모두 가능하다.
  또한 꼭 소스 트리에서 올 필요는 없고, 문자열을 넘겨도 좋다.
  ex. 엘리먼트 노드일 때 : <xsl:with-param name="pTitle" select="title"/>
        텍스트 노드일 때   : <xsl:with-param name="pTitle" select="title/text()"/>
        문자열일 때           : <xsl:with-param name="pTitle" select="'문자열 파라미터이다'"/>
   
▪ xsl:apply-templates엘리먼트 : match 속성 갖는 다른 템플릿 룰을 적용
<xsl:apply-templates match="대상 노드">
        <xsl:with-param name="파라미터명" select="전달할 데이터"/>
</
xsl:apply-templates>


▪ xsl:call-templates엘리먼트   : name 속성 갖는 다른 템플릿 룰을 적용

<xsl:call-template name="Template Rule name">
        <xsl:with-param name="파라미터명" select="전달할 데이터"/>
</
xsl:apply-template>


3) 파라미터 사용

<xsl:template ~>
       <!-- 파라미터 선언 -->
      <xsl:param name="파라미터명"/>
       <!-- 파라미터 사용 -->
         .....
<xsl:template>


4) 예제

<xsl:template match="book">

          <!-- 파라미터 값 전달 -->

          <xsl:call-template name="tBook">

                  <xsl:with-param name="pTitle" select="title"/>

          </xsl:call-template>

</xsl:template>

 

<xsl:template name="tBook">

          <!-- 파라미터 선언 -->

          <xsl:param name="pTitle"/>   
         
<!-- 파라미터 사용 -->       
         
<xsl:value-of select="$pTitle"/>

</xsl:template>





◆ XSL 문서의 결합

: 외부 XSL 문서를 참조

1. xsl:include 엘리먼트
==============================================================================================
: Top-level 엘리먼트로서 작성된다.
  다른 Top-level 엘리먼트 (ex. Template Rule) 의 정의가 앞이나 뒤에 있어도 상관 없다.
<xsl:include href="uri-reference"/>



2. xsl:import 엘리먼트
==============================================================================================
: 다른 Top-level 엘리먼트보다 먼저 작성되어야 한다.
  여러 개 작성할 수 있다.

<xsl:import href="uri-reference"/>


▪ 참조하는 문서와 참조되는 문서에 같은 match 속성값이 정의되어 있을 경우,
  참조하는 XSL 문서의 Template Rule 이 적용된다.

신고
TAG xsl

튜닝이론

JAVA/framework 2008.04.08 18:12
성능 튜닝에 관한 글을 요청받고 어떤 글을 쓸까, 과연 글을 쓸 만한 기술이 있을까, 쓴다면 독자들에게 어떤 이야기를 들려줄 것인가를 생각하게 되었다. 엔지니어적 관점에서 성능이라는 주제는 고도의 기술과 논리적 사고를 요하는 흥미로운 분야이지만, 한편으로는 방대한 배경 지식을 요하는 분야이고 체계적인 방법으로 접근하고 논하기에도 힘든 분야이다.

물론 성능 튜닝 분야에서도 IT 엔지니어의 양적인 팽창과 인터넷의 혁명으로 특정 솔루션 튜닝 기법과 실무 사례들은 주위에서 쉽게 구할 수 있다. 그럼에도 불구하고 끊임없이 성능상의 문제가 발생하는 이유는 무엇인가? 기본적인 솔루션의 튜닝 지식에도 불구하고 실제 튜닝을 할 수 없는 이유는 무엇인가?

필자의 경험으로는 성능에 관한 이해 부족과 문제를 체계적으로 해결할 수 있는 방법론의 부재라고 생각한다.

필자는 또 한번 고민에 부딪혔다. 바로 방법론과 기본 지식 중 어떤 분야를 이 글에서 이야기할 것인가를 고민했고, 결과는 기본 지식을 이야기하기로 결정했다.

그 이유는 “테스팅은 방법론적 접근이 가능하지만 튜닝은 예술”이라는 격언과(섣부른 접근보다는 기회가 주어진다면 진지한 접근을 하고 싶다. 책 한권 분량은 되지 않을까?) 기본 지식에 관해 다시 한번 음미하는 기회를 가지는 것이 ‘왜 튜닝을 하는가?’란 이 글의 화두와도 어울린다고 생각했으며, 무엇보다 중요하다고 생각하기 때문이다.

필자가 튜닝에 관해 조금 안다고 자부하던 시절, 다음과 같은 충격적인 질문을 받았다. “시스템을 모니터링할 때 왜 CPU 사용량이 70~80%일 때 CPU 병목이라고 하나요? 50%도 아니고 60도 아니고 70~80%인 이유는 무엇인가요?” 이러한 질문에 필자는 그 당시 어물쩡 넘어갔지만, 한 동안 “내가 성능을 정말 이해하고 있는 게 맞는 것일까”하는 자괴감을 안겨 주었다.

필자가 즐겨보는 ‘CEO 익스체인지’라는 텔레비전 프로그램에서 헤드헌팅 회사의 CEO는 다음과 같은 질문을 헤드헌팅 대상자에게 주로 건넨다. “당신이 자기 자신에게 가장 큰 오해를 하고 있는 것은 무엇인가?” 이제 우리가 이러한 질문을 자신에게 물어봐야 할 시점이 된 것 같다. “당신이 성능에 관해 가장 큰 오해를 하고 있는 것은 무엇인가?”

에피소드 1. CPU 사용량 80%의 함정
왜 80인가에 관한 의문을 풀기 위해서는 다소 딱딱한 그렇지만 재미있을 수도 있는 큐잉 이론(Queueing theory)이라 불리는 수학적인 이야기를 하기로 하자.


<그림 1> 큐잉 이론

<그림 1>은 시스템의 상태(state)를 서비스 요청(request)의 개수로 그린 그림이다. 서비스 요청 개수의 예로는 CPU 자원인 경우 CPU 할당을 기다리고 있는 프로세스의 개수이며, 웹서버의 경우 사용자로부터 요청된 URL의 개수라고 할 수 있다. 원으로 표시된 상태는 서비스 요청이 K일 경우 시스템의 상태를 표시한다. λ는 새로이 발생되는 요청 개수이며, μ는 처리된 요청 개수로서 단위는 request/sec이다.

새로 발생되는 서비스 요청과 처리된 요청에 따라 시스템의 상태는 변화하게 된다. 바운더리로 표시된 영역은 새로이 발생된 요청의 개수와 처리된 요청의 개수가 균형을 이루는 경계들을 표현하고 있으며, 이러한 상태는 ‘operational equilibrium’이라 한다.

‘operational equilibrium’에 관심을 가지는 이유는 옆의 그림과 같이 설명될 수 있다. 만약 flow-in이 flow-out보다 지속적으로 많은 불안정한 관계가 지속될 경우 댐은 붕괴된다(컴퓨터 시스템의 경우 크래시 또는 다운될 것이다).

우리는 댐이 붕괴되는 시점을 모델링하고 싶은 것은 아니므로, 특정한 시점에서 flow-in과 flow-out이 균형을 이룬다고 가정할 경우 시스템의 상태는 다음과 같다(몇 가지 가정이 더 있지만 이 글에서는 생략한다. 더 자세히 알고 싶은 독자는 큐잉 이론을 참고하기 바란다).

P0는 시스템이 서비스를 하고 있지 않는 상태를 의미하므로 시스템의 사용량은 다음과 같다.
시스템 상에 존재하는 요구(requests) 개수의 평균 값은 다음과 같다.

시스템의 평균 응답시간을 사용률과 서비스 시간으로 표현하면 다음과 같다.
T는 단위시간당 처리량(troughput)을 의미한다. Little‘s law에 따라 N=TR로 표시할 수 있는데 그 의미는 단위 시간당 시스템에 존재하는 평균적인 요청의 개수는 단위 시간당 처리량과 서비스 시간의 곱과 같다는 것이다. 단일 요청의 평균 서비스 시간을 S=1/μ이라 가정한다. 즉, 1초에 2개의 요구가 처리되면, 평균적인 서비스 시간은 0.5초라고 가정할 수 있다. S는 다음 그래프에서 실제 상수로서 작용하게 된다.


<그림 2> 사용량과 서비스 시간의 상관관계

<그림 2>에서 볼 수 있듯이 응답 시간은 사용량(utilization)의 임계값을 지나게 될 때 급격히 증가하게 된다. 사용량의 임계값은 이론적으로는 80% 내외에서 형성이 된다(실제 시스템에서 임계값은 여러 가지 복합적인 요인이 작용하게 된다). 따라서 CPU 사용량이 80%를 초과하면 CPU로 인한 반응 시간(response time)이 발생될 수 있다.

복잡한 공식을 살펴봤으니, 한 가지만 더 생각해 보기로 하자. 흔히 튜닝과 관련된 책을 읽어 보면 CPU 부분에서 큐(queue)에 있는 프로세스의 개수가 CPU당 약 4개 이상일 경우 CPU 병목이라고 한다. 그 이유에 관해 생각해 보라(물론 대부분의 퀴즈가 그렇듯 과도한 힌트을 주기로 한다. 공식을 음미해 보라). 그런데 CPU 사용량이 80% 이상이거나 CPU 큐에 대기하고 있는 프로세스의 수가 4개 이상일 경우 CPU로 인해 성능 저하가 발생되었다라고 말할 수 있는가?

우리가 CPU 사용량이 80%이거나 CPU 큐에 있는 프로세스의 수가 4개 이상일 경우 병목이라고 판단한 근거는 무엇인가? 바로 응답 시간의 급격한 저하이다. 그런데 실제 시스템에서는 응답 시간의 급격한 증가는 시스템에 가해지는 부하의 특징 및 각 요청을 처리하기 위한 리소스들(CPU, 메모리, 디스크…)의 사용량의 차이 등에 따라 병목을 나타내는 임계점은 크게 변하게 된다.

예를 들어 하나의 요구를 처리하기 위해서『1/100초의 CPU 사용 → 1/50초의 디스크 사용 → 1/100초의 CPU 사용』을 필요로 한다고 하자(편의상, context switch 시간은 0이라고 가정한다). 단위 시간당 50개의 요청이 발생한다고 가정할 경우 CPU 사용량은 100을 유지하고, 대기하고 있는 프로세스의 개수는 49개를 유지하지만 요청의 수행시간은 저하되지 않는다.

실제로 CPU 사용량이 90% 이상에서 10개 이상의 프로세스가 대기하고 있어도 웹서버의 로그를 분석해 보면 응답 시간이 크지 않은 경우가 많이 발생한다. 따라서 다음과 같은 접근 방법이 올바르다고 할 수 있다.

시스템에 접수된 서비스 요청들의 수행 시간이 고객이 요구한 시간보다 과도하게 길어진 상황이 발생해 시스템 상황을 모니터링해 보니 다른 리소스(메모리, 디스크, …)들은 정상적으로 작동되는데 CPU의 사용량이나 큐에서 대기하는 프로세스의 개수가 과도하게 커서(통상적인 임계값은 무의미할 수 있다) CPU를 증설하였더니 문제가 해결되었다. 그러므로 CPU 병목으로 인한 시스템의 병목이 발생되었다.

성능 관점에서 리소스의 사용량과 반응 시간의 관계에서는 반응 시간이 우선한다. 다음과 같은 추가 질문으로 시스템의 모니터링 값을 볼 경우를 생각해 보자(역시 성능에 관한 진지한 이해가 우선 선행되어야 한다는 것을 강조한다).

“시스템 성능의 기준이 응답시간이 아닌 처리량이라면 임계값과 성능과의 상관관계는 어떻게 될 것인가?”, “Context time이 10,000 이상일 경우 성능 저하가 발생된다고 알려져 있다. 그 근거는 무엇일까?”

에피소드 2. 모니터링을 통해 시스템을 이해할 수 있다?
이제 시스템 모니터링시 보여지는 값들에 관해 생각해 보기로 하자. 다음과 같은 질문을 받았다고 가정하자. “CPU 사용량은 크지 않는데 CPU 사용을 대기하고 있는 프로세스의 개수는 많은 현상이 발생되고 있다. 그 원인은 무엇인가?”

상식적으로 생각해 볼 때 CPU 사용을 대기하고 있는 프로세스의 개수가(lock이 없다고 가정한다면) 1개 이상이면 CPU 사용은 100% 이상이어야 할 것이다. 이 질문에 답하기 위해서 우리는 성능을 모니터링하기 위해 사용하는 명령어가 어떻게 만들어져 있는지 생각할 필요가 있다.

운영체제(OS)는 주기적으로(보통 1/100초마다) 시스템의 상황을 체크해 성능 관련 정보를 저장한다. 우리가 사용하는 iostat, vmstat, sar와 같은 명령어는 OS상의 성능 관련 데이터에 접근해 해당하는 정보를 읽어와 적절히 가공한 후 사용자에게 보여준다.

vmstat을 사용해 CPU 사용량을 모니터링할 경우 CPU 관련 큐에 관련된 정보는 /usr/include/sys/sysinfo.h에 정의되어 있는 sysinfo 구조체를 사용해 OS에 저장된 CPU 사용 관련 정보를 읽어 온다.

typedef struct sysinfo { /* (update freq) update action */
ulong updates; /* (1 sec) ++ */
ulong runque; /* (1 sec) += num runnable procs */
ulong runocc; /* (1 sec) ++ if num runnable procs > 0 */
ulong swpque; /* (1 sec) += num swapped procs */
ulong swpocc; /* (1 sec) ++ if num swapped procs > 0 */
ulong waiting; /* (1 sec) += jobs waiting for I/O */
} sysinfo_t;

앞에서 보이는 CPU 큐에 관련된 정보는 1초에 한번씩 업데이트가 된다. 솔라리스의 경우 CPU 사용률(user, sys, idle)에 관련된 정보는 kstat이라는 구조체를 이용해 가져오는데, 관련 정보는 OS가 주기적으로(보통 1/100으로 설정되어 있다.

1초 단위로 계산한다면 우리가 표시하는 %와 일치하는 사용률을 보이게 된다) 검사해 CPU를 점유하고, 사용되는 프로세스가 존재하면 커널과 사용자 프로세스로 구분해 해당 CPU 사용량을 1 증가하고 프로세스가 존재하지 않는다면 변경하지 않는다. vmstat을 사용해 5초마다 CPU 사용량을 본다면 kstat의 CPU 사용량을 5로 나누어 화면에 표시하게 된다.

정리하면 vmstat에서 표시되는 CPU 사용량은 1/100초로 샘플링이 되는 값을 사용하고, CPU 큐에 관련된 정보는 1초마다 업데이트 되는 정보를 사용한다. 다음과 같은 경우를 생각하자.

0초에 CPU 큐에 대기하는 프로세스의 수를 10개라고 하고 각 프로세스는 1/100초 후 종료된다고 가정하자. vmstat을 사용해 1초 간격으로 모니터링을 한다면 결과는 CPU 큐에 대기하는 프로세스의 개수는 10으로 CPU 사용량은 10%로 나타날 것이다.

이번에는 1/100초에 CPU 큐에 대기하는 프로세스의 수를 10개라고 하고 각 프로세스는 1/100초 후 종료된다고 가정하자. vmstat을 사용해 1초 간격으로 모니터링을 한다면 결과는 CPU 큐에 대기하는 프로세스의 개수는 0으로 나타날 것이며 CPU 사용량은 10%로 나타날 것이다.

실제로 시스템 모니터링은 CPU, 캐시, 메모리, 디스크, 네트워크 부분에서 광범위하게 이루어지며, 사용자의 요청들의 합인 워크로드의 성격 또한 다양하므로 모니터링 값을 정확히 이해하는 것은 생각보다 난해한 일이 될 수 있다.

앞의 예와 같이 모니터링 명령어를 통한 값을 통해 시스템의 상태를 파악하기 위해서는 모니터링 명령어의 작동 방법에 관한 정확한 이해와 시스템에 가해지는 부하의 특징(workload)에 관한 이해가 필수적이다.

에피소드 3. 만병통치 쓰레드?
필자는 몇 년 전 다음과 같이 말하는 업체 관계자를 만난 적이 있다. “본사의 웹서버 제품인 X는 쓰레드 방식으로 작동되므로, 프로세스 방식으로 작동되는 아파치보다 뛰어난 성능을 보인다. X 웹서버는 대용량에서 더욱 뛰어난 성능을 보여준다. <그림 3>는 그것을 증명하는 벤치마킹 결과이다.”


<그림 3>벤치마킹 결과

<그림 3>에서 사용자가 600명인 구간에서 아파치의 성능이 급격히 저하됨을 보여주고 있다. 그 원인은 무엇일까?

일반적으로 쓰레드가 프로세스에 비해 성능상의 우위를 가지는 데, 그 이유는 context switch시 교체되어야 될 정보가 적기 때문이다. 벤치마킹의 결과를 볼 때 대용량의 부하에서 과도한 context switch로 인해 웹서버 X의 성능이 우수한 것으로 보여진다(물론 이렇게 단순하다면 필자가 쓰지 않았을 것이다). 진실은 무엇일까?

진실은 벤치마킹 대상 서버가 메모리 250MB의 워크스테이션이라는 것에서 출발한다. 아파치 프로세스의 크기를 0.5MB라고 하자. 접속하는 클라이언트가 증가함에 따라 아파치는 새로운 프로세스를 생성해 서비스를 하게 된다.
<그림 4>에서 성능이 급격히 저하되는 클라이언트 600의 환경에서 프로세스가 300개 정도 만들어 졌다고 가정하면, 150MB의 메모리가 필요할 것이다. 기타 프로그램이 사용하는 메모리의 양을 100MB 정도라고 한다면, 전체 메모리의 사용량은 250MB 정도가 될 것이고, 프로세스가 추가 생성됨에 따라 paging fault나 swapping이 일어남을 예측할 수 있다.


<그림 4>프로세스 vs. 쓰레드

현재 아파치가 운영되는 환경의 메모리는 대부분의 경우 2GB 이상의 메모리를 가지고 있으므로 이러한 상황은 발생되지 않을 것이며, 실제 운영시에도 웹서버 X와 아파치의 성능상의 차이는 크지 않을 것으로 예상할 수 있다.

자, 이제 조금만 더 생각해 보기로 하자. 쓰레드와 프로세스는 과연 성능상의 큰 차이가 나지 않는 것일까? 일반적으로 한 개의 서버에는 여러 솔루션이 설치된다. 이 경우 메모리는 아껴 써야만 하는 자원이 될 수가 있다. 또한 웹서버에 php, Perl과 같은 CGI 서비스나 웹 애플리케이션 서버(WAS)와의 연결을 위한 모듈이 추가될 경우 프로세스의 크기가 1MB 가까이 되는 경우가 있다.

이러한 상황은 메모리 부족이 발생될 수 있으며, 쓰레드 방식의 웹서버를 사용했다면 발생되지 않았을 성능상의 문제가 아파치에서는 발생될 수 있다. 물론 메모리를 증가시켜주면 대부분의 문제는 해결될 것이다.

이번에는 반대로 아파치에서는 발생되지 않았던 문제가 쓰레드 방식의 웹서버에서 발생된 경우를 생각해 보자. 필자가 수행한 SWAT 활동 중 아파치에서 쓰레드 방식의 웹서버로 교체한 후 클라이언트로부터의 요청이 증가함에 따라 웹서버가 다운되는 문제가 발생한 적이 있다. 우선적으로 시스템 설정을 조사했는데 별다른 문제점은 없었다. 웹서버의 로그를 조사한 결과 소켓이 열리지 않아 시스템이 다운되는 현상이 보였다.

바로 웹서버는 클라이언트 및 기타 솔루션과 통신하기 위해 소켓을 주로 사용하는데 유닉스에서 소켓은 파일로 인식됨으로 소켓이 열리지 않는다는 것은 프로세스가 열 수 있는 파일의 최대 개수와 관련된 설정에 문제가 있다고 추측할 수 있었다.

그런데 시스템 설정을 조사할 경우 해당 환경 변수가 적절히 설정되어 있었다. 혹시나 하는 마음에 운영자에게 환경 변수가 설정된 후 시스템을 재부팅한 적이 있느냐고 물어 보았더니 없다고 하였다. 바로 해당 환경 변수는 재부팅이 되었어야만 적용이 되는 변수였던 것이었다.

그럼 아파치에서는 왜 동일한 문제가 발생되지 않았던 것일까? 그 이유는 프로세스 방식에서는 각각의 프로세스가 각자 file descriptor를 관리하는데 반해 쓰레드 방식에서는 file descriptor를 공유하기 때문이었다. 즉 n개의 file descriptor를 m개의 쓰레드가 공유함으로 열 수 있는 파일의 개수가 실질적으로 감소하기 때문이다.

에피소드 4. 성능 튜닝 툴, 어디에 쓰는 물건인고?
솔루션의 성숙과 더불어 각종 툴의 도움으로 쉽게 시스템의 상황을 파악할 수 있게 되었다. 실제 WAS의 경우 관리와 성능 분석 도구가 주요 상품화되고 있으며, 오라클 DB의 경우 써드 벤더 도구들의 기능을 오라클 DB가 내장하는 수준으로 발전하고 있다.

엔지니어 특유의 고집으로 인한 모니터링 도구의 거부감에도 불구하고 실제 성능 관련 도구 사용의 작업 효율을 크게 향상시킬 수 있다. 이제 성능 관련 엔지니어에게 더욱 중요한 내용은 논리적인 사고 기반 위에 적절한 명령어와 성능 관련 도구를 이용해 시스템 성능을 분석하는 일일 것이다. 이제 각종 툴을 이용해 어떠한 방식으로 성능을 이해할 것인지에 대해 고민해보자.

전체 시스템의 성능을 분석하기 위해서는 시스템을 구성하는 각 컴포넌트(예 : OS, 웹서버, WAS, DB 등)들의 로그에 관한 이해는 필수이다. 로그에서 중요한 것은 에러, 요구량, 처리량, 그리고 각 요구를 처리하는데 걸린 수행시간이다. 이러한 정보를 이용해 전체 시스템을 구성하는 컴포넌트들 중 성능상의 문제를 유발한 컴포넌트를 발견할 수 있다. 필자가 참여하지는 않았지만 다음과 같은 경우가 있었다.

웹서버, WAS, DB로 이루어진 비교적 간단한 웹서버 구조였는데 성능 상의 문제로 시스템 오픈시 다운되었다. SWAT팀이 출동해 상황을 분석하고 각 솔루션별 튜닝을 마쳤지만 성능은 만족스럽게 향상되지 않았다. 단순한 HTML 파일을 이용해 웹서버에는 문제가 없다는 결론을 내렸고 DB를 이용하지 않는 애플리케이션을 이용해 WAS에도 문제가 없다는 것을 확인했다. 또한 DB를 이용하는 애플리케이션을 이용해 성능 저하가 발생됨을 확인했다.

그런데 DBA에게 문의한 결과 DB상의 로그에는 성능상의 저하가 발생됐다는 증거가 나타나지 않았다는 것이었다. 이제 DBA는 DB에는 문제가 없다고 주장하고 WAS 엔지니어는 WAS에는 문제가 없다고 하고 OS 전문가는 OS에는 문제가 없다고 주장하는 상황이 발생되었다. 그럼 문제는 어디에서 발생했을까?

문제는 해당 WAS의 JDBC 드라이버가 512Bytes로 데이터를 전송하는 것이었다. 이 경우 각 패킷의 헤더 정보의 비중이 과도하게 커져 네트워크 병목을 유발할 수 있다. 각 네트워크 노드마다 MSS(Maximim Segment Size)라 불리는 전송 가능한 최소 패킷 사이즈가 있는데, 네트워크 통신 초기에 auto-negotiation으로 단말 노드 간에 MSS가 설정된다.

문제는 단말 노드 사이의 네트워크 장비가 auto-negotiation을 지원하지 않는 경우 네트워크 장비는 이동시켜야 할 패킷이 자기가 처리할 수 없는 크기이면 패킷을 조각내고 합치는 작업을 해야 한다는 것이며 이는 성능 저하로 유발된다(조각내고 합치는 것도 불가능하다면 패킷을 손실될 것이다).

512bytes는 원시시대부터 지원된 가장 작은 패킷 사이즈이며 모든 네트워크 장비가 지원하고 있다. 친절하게도 JDBC는 모든 장비가 지원하는 512bytes로 데이터를 전송했지만, 현재 네트워크 장비를 고려할 때 512bytes는 헤더로 인해 너무나 낭비가 심한 크기의 패킷이다. 실제 이런 부분은 대단히 발견하기가 힘든 튜닝 사항이다. 역시 문제의 원인이 되는 컴포넌트 발견시에도 전산 환경에 대한 깊은 이해가 필요한 것 같다.

그럼 여기서 추가 질문. 웹서버상의 로그를 보면 전송된 데이터의 크기를 볼 수 있다. 웹서버 로그에 index.html이 1KB라고 기록됐다면 이는 실제 index.html 파일의 크기일까 또는 네트워크를 실제 사용한 크기일까? 만약 웹서버상의 index.html 파일이 1KB라면 네트워크를 점유하는 데이터의 크기는 얼마일까? 100Mbps의 네트워크를 사용한다면 1초동안 전송 가능한 최대 index.html은 몇 개가 될까?

유닉스 또는 다른 OS에서 제공하는 기본적인 기능 외에 사용자 편의를 위한 다양한 명령어를 ‘유틸리티’라고 한다. 성능과 관련되어 다양한 명령어가 있지만 앞에서도 언급했듯이 명령어에 관한 정확한 이해는 필수이다.

turss를 이용해 유닉스상에서 프로세스가 호출하는 시스템 콜을 이해할 수 있지만 이는 과연 튜닝에 얼마나 도움을 줄까(필자의 경험으로는 한번 뿐이었는데, OS상에서 환경 변수 설정은 정상으로 되었지만 패키지 형태의 솔루션이 시작되면서 setsockopt() 시스템 콜을 사용해 환경 변수를 변경함으로써 패키지가 정상적으로 작동되지 않는 경우였다).

crash를 통해 얻을 수 있는 정보는 무엇인가? Profiler를 통해 얻을 수 있는 정보는 과연 소스에 코드를 넣어 로그를 남기는 방법보다 좋다고 말할 수 있을까(필자의 경험으로는 소스에 로그 코드를 추가하는 방법이 효과적인 경우가 더 많았던 것 같다)? 유틸리티와 성능 관련 도구를 통해 우리가 얻을 수 있는 정보에 관한 정확한 이해는 성능 튜닝 작업을 위한 필수 지식이라고 할 수 있겠다.

필자는 개발자와 작업을 하면서(필자가 개발자이기도 하다) 각자가 작성한 코드를 서버에 설치하도록 하고 간단한 부하 도구를 이용해 성능을 분석하도록 한 적이 있다. 결과는 대 성공이었다. 부하 도구는 개발자가 사용하기에 어려움이 없었고 측정해야 할 요소(Max TPS)는 쉽게 이해할 수 있는 수준이었으며 개발자는 자기 자신의 소스 코드에 대해 성능 관점에서 진지하게 접근했다.

그리하여 필자가 생각하게 된 것은 성능 관련 툴의 발전을 개발 방법론상에 어떻게 접목시킬 것인가 하는 것이었다. clean room project나 XP와 같이 철저한 테스팅 수준으로 가지는 않더라도 개발자들이 자기 자신의 코딩에 관한 간단한 성능 검증을 직접 함으로써 얻을 수 있는 이익은 어떤 튜닝보다 효과적일 수 있다. SWAT가 코드를 직접 분석하기에는 시간이 너무나 걸리고 개발자들이 SWAT에 협조하기에 그들은 너무 바쁘다.

성능 튜닝의 현재와 미래
필자는 오라클, DB2, 그리고 이제는 너무나 일반화가 되어버린 WAS의 엔지니어를 만나면 농담 반 진담 반으로 “이제 성능 튜닝도 솔루션 자체가 스스로 하는데, 엔지니어도 몇 년 후에는 굶어죽겠군”이라는 이야기를 하게 된다.

이러한 이야기를 하게 되는 배경에는 무엇보다도 2000년대를 대표할 전산 환경으로 기억될 웹 기반 시스템의 각 솔루션(웹서버, WAS, DB)이 성숙기를 지남에 따라 기능이 안정화되고, 그에 따라 성능 부분에서도 일정 부분은 스스로 최적화가 되거나 별도의 튜닝이 없어도 웬만큼 버티는(?) 단계로 접어들었기 때문이라고 생각된다. 또한 해당 솔루션이 대중화됨에 따라 초·중급 수준의 엔지니어는 포화 상태를 이루고 있기 때문이다. 그러면 성능과 관련된 제품의 성숙도와 주요 업체들의 향후 방향성은 무엇일까?


<그림 5> 리얼타임 인프라스트럭처 기술의 Hype 사이클(출처:가트너 그룹)

<그림 5>의 Hype 사이클에서 세로축은 사람들의 기대치를 나타내며 가로축은 성숙도를 나타낸다. 기술이 시장에 처음 소개될 때 기대치는 실제 성숙도 이상으로 상승하게 되어 거품을 이루게 된다. 특히 서버 리소스 매니지먼트(server resource management)/워크로드(workload) 관리가 거품의 정점에 있다고 할 수 있다. 이후 사람들이 현실을 깨달음에 따라 기대치는 급속도로 냉각하게 되며, 제품(기술)이 시장에서 살아남는다면 기대치의 완만한 상승을 성숙도가 만족시키면서 안정화 단계를 이루게 된다.

현 IT 시장에서의 화두는(적어도 업체 입장에서는) 리얼 타임이라고 할 수 있는데, 업체들의 사업 방향과 역량에 따라 e비즈니스 온디맨드(on-demand, IBM), 어댑티브 컴퓨팅(Adaptive computing, HP), N1(썬)이라는 용어로 표현되기도 한다(각각의 내용은 사실상 조금씩의 차이가 존재하지만 공통된 목적은 동일하다).

리얼 타임이라는 용어는 가트너에서 주창한 용어인데, “기업이 원하는 전산 환경을 즉시즉시 제공해 준다”라는 의미이다. 물론 제공할 대상은 컨설팅을 포함한 광범위한 분야인데, 이 글에서 관심을 가지고 있는 성능과 관련된 인프라스트럭처 분야는 리얼 타임 인프라스트럭처(Real time infrastructure)라는 용어로 표현된다.


<그림 6> 자율적 컴퓨팅(Autonomous computing, 출처 : IBM)

인프라스트럭처 분야로 한정될 경우 리얼 타임의 의미는 기업이 원하는 “전산 환경의 리소스를 즉시즉시 제공해 준다”는 의미를 지니고 있는데, 이는 대부분의 설정이 자동화되고 문제 발생시 솔루션이 직접 해결하며, 스스로 최적화되고 보안이나 기타 외부의 이상 환경으로부터 스스로를 보호한다는 것을 나타낸다. 바꾸어 말하면 문제 발생시 엔지니어를 부르기 위해 며칠이 소비되고 해결하는 데 며칠이 걸린다면 리얼 타임이라 부를 수 없으며 이는 기업 운영에 치명적으로 작용할 수 있다는 것이다.

물론 과거의 많은 경험들로 미루어 볼 때 관련 업체들의 미사여구가 나열된 선언적 부분이 상당히 있겠지만, 가트너의 Hype 사이클을 보면 관련 기술의 대부분이 5년 이내에 성숙될 것으로 예측됨을 알 수 있다. 실제 이는 기본적인 전산 상식으로 유추할 수 있는 내용인데, 각 솔루션의 전문가들은 이미 시장에 존재하며, 인공지능 분야 중 전문가 시스템을 이용해 전문가들의 문제 해결 능력은 모델링 되어 솔루션에 추가될 수 있다.

물론 최고급 전문가들의 최고급 기술이 솔루션에 탑재되기는 힘들다. 그러나 전산 시스템을 운영하는 기업 입장에서는 자동으로 작동되는 솔루션과 향상된 컴퓨팅 파워 환경에서 초·중급 엔지니어의 고용에 심각한 회의를 하는 시점이 도래할 것으로 예상된다(물론 현재 부분적으로 일어나고 있는 상황이기도 하다. 유닉스와 비교할 때 윈도우 운영시 전문 엔지니어의 필요성이 감소되는 것은 엄연한 사실이 아닌가).

이와 같은 긍정적인(?) 방향에도 불구하고 시스템 오픈시 성능 문제로 인해 다운이 되는 현상이 반복되는 이유는 무엇일까? 여러 가지 해석이 가능하겠지만 필자의 견해로는 실제 성능은 개별 솔루션의 성능 튜닝 이상을 의미하는 상황에서 전체 시스템의 복잡도가 증가되기 때문이라고 생각된다.

성능 관점에서 볼 때 웹 환경만 하더라도 단순한 구성(웹서버 - WAS- DB)에서 여러 가지 솔루션(LDAP, 인증서, SSL, 방화벽, 바이러스 백신 등)이 혼재된 형태로 발전되고 있다. 클러스터링을 통해 데이터베이스의 성능은 높아졌지만 클러스터링된 노드간의 간섭을 줄이기 위하여 파티셔닝을 하기 위한 디자인 능력은 더욱 요구되고 있다.

응용 프로그램 개발시 컴포넌트나 프레임워크를 이용한 표준화를 통해 성능 관련된 많은 부분들이 미연에 방지되고는 있지만, 수준 있는 애플리케이션 아키텍처는 여전히 부족할 뿐만 아니라 시스템이 복잡해짐에 따라 표준화할 수 없는 부분이 증가되고, 여전히 개발 기간은 부족하고 방법론은 체계적으로 적용되고 있지 못하다.

요약하면 솔루션의 진화와 컴퓨팅 파워의 향상으로 개별 솔루션의 예술가적 튜닝 요구는 줄어들겠지만, 아키텍트적인 관점에서 전체 시스템의 디자인과 성능과 관련된 프로젝트 관리상의 요구는 증가될 것으로 예상된다. 엔지니어 입장에서는 높은 곳에서 전체 시스템을 전망할 수 있는 능력을 더욱 요구받게 된 것이다. 높은 곳으로 가기위해서는 체력과(기본 지식) 올바른 길(문제 해결을 위한 최선의 방법)이 필수적으로 필요함을 다시 한번 이야기 해 두고 싶다.

존재의 이유
필자가 접하게 된 최근 IT 환경의 가장 큰 변화는 고객이 무척 똑똑해졌다는 것이다. 그들은 단순히 서버를 증설해야 한다는 엔지니어 주장을 믿지 않을뿐더러(옛날에도 믿지 않았지만), 이론적 설명을 요구하기도 한다. 이러한 변화의 가장 큰 이유는 IT에 관한 ‘묻지마 투자’에서 ROI(Return Of Investment) 관점에서의 철저한 분석이 선행된 투자를 하도록 기업 환경의 경쟁이 심화되고 있다는 것이다.

필자가 만난 모 기업의 전산 담당자는 다음과 같은 말했다. “서버 증설을 위해 임원진에게 건의를 했더니 임원이 서버 증설을 해야 하는 이유를 논리적이거나 수학적으로 증명을 해달라고 한다. 나도 답답하다. 임원에게 CPU 사용량이 90%이므로 증설해야 한다고 해도 받아 들여지지 않는다. 전산 투자를 해야하는데 우리도 답답하다.” 결국 기존의 로그를 분석해 사용량의 증가를 예측하고, 시스템을 증설하지 않을 경우 예상되는 손실을 계산하고 이를 증설될 서버의 가격과 비교하였다.

물론 엔지니어 각자의 임무와 취향에 따라 앞의 상황에 대한 해석이 틀려지겠지만, 성능 관련 엔지니어에게도 단순한 파라미터 조작을 통한 솔루션 튜닝 이상의 무엇을 통해 각자의 존재 이유를 증명해야 될 시대가 도래하고 있는 것은 틀림없는 것 같다.

이 글의 결말을 어떻게 낼까 고민하다 다음과 같은 말이면 어떨까 생각하게 되었다. “제임스 고슬링이 자바를 개발했다고 하는데 설마 제임스 고슬링이 날 코딩했겠냐(물론 코딩을 못한다는 얘기가 아니다). 그가 자바를 개발하면서 무슨 일을 했을까를 생각해 봐야 한다. 그것을 통해 우리가 생각하는 엔지니어의 미래를 고민해 보자.”@

* 이 기사는 ZDNet Korea의 자매지인 마이크로소프트웨어에 게재된 내용입니다.
신고

Junit 사용법

JAVA/framework 2007.12.06 14:34
   
  • Junit 3.8
  1. public class TestConvert extends MyTestCase { // TestCase 상속
       
        private boolean t = DES.t;
        private boolean f = DES.f;

        public TestConvert(String name) { // 생성자
            super(name);
        }

        protected void setUp() throws Exception { // 한 메소드 수행전에 실행되는 메소드
            super.setUp();
        }

        protected void tearDown() throws Exception { // 한 메소드 수행후에 실행되는 메소드
            super.tearDown();
        }
       
        public void testConvertToBinary() { // 일반 테스트 메소드 - test로 시작작
            String str = "dddddddd";
            boolean[] text = null;
            boolean[] expected = new boolean[str.length()*8];
            boolean[] oneByte = {f,t,t,f,f,t,f,f};
            int j=0;
            for(int i=0, n=str.length(); i<n;i++) {
                for(int k=0; k<oneByte.length; k++) {
                    expected[j++] = oneByte[k];
                }
            }
           
            text = Convert.convertToBinary(str);
            assertByteEquals(expected, text);
        }
       
        public static Test suite() { // 테스트 수위트 형식식
            TestSuite suite = new TestSuite();
           
            suite.addTestSuite(TestConvert.class);

            TestSetup wrapper = new TestSetup(suite) {
                protected void setUp() {
                    oneTimeSetup(); // 테스트 수행 전에 호출되는 함수
                }
                protected void tearDown() {
                    oneTimeTearDown(); // 테스트 수행 후에 호출되는 함수
                }
            };
            return wrapper;
        }

        protected static void oneTimeSetup() {
        }
       
        protected static void oneTimeTearDown() {
        }


  1. public class TestAll extends MyTestCase { // 전체 테스트

    public TestAll(String method) {
            super(method);
        }
       
        public static Test suite() {
            TestSuite suite = new TestSuite();
           
            suite.addTest(TestDES.suite());
            suite.addTest(TestDESKey.suite());
            suite.addTest(TestDESExecution.suite());
            suite.addTest(TestTripleDes.suite());
            suite.addTest(TestAES.suite());
            suite.addTest(TestAesKey.suite());
            suite.addTest(TestAESExcution.suite());
            suite.addTest(TestSecAlgorithm.suite());
            suite.addTest(TestConvert.suite());
            suite.addTest(TestShiftRegister.suite());
            suite.addTest(TestECBmode.suite());
            suite.addTest(TestCBCmode.suite());
            suite.addTest(TestCFBmode.suite());
            suite.addTest(TestOFBmode.suite());
            suite.addTest(TestCTRmode.suite());
            return suite;
        }
       
    }
  • Junit 4.0

    • Jnuit 4.0 뛰어 들기

      • setupBeforeClass
      1. @BeforeClass
      2. public static void setupBeforeClass() throws Exception { }
      • test 메소드
      1. @Test
      2. pubic void ...() {}
      • 예외 테스트
      1. @Test(expected = IndexOutOfBoundsException.class)
      2. public void verify() throws Exception {
      3. Matcher mtcher = this.pattern.matcher("221010-5051");
      4. boolean isValid = mtcher.matches();
      5. mtcher.group(2);
      6. }
      • 제한 시간 테스트
      1. @Test(timeout=1)
        public void verifyFastZipCodeMatch() throws Exception{       
         Pattern pattern = Pattern.compile("^\\d{5}([\\-]\\d{4})?$");
         Matcher mtcher = pattern.matcher("22011");
         boolean isValid = mtcher.matches();       
         assertTrue("Pattern did not validate zip code", isValid);
        }
      • 테스트 무시
      1. @Ignore("this regular expression isn't working yet")
        @Test
        public void verifyZipCodeMatch() throws Exception{       
         Pattern pattern = Pattern.compile("^\\d{5}([\\-]\\d{4})");
         Matcher mtcher = pattern.matcher("22011");
         boolean isValid = mtcher.matches();       
         assertTrue("Pattern did not validate zip code", isValid);
        }
      • setup
      1. @Before or @BeforeClass
      • tearDown
      1. @After or @AfterClass
      • Suit
      1. @RunWith(Suite.class)
        @SuiteClasses({ParametricRegularExpressionTest.class,
              RegularExpressionTest.class,
              TimedRegularExpressionTest.class})
        public class JUnit4Suite {

        }
신고

우선 자신의 JDK에 맞는 JSON LIB가 필요하다.
http://json-lib.sourceforge.net/ 여기에서 받아보자 (jdk 1.3용과 jdk 1.5가 있다.)


json이 여기서 받아야 하는 파일이 끝이라고 생각한다면 오산이다.

오류발생 : java.lang.NoClassDefFoundError: net/sf/ezmorph/MorpherRegistry

이것은 EZmorph가 없어서 발생하는 오류이다.
바로 연관 package가 추가로 더 있는 경우에 해당한다.

http://ezmorph.sourceforge.net/ 에서 추가로 다운받자.


최종!!
 > json-lib-1.1-jdk15-javadoc.jar / ezmorph-1.0.2.jar  2개가 있어야 구동이 가능함.


● 간단 sample 소스코드

 public oid test11DataTest () {
  JSONObject jsonObject = new JSONObject() ;
  jsonObject.put ("subject", "001");
  jsonObject.put ("author", "002");
  jsonObject.put ("date", "003");

  System.out.println("neouser ^^ >>>" + jsonObject.toString());
 }





신고
TAG java, JSON, neouser
Struts 1.1 Tiles-framework에 대한 개요 및 사용방법

이번 아티클은 Jakarta-Struts에 1.1부터 component로 정식포함 Tiles-Framework을 이용하여 Struts을 이용한 template에 대한 설명을 하고자 한다.
만약 당신이 struts를 1.0버젼때부터 사용해봤다면 tiles가 얼마나 강력한 화면 구성도구인지 이미 알고 있을 것이며, 몰라도 새로 배우면 되므로 아무런 상관이 없음을 밝힘다. ^^ ( 2003/07/14 ) 592
Written by ienvyou - 최지웅

1 of 1


이번 아티클은 Jakarta-Struts에 1.1부터 component로 정식포함 Tiles-Framework을 이용하여
Struts을 이용한 template에 대한 설명을 하고자 한다.

만약 당신이 struts를 1.0버젼때부터 사용해봤다면 tiles가 얼마나 강력한 화면 구성도구인지
이미 알고 있을 것이며, 몰라도 새로 배우면 되므로 아무런 상관이 없음을 밝힘다. ^^

▶ About Tiles

사실 기존의 Tiles가 없을때는 struts에서 화면을 구성하는 템플릿에서 org.apache.struts.taglib.template을
이용한 put tag를 이용하여 화면을 조립하였었는데 문제는 화면에 대한 구성을 자유자재로
하지 못하는다는 것을 javapattern.info사이트 구축시에 이미 느꼈었다. 이미 연재한
Mini-Spider Framework에서는 화면구성에 대한 템플릿을 조합하는 serlvet component를 두어서
xml에서 읽어들인 데이터로 layout.jsp를 구성한 다음 뿌려주게끔 만들었었는데 그 부족한 부분을
struts에 채워줬던 것이 바로 tiles-framework이다.

이것은 2002년 1월에 아주 똑똑한 apache-contributor인 Cedric Dumoulin란 사람이 컴포넌트 형대로
처음 소개했고, 2002년 2월에 tomcat에서 tag로 사용되던 것을 struts 1.1버젼의 개발 릴리즈에
포함시키기로 결정되었었다.
현재는 struts API를 봤을때 org.apache.struts.tiles 및 org.apache.struts.tiles.taglib 패키지로
요약되어 지고 있다.

대략 tiles가 가진 기능을 살펴보면 다음과 같다.


우선 tiles에 대한 식별을 한후 그것을 기술하고 당신의 화면형태로 조립하여 사용할수 있다.

이미 기술된 레이아웃에 대하여 재사용 및 템플릿을 관리할 수 있다.

화면단에 대한 tiles의 선언 및 정의를 할 수 있으며, 파라미터 값을 통하여 struts에서
넘어온 값을 변경시킬 수 있다.

새로운 레이아웃 생성 및 객체지향의 상속개념을 통하여 불필요한 선언을 필요없게 만든다.

국제화에 대한 tiles를 생성하여 처리할 수 있다.


▶ Tiles 설정


기본의 Struts1.0을 이용하게 된다면 tiles에 대한 jar파일을 apache foundation에서 다운로드 받아
당연히 WEB-INF의 lib에 복사하여 사용하게 되는데 더 필요한 것을 taglib에 관련한 설정을
이용하여 처리해야 하므로 web.xml에 대하여 uri정보를 설정하던지 아니면 만들어질
페이지에 대하여 적절한 설정을 해주어야 함은 물론이며, 이글을 읽는 당신~! 당연히
할줄 알고 있으리라 놀새는 믿는다.


▶ 첫번째 기본 레이아웃에 대한 설정


우선 가장 기본적으로 우리가 많이 볼수 있는 샘플 화면에 대하여 살펴보도록 하자.
프레임을 좋아하는 사람도 있겠지만 놀새~ 스스로는 single frame안에 layout을 나누어 해당 jsp만
include를 하는 것을 선호하고 있다. 그렇게 하는 게 훨씬 핸들링하기 쉽다고 생각하는데
뭐 개인마다 취향이 틀리므로 아무렇게나 사용하고 싶은데로 쓰면 되겠다.

우선 아래와 같은 형태의 화면 레이아웃이 나왔다고 가정을 하자.

header menu body footer

java.sun.com에서 샘플로 보여주는 petstore에서는 위와 같은 형태를 조합하는 웹페이지조립용
servlet component를 두어 layout으로 설정된 페이지로 무조건 forwarding시키면 거기서 데이터를
로딩된 xml정보를 이용하여 각 영역에 들어가야 할 페이지에 대한 부분을 include시키는 형태를
취하고 있다.

위에서 이야기하는 보통의 header에는 기업의 로고 또는 대분류메뉴들이 들어가게 되며,
거의 바뀌지 않는 내용이 대부분이며, 왼쪽편의 menu파트, 아래쪽의 footer(보통 copyright) 또한
바뀌지 않는 부분이라구 생각해도 된다.

페이지를 조립하는 데 있어서 한가지 주의해야 할 점은 링크부분에 관련한
설정인데 만약 struts의 taglib를 사용하게 되지 않는다면 이미지등의 경로를 입력하는 데 있어서
<img src='<%= request.getContextPath() %>/images/xxx.gif>의 형태로 처리해야 하며
struts taglib를 사용하면 <html:img src="/images/xxx.gif" />의 형태로 만들어줘야 한다.

사실 위의 layout에서 가장 많이 변동되는 부분은 당연히 body부분이 될 것이다.

자 그러면 이제부터 본격적인 tiles의 configure를 작성해보도록 하자.

▶ Page안에서의 Tiles조립


우선 struts에서 화면을 조립할 수 있는 2가지방법이 있다고 위에서 말했는데 template패키지를
이용한 화면조립이 그 첫번째이고 tiles를 이용한 방법이 두번째라고 말했다.

- Tiles선언


<%@taglib uri="/WEB-INF/tiles.tld" prefix="tiles" %>
<tiles:insert page="/basic/myLayout.jsp" flush="true">
<tiles:put name="title"value="My first page" />
<tiles:put name="header" value="/tutorial/common/header.jsp" />
<tiles:put name="footer" value="/tutorial/common/footer.jsp" />
<tiles:put name="menu" value="/tutorial/basic/menu.jsp" />
<tiles:put name="body" value="/tutorial/basic/helloBody.jsp" />
span lang=EN-US></tiles:insert>


- Strus template pacakage선언

<%@taglib uri="/WEB-INF/tiles.tld" prefix="template" %>
<template:insert page="/basic/myLayout.jsp" flush="true">
<template:put name="title"value="My first page" />
<template:put name="header" value="/tutorial/common/header.jsp"/>
<template:put name="footer" value="/tutorial/common/footer.jsp"/>
<template:put name="menu" value="/tutorial/basic/menu.jsp"/>
<template:put name="body" value="/tutorial/basic/helloBody.jsp"/>
</template:insert>


위의 코드에서 보여주는 것은 tiles.tld를 선언하여 put에 대한 tag를 만났을 경우 name에 해당하는
layout페이지의 각 영역에 value값들이 "/tutorial/common/header.jsp"의 형태로 삽입되도록 선언한
것이다.

그렇다면 이제 main layout에 관련한 화면구성의 html template를 먼저 작성해보도록 하자.
이것은 웹디자이너와도 상의를 하여야 할 것이며, 전체 프로젝트에서 화면에 대한 프로토타이핑이
이루어진 시점에서 구성이 되어도 무방할 것이다.


<table border='1' width='300'>
<tr>
<td colspan='2' bgcolor='#CCFFFF'>header
</td>
</tr>
<tr height='200'>
<td width='60' bgcolor='yellow'>menu
</td>
<td bgcolor='#CCFF66'>body</td>
</tr>
<tr>
<td colspan='2' bgcolor='#CCFFFF'>footer
</td>
</tr>
</table>


위의 html형태와 이미 본 그림처럼 설정을 했었는데 위의 각 영역에 붙일 수 있는 tiles를 선언해
보도록 하자.

우선 아래와 같이 tiles taglib를 사용할 수 있도록 먼저 prefix에 대한 선언을 한후

<%@ taglib uri="/WEB-INF/tiles.tld" prefix="tiles" %>

아래와 같이 각각의 영역에 들어갈 attribute들에 대한 선언을 하도록 한다.

<tiles:insert attribute=”body” flush=”true” />

최종적으로 taglib가 포함되어 변경된 html source를 보게 되면


<TABLE width="100%">
<TR>
<TD colspan="2"><tiles:insert attribute="header" /></TD></TR>
<TR>
<TD width="120"><tiles:insert attribute="menu" /></TD>
<TD><tiles:insert attribute="body" /></TD></TR>
<TR>
<TD colspan="2"><tiles:insert attribute="footer" /></TD>
</TR>
</TABLE>


위와 같이 선언된다면 각각의 영역에 그 대표 이름을 붙임으로서 tiles:insert에 대한
tag library가 호출되면 해당 클래스가 config에서 이미 설정된 value를 이용하여
포함된 jsp파일을 각 영역에 include시키는 방법을 사용하고 있다.

화면 조립에 대한 이러한 기본 아키텍쳐가 궁금하다면 먼저 아래의 아티클을 읽은 후 다시 보면
되겠다.

Web Application Framework개발방법(3)-View page Composing

▶ Page안에서의 html page title 세팅

브라우져의 타이틀바에 보여져야 할 내용도 동적으로 변경을 가할 수 있는데 이것 또한
tiles가 제공하는 title tag를 이용하여 처리하면 config에 설정된 내용을 동적으로 가져 올수 있는
특징을 가지고 있다.


<head>
<title><tiles:getAsString name="title"/></title>
</head>


▶ 최종 페이지 구성


위와 같이 구성되어 완성된 템플릿 페이지는 아래와 같다.


<%@ taglib uri="/WEB-INF/tiles.tld" prefix="tiles" %>
<html>
<head>
<title><tiles:getAsString name="title"/></title>
</head>
<body>
<TABLE width="100%">
<TR>
<TD colspan="2"><tiles:insert attribute="header" /></TD></TR>
<TR>
<TD width="120"><tiles:insert attribute="menu" /></TD>
<TD><tiles:insert attribute="body" /></TD></TR>
<TR>
<TD colspan="2"><tiles:insert attribute="footer" /></TD>
</TR>
</TABLE>
</body>
</html>


자, 이제 화면을 구성할 수 있는 layout페이지가 조립이 되었다.
위의 페이지의 이름을 "/layout/classicLayout.jsp"라고 정하자.
이제 그곳에 내용을 입력할 수 있는 두가지 방법이 존재하게 되는데 그 두가지 방법 모두를
한번 살펴보도록 하자.

▶ 가장 기본적인 template삽입방법


우선은 layout페이지가 정의되었을 때 그 페이지의 실제 보여지게 각각의 페이지가 어떤것인지를
알려주어 삽입하도록 하게 하는 방법이다.

위에서 템플릿 파일의 이름을 classicLayout.jsp라고 정의했고, 아래의 파일이름은
실제 최초요청이 들어왔다는 가정으로 index.jsp라고 하자.


<%@ taglib uri="/WEB-INF/tiles.tld" prefix="tiles" %>
<tiles:insert page="/layout/classicLayout.jsp" flush="true">
<tiles:put name="title" value="My first page" />
<tiles:put name="header" value="/tutorial/common/header.jsp" />
<tiles:put name="footer" value="/tutorial/common/footer.jsp" />
<tiles:put name="menu" value="/tutorial/basic/menu.jsp" />
<tiles:put name="body" value="/tutorial/basic/helloBody.jsp" />
</tiles:insert>


위의 프로그램처럼 호출을 하게 되면 tiles의 기본동작은 /layout/classicLayout.jsp를 템플릿으로
기본으로 하여 처음에 설정된 attribute에 해당하는 put name="title"의 값인 value="My first page"를
classicLayout으로 전달하여 title을 설정하고, include되어질 수 있는 페이지는
tiles:put name="header" value="/tutorial/common/header.jsp"처럼 header영역에 뿌려질 값이
/tutorial/common/header.jsp임을 선언하여 넘길 수가 있다.

그런데~~~!!!

위의 방법이 편한가? 만약 layout을 이용한 페이지가 프로젝트 규모에 따라서 수백본이 될텐데
header, menu, footer의 경우처럼 같은 페이지가 삽입된다고 했을 경우 불필요한 copy-paste가
나타나게 되는 건 불을 보듯 뻔한 일이다.

그렇다면 재사용에 대한 효용성을 극대화시키기 위하여 어떤 방법을 사용하면 될까?
Tile에서는 xml파일을 이용하여 layout을 definition할 수 있는 방법을 사용함으로서 같은 부분에
대한 내용을 재사용할 수 있는 효과적인 방법을 제공한다.

페이지를 list형태로 관리하여 각각의 경우에 대한 서로 다른 페이지를 보여줄 수 있는 방법도
존재하지만 그건 각자 알아서 공부하기 바란다.

▶ Definition의 설정


Definition파일을 설정했을 경우 얻어낼 수 있는 효과는 다음과 같다.


페이지선언에 대한 중앙집중화를 가능하게 한다
같은 페이지를 계속 선언해야 하는 불필요함을 상속으로서 제거한다.
파라미터로서 페이지를 호출해야 하는 것을 피한다.
struts-config파일에 forward에 대한 이름으로 정의할 수 있다.
definition attribute에 대한 오버로딩이 가능하다.
멀티채널 및 국제화에 대한 지원이 가능해진다.


Struts1.1에서는 strut-config.xml파일처럼 tiles에 대한 기본로딩이 가능하도록 구성되어져 있는데
web.xml파일의 servlet-mapping에서 org.apache.struts.tiles.ActionComponentServlet부분의
definitions-config를 이용하여 실제 definition파일의 위치를 지정하여 주면 가능하다.

위의 로딩부분이 들어간 javapattern.info사이트의 web.xml을 잠깐 보자.

<!-- Action Servlet Configuration -->
<servlet>
<servlet-name>action</servlet-name>
<servlet-class>org.apache.struts.tiles.ActionComponentServlet</servlet-class>
<init-param>
<param-name>definitions-config</param-name>
<param-value>/WEB-INF/conf/page-definitions.xml</param-value>
</init-param>
<init-param>
<param-name>definitions-debug</param-name>
<param-value>1</param-value>
</init-param>
<init-param>
<param-name>application</param-name>
<param-value>com.javapattern.resource.ApplicationResources</param-value>
</init-param>
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/conf/struts-config.xml</param-value>
</init-param>
<init-param>
<param-name>debug</param-name>
<param-value>2</param-value>
</init-param>
<init-param>
<param-name>detail</param-name>
<param-value>2</param-value>
</init-param>
<init-param>
<param-name>validate</param-name>
<param-value>true</param-value>
</init-param>
<load-on-startup>2</load-on-startup>
</servlet>


위의 설정에서는 definition-config를 WEB-INF/conf/page-definition.xml 파일로 지정을 했으며
샘플파일을 아래와 같이 설정할 수 있다.


<!-- html definition Mappings -->
<page-definitions>
<!-- Definition description -->
<definition name="site.mainLayout" path="/tutorial/layout/classicLayout.jsp">
<put name="title" value="My First Definition Page" />
<put name="header" value="/tutorial/common/header.jsp" />
<put name="footer" value="/tutorial/common/footer.jsp" />
<put name="menu" value="/tutorial/common/menu.jsp" />
<put name="body" value="/tutorial/basic/hello.jsp" />
</definition>
</page-definitions>


위에서 선언한 방법은 이미 살펴보았던 classic한 형태의 webpage에 include하는 방식과
별단 다르지가 않지만 가장 큰 특징은 해당 definition name을 정의하여 객체처럼 활용할수
있다는 것이다.

즉 상위 definition을 먼저 정의한 후 아래와 같이 상속을 받아서 사용이 가능하다는 얘기다

<definition name="site.index.page" extends="site.mainLayout" >
<put name="title" value="Tiles Blank Site Index" />
<put name="body" value="/common/content.jsp" />
</definition>


설정된 내용을 보게 되면 definition의 이름은 site.index.page라고 하여 site.mainLayout을
상속받아 처리하게 되는데 자바의 객체지향과 같은 개념이라 보면 된다.
즉 실제 site.index.page를 호출했을 경우 나머지 정의된 페이지가 없이 title, body만을
정의하고 있으므로 header, footer, menu는 부모인 site.mainLayout의 속성을 사용하게 되고
body와 title은 실제 자식객체인 site.index.page definition을 사용하게 된다라는 것이다.

그렇다면 저위에 설정된 definition을 어떻게 우리가 보여지게할 template파일에 포함시킬것인가?

그 설정방법은 아래와 같다.

<%@ taglib uri="/WEB-INF/tiles.tld" prefix="tiles" %>
<tiles:insert definition="site.index.page" flush="true" />


위의 파일은 www.javapattern.info의 index.jsp파일의 설정에 사용된 형태이다.
사실 머리통을 돌려서 다른 조작을 좀 해서 설정을 편하게 했지만 기초내용은 별반 다를 것이
없다.

▶ Conclusion


간단하게 tiles에 대하여 보았으며, 해당 문서는 struts의 tiles part에 포함되어 설명이 아주
자세하게 나와있는 내용이다.
이 글을 읽는 것에만 끝내지 말고, 직접 샘플하나를 만들어보면서 어떻게 적용시킬 수 있을것인가를
생각해보면 아주 다양하게 처리할 수 있는 방법이 계속 꼬리에 꼬리를 물게 될것이라 생각한다.
신고

 

Hibernate 버전 3.02 Reference Document 한글 버전입니다.

우측의 압축 파일의 내용물은 다음과 같습니다 :
 single html 문서
 multi html 문서
 프린트 전용 pdf 문서(copy-and-paste와 검색이 지원되지 않습니다)
 (* 용량이 작고 모든 기능이 지원되는 pdf 문서는
    sing html을 Acrobat과 같은 상용 도구로 변환하셔서 사용하시길 바랍니다)

HIBERNATE - Relational Persistence for Idiomatic Java

Hibernate Reference Documentation

3.0.2

역자 : 김종대


목 차

서두
1. Tomcat 으로 빠른 시작
1.1. Hibernate로 시작하기
1.2. 첫 번째 persistent class
1.3. cat 매핑하기
1.4.cat들에 작업하기
1.5. 마지막
2. 아키텍처
2.1. 개요
2.2. 인스턴스 상태들
2.3. JMX 통합
2.4. JCA 지원
3. 구성
3.1. 프로그램 상의 구성
3.2. SessionFactory 얻기
3.3. JDBC 커넥션들
3.4. 옵션 구성 프로퍼티들
3.4.1. SQL Dialects
3.4.2. Outer Join 페칭
3.4.3. Binary Streams
3.4.4. Second-level 캐시와 query 캐시
3.4.5. Query Language Substitution
3.4.6. Hibernate statistics
3.5. 로깅
3.6. NamingStrategy 구현하기
3.7. XML 구성 파일
3.8. J2EE 어플리케이션 서버 통합
3.8.1. 트랜잭션 방도 구성
3.8.2. JNDI-bound SessionFactory
3.8.3. 자동적인 JTA 및 Session 바인딩
3.8.4. JMX 배치
4. 영속 클래스들
4.1. 간단한 POJO 예제
4.1.1. 영속 필드들에 대한 accessor들과 mutator들을 선언하라
4.1.2. 아규먼트 없는 생성자를 구현하라
4.1.3. identifier 프로퍼티를 제공하라(옵션)
4.1.4. non-final 클래스들을 선호하라(옵션)
4.2. 상속 구현하기
4.3. equals() 과 hashCode() 구현하기
4.4. 동적인 모형들
5. 기본 O/R 매핑
5.1. 매핑 선언
5.1.1. Doctype
5.1.2. hibernate-mapping
5.1.3. class
5.1.4. id
5.1.4.1. Generator
5.1.4.2. Hi/lo 알고리즘
5.1.4.3. UUID 알고리즘
5.1.4.4. Identity 컬럼들과 시퀀스
5.1.4.5. 할당된 식별자들
5.1.4.6. 트리거들에 의해 할당된 프라이머리 키들
5.1.5. composite-id
5.1.6. discriminator
5.1.7. version (옵션)
5.1.8. timestamp (옵션)
5.1.9. property
5.1.10. many-to-one
5.1.11. one-to-one
5.1.12. component, dynamic-component
5.1.13. properties
5.1.14. subclass
5.1.15. joined-subclass
5.1.16. union-subclass
5.1.17. join
5.1.18. key
5.1.19. column 요소와 formula 요소
5.1.20. import
5.1.21. any
5.2. Hibernate 타입들
5.2.1. 엔티티들과 value들
5.2.2. 기본 value 타입들
5.2.3. 맞춤형 value 타입들
5.3. SQL 인용부호 처리된 식별자들
5.4. Metadata 대안들
5.4.1. XDoclet 마크업 사용하기
5.4.2. JDK 5.0 주석들을 사용하기
6. 콜렉션 매핑
6.1. 영속 콜렉션들
6.2. 콜렉션 매핑들
6.2.1. 콜렉션 foreign 키들
6.2.2. 콜렉션 요소들
6.2.3. 인덱싱된 콜렉션들
6.2.4. 값들을 가진 콜렉션들과 many-to-many 연관들
6.2.5. One-to-many 연관들
6.3. 개선된 콜렉션 매핑들
6.3.1. Sorted 콜렉션들
6.3.2. 양방향 연관들
6.3.3. 세 겹의 연관들
6.3.4. <idbag> 사용하기
6.4. 콜렉션 예제들
7. 연관 매핑들
7.1. 개요
7.2. 단방향 연관들
7.2.1. many to one
7.2.2. one to one
7.2.3. one to many
7.3. join 테이블들에 대한 단방향 연관들
7.3.1. one to many
7.3.2. many to one
7.3.3. one to one
7.3.4. many to many
7.4. 양방향 연관들
7.4.1. one to many / many to one
7.4.2. one to one
7.5. join 테이블들에 대한 양방향 연관들
7.5.1. one to many / many to one
7.5.2. one to one
7.5.3. many to many
8. 컴포넌트 매핑
8.1. 종속 객체들
8.2. 종속 개체들을 가진 콜렉션들
8.3. Map 인덱스들로서 컴포넌트들
8.4. composite 식별자들로서 컴포넌트들
8.5. 동적인 컴포넌트들
9. 상속 매핑
9.1. 세 개의 방도들
9.1.1. Table per class hierarchy
9.1.2. Table per class subclass
9.1.3. Table per subclass, using a discriminator
9.1.4. table per class hierarchy를 table per subclass와 혼합시키기
9.1.5. Table per concrete class
9.1.6. 함축적인 다형성을 사용하는 Table per concrete class
9.1.7. 함축적인 다형성을 다른 상속 매핑들과 혼합시키기
9.2. Limitations
10. 객체들로 작업하기
10.1. Hibernate 객체 상태들
10.2. 객체들을 영속화 시키기
10.3. 객체를 로드시키기
10.4. 질의하기
10.4.1. 질의들을 실행하기
10.4.1.1. 결과들을 반복하기
10.4.1.2. 튜플들을 반환하는 질의들
10.4.1.3. 스칼라 결과들
10.4.1.4. 바인드 파라미터들
10.4.1.5. 쪽매김
10.4.1.6. 스크롤 가능한 iteration
10.4.1.7. 명명된 질의들을 구체화 시키기
10.4.2. 콜렉션들을 필터링하기
10.4.3. Criteria 질의들
10.4.4. native SQL에서 질의들
10.5. 영속 객체들을 변경하기
10.6. detached 객체들을 변경하기
10.7. 자동적인 상태 검출
10.8. 영속 객체들을 삭제하기
10.9. 두 개의 다른 데이터저장소들 사이에 객체를 복사하기
10.10. Session을 flush 시키기
10.11. Transitive persistence
10.12. 메타데이터 사용하기
11. 트랜잭션들과 동시성
11.1. Session 영역과 트랜잭션 영역
11.1.1. 작업 단위
11.1.2. 어플리케이션 트랜잭션들
11.1.3. 객체 identity 고려하기
11.1.4. 공통된 쟁점들
11.2. 데이터베이스 트랜잭션 경계설정
11.2.1. 관리되지 않는 환경
11.2.2. JTA 사용하기
11.2.3. 예외상황 처리
11.3. Optimistic 동시성 제어
11.3.1. 어플리케이션 버전 체킹
11.3.2. 긴 세션과 자동적인 버전화
11.3.3. Detached 객체들과 자동적인 버전화
11.3.4. 자동적인 버전화 맞춤화 시키기
11.4. Pessimistic 잠금
12. 인터셉터들과 이벤트들
12.1. 인터셉터들
12.2. 이벤트 시스템
12.3. Hibernate 선언적인 보안
13. Batch processing
13.1. Batch inserts
13.2. Batch updates
13.3. Bulk update/delete
14. HQL: Hibernate Query Language
14.1. 대소문자 구분
14.2. from 절
14.3. 연관들과 joins
14.4. select 절
14.5. Aggregate 함수들
14.6. Polymorphic 질의들
14.7. where 절
14.8. 표현식들
14.9. order by 절
14.10. group by 절
14.11. 서브질의들
14.12. HQL 예제들
14.13. 대량 UPDATE & DELETE 문장들
14.14. 팁들 & 트릭들
15. Criteria 질의들
15.1. Criteria 인스턴스 생성하기
15.2. Narrowing the result set
15.3. 결과들을 순서지우기(Ordering)
15.4. 연관들
15.5. 동적인 연관 페칭
15.6. 예제 질의들
15.7. Projections, aggregation 그리고 grouping
15.8. Detached 질의들과 서브질의들
16. Native SQL
16.1. native SQL Query 생성시키기
16.2. Alias 참조들과 프로퍼티 참조들
16.3. 명명된 SQL 질의들
16.3.1. column/alias 이름들을 명시적으로 지정하는데 return-property 사용하기
16.3.2. 질의하는데 내장 프로시저들을 사용하기
16.3.2.1. 내장 프로시저들을 사용하는 규칙들/제약들
16.4. create, update 그리고 delete를 위한 맞춤형 SQL
16.5. 로딩을 위한 맞춤형 SQL
17. 데이터 필터링하기
17.1. Hibernate 필터들
18. XML 매핑
18.1. XML 데이터로 작업하기
18.1.1. XML과 class 매핑을 함께 지정하기
18.1.2. 단지 XML 매핑 지정하기
18.2. XML 매핑 메타데이터
18.3. XML 데이터 처리하기
19. 퍼포먼스 개선하기
19.1. 페칭 방도들
19.1.1. 페치 방도들을 튜닝하기
19.1.2. Single-ended association proxies
19.1.3. 콜렉션들과 프락시들을 초기화 시키기
19.1.4. batch 페칭 사용하기
19.1.5. lazy property 페칭 사용하기
19.2. Second Level Cache
19.2.1. Cache 매핑들
19.2.2. 방도: 읽기 전용
19.2.3. 방도: 읽기/쓰기
19.2.4. 방도: 엄격하지 않은 읽기/쓰기
19.2.5. 방도: transactional
19.3. 캐시들을 관리하기
19.4. Query Cache
19.5. Collection 퍼포먼스 이해하기
19.5.1. 분류
19.5.2. List들, map들, idbag들 그리고 set들은 업데이트에 가장 효율적인 콜렉션들이다
19.5.3. Bag들과 list들은 가장 효율적인 inverse 콜렉션들이다
19.5.4. 원 샷 delete
19.6. Monitoring performance
19.6.1. SessionFactory 모니터링 하기
19.6.2. Metrics
20. 도구셋 안내
20.1. 자동적인 스키마 생성
20.1.1. 스키마 맞춤화 시키기
20.1.2. 도구 실행하기
20.1.3. 프로퍼티들
20.1.4. Ant 사용하기
20.1.5. 점증하는 스키마 업데이트들
20.1.6. 점증하는 스키마 업데이트들에 대해 Ant 사용하기
21. 예제: 부모/자식
21.1. 콜렉션들에 관한 노트
21.2. 양방향 one-to-many
21.3. 케스케이딩 생명주기
21.4. 케스케이드들과 unsaved-value
21.5. 결론
22. 예제: Weblog 어플리케이션
22.1. 영속 클래스들
22.2. Hibernate 매핑들
22.3. Hibernate 코드
23. 예제: 여러가지 매핑들
23.1. Employer/Employee
23.2. Author/Work
23.3. Customer/Order/Product
23.4. 기타 예제 매핑들
23.4.1. "타입화 된" one-to-one 연관
23.4.2. Composite 키 예제
23.4.3. 내용 기반 판별
23.4.4. 대체 키들 상의 연관들
24. 최상의 실전 경험들

서두

객체 지향 소프트웨어와 관계형 데이터베이스로 작업하는 것은 오늘날의 엔터프라이즈 환경들에서 성가시고 시간이 소비될 수 있다. Hibernate는 자바 환경들을 위한 객체/관계형 매핑 도구이다. object/relational mapping (ORM) 용어는 객체 모형으로부터 SQL-기반의 스키마를 가진 관계형 데이터 모형으로의 데이터 표상을 매핑하는 기술을 언급한다. 

Hibernate는 자바 클래스들로부터 데이터베이스로의 매핑(그리고 자바 데이터 타입들로부터 SQL 데이터 타입들로의 매핑)을 처리할 뿐만 아니라, 또한 데이터 질의와 검색 편의들을 제공하며, SQL과 JDBC로 수작업 데이터 핸들링에 소요되는 개발 시간을 현저하게 단축시켜줄 수 있다. 

Hibernate의 목적은 공통된 데이터 영속화 관련 프로그래밍 작업들의 95%를  덜어주는 것이다. Hibernate는 데이터베이스에서 비지니스 로직을 구현하는데 내장 프로시저들을 전용으로 사용하는 데이터 중심적 어플리케이션에 대한 최상의 솔루션이 아닐 수도 있지만, 그것은 자바 기반 미들-티어에서 객체 지향 도메인 모형들과 비지니스 로직에 가장 유용하다. 하지만 Hibernate는 벤더 지정적인 SQL 코드를 제거하거나 캡슐화 시키는 당신을 확실히 도와줄 수 있고 테이블 형식의 표현으로부터 객체들의 그래프로 결과 셋을 변환하는 공통된 태스크를 도와줄  것이다.

만일 당신이 Hibernate와 Object/Relational 매핑 또는 심지어 자바에 초심자라면, 다음 단계들을 따르기 바란다:

  1. Tomcat을 사용하는 30분짜리 튜토리얼인 1장, Tomcat으로 빠른 시작 을 읽어라.
  2. Hibernate가 사용될 수 있는 환경을 이해하기 위해 2장, 아키텍처를 읽어라. 
  3. Hibernate 배포본 내의 eg/디렉토리를 살펴 보라. 이 디렉토리는 간단한 스탠드얼론 어플리케이션을 포함하고 있다. 당신의 JDBC 드라이버를 lib/ 디렉토리에 복사하고 당신의 데이터베이스에 맞는 정확한 값을 지정하여 etc/hibernate.properties를 편집하라. 배보본 디렉토리에서 명령 라인 프롬프트에서 (Ant를 사용하여) ant eg를 타이핑 하거나 , Windows 하에서 build eg를 타이프 하라.
  4. 당신의 주된 정보의 소스로서 이 참조 문서를 사용하라. 만일 어플리케이션 설계에 대해 더 많은 도움을 필요로 하거나 당신이 단계적인 튜토리얼을 선호한다면 Hibernate in Action (http://www.manning.com/bauer)을 읽는 것을 고려하라.또한 http://caveatemptor.hibernate.org 에 방문해서 Hibernate in Action용 예제 어플리케이션을 다운로드 하라.
  5. FAQ들은 Hibernate 웹 사이트 상에 답변되어 있다.
  6. 제 3의 데모들, 예제들, 그리고 튜토리얼들은 Hibernate 웹 사이트 상에 링크되어 있다.
  7. Hibernate 웹사이트 상의 공동체 영역은 설계 패턴과 다양한 통합 솔루션들(Tomcat, JBoss, Struts, EJB 등.)에 관한 좋은 소스이다.

질문이 있다면, Hibernate 상에 링크되어 있는 사용자 포럼을 사용하라. 우리는 또한 버그 보고와 특징 요청들을 위한 JIRA 쟁점 추적 시스템을 제공한다. 당신이 Hibernate의 개발에 관심이 있다면, 개발자 메일링 리스트에 참여하라. 만일 당신이 이 문서를 당신의 언어로 번역하는 것에 관심이 있다면, 개발자 메일링 리스트에 접촉하라. 

Hibernate를 위한 상용 개발 지원, 제품 지원 그리고 교육은 JBoss Inc를 통해 이용 가능하다(http://www.hibernate.org/SupportTraining/를 보라). Hibernate 는  JBoss Professional Open Source product suite의 프로젝트이다.

제 1장. Tomcat으로 빠른 시작

1.1.  Hibernate로 시작하기

이 튜토리얼은 웹 기반의 어플리케이션 용 Apache Tomcat 서블릿 컨테이너에 대한 Hibernate 3.0 셋업을 설명한다(우리는 버전 4.1을 사용했다. 5.0에 대한 차이점들은 적을 것이다). Hibernate는 모든 주요 J2EE 어플리케이션 서버들의 관리되는 환경에서 잘 동작하고, 또는 심지어 스탠드얼론 어플리케이션들에서도 잘 동작한다. 이 튜토리얼에 사용되는 데이터베이스 시스템은  PostgreSQL 7.4이고, 다른 데이터베이스에 대한 지원은  단지 Hibernate SQL dialect 구성과 커넥션 프로퍼티들을 변경시키는 것에만 관계된다. 

먼저 우리는 모든 필수적인 라이브러리들을 Tomcat 설치 장소에 복사해야 한다. 우리는 이 튜토리얼을 위해 별도의 웹 컨텍스트(webapps/quickstart)를 사용하며, 따라서 우리는 전역 라이브러리 검색 경로(TOMCAT/common/lib)와  webapps/quickstart/WEB-INF/lib(JAR 파일들의 경우)와 webapps/quickstart/WEB-INF/classes 내 에 있는 컨텍스트 레벨에서 클래스로더 양자를 고려해야 한다. 우리는 두 개의 클래스로더 레벨들을 전역 classpath와 컨텍스트 classpath로 언급한다.

이제 라이브러리들을 두 개의 classpath들에 복사하라: 

  1. 데이터베이스 용 JDBC 드라이버를 전역 classpath로 복사하라. 이것은 Tomcat에 번들로구성된 DBCP 커넥션 풀 소프트웨어에 필요하다. Hibernate는 데이터베이스 상에서 SQL을 실행시키는데 JDBC 커넥션들을 사용하므로, 당신은 풀링된 JDBC 커넥션들을 제공해야 하거나, 직접 지원되는 풀들(C3P0, Proxool) 중 하나를 사용하기 위해 Hibernate를 구성해야 한다. 이 튜토리얼을 위해, (PostgreSQL 7.4와 JDK 1.4용) pg74jdbc3.jar 라이브러리를 전역 classloaders 경로로 복사하라. 만일 당신이 다른 데이터베이스를 사용하고자 원할 경우, 간단하게 그것의 적절한 JDBC 드라이버를 복사하라.
  2. 그 밖의 어떤 것을 Tomcat 내의 전역 클래스로더 경로에 복사하지 말라. 또는 당신은 Log4j, commons-logging 그리고 다른 것들을 포함하는 여러 가지 도구들에 관련된 문제점들을 얻게 될 것이다. 각각의 웹 어플리케이션에 대해 컨텍스트 classpath를 사용하라. 즉 라이브러리들을  WEB-INF/lib에 복사하고, 당신 자신의 클래스들과 구성 파일들/프로퍼티 파일들을 WEB-INF/classes에 복사하라. 두 디렉토리들 양자는 디폴트로 컨텍스트 classpath 내에 있다.
  3. Hibernate는 JAR 라이브러리로서 패키지화 되어 있다.  hibernate3.jar 파일은 어플리케이션의 다른 클래스들과 함께 컨텍스트 classpath 속에 복사되어야 한다.  Hibernate는 실행 시에 어떤 제 3의 라이브러리들을 필요로하고, 이것들은 lib/ 디렉토리 내의 Hibernate 배포본에 번들화되어 있다;  1.1, “ Hibernate 3rd party libraries ”를 보라. 필요한 제3의 라이브러리들을 컨텍스트 classpath로 복사하라.

표 1.1.  Hibernate 3rd party 라이브러리

라이브러리 설명
antlr (필수) Hibernate는 질의 파서들을 산출하는데 ANTLR을 사용하고, 이 라이브러리는 또한 실행 시에 필요하다.
dom4j (필수) Hibernate는 XML 구성과 XML 매핑 메타데이터 파일들을 파싱하는데 dom4j를 사용한다. .
CGLIB, asm (필수) Hibernate는 (Java reflection과 결합하여) 런타임 시에 클래스들을  고양시키는데 코드 생성 라이브러리를 사용한다.
Commons Collections, Commons Logging (필수) Hibernate는 Apache Jakarta Commons 프로젝트로부터 다양한 유틸리티 라이브러리들을 사용한다.
EHCache (필수) Hibernate는 second-level 캐시를 위한 다양한 캐시 프로바이더들을 사용할 수 있다. 만일 구성에서 변하지 않을 경우 EHCache가 디폴트 캐시 프로바이더이다.
Log4j (옵션) Hibernate는 기본 로깅 메커니즘으로서 Log4j를 사용할 수 있는, Commons Logging API를 사용한다. 만일 Log4j 라이브러리가 컨텍스트 라이브러리 디렉토리 속에서 이용가능하다면, Commons Logging은 Log4j와 컨텍스트 classpath 내에 있는 log4j.properties 구성을 사용할 것이다.  Log4j에 대한 예제 properties 파일은 Hibernate 배포본에 번들화 되어 있다. 따라서 당신이 이면에서 무엇이 진행되는 지을 보고자 원할 경우에 log4j.jar와 (src/에 있는) 구성 파일을 당신의 컨텍스트 classpath 속으로 복사하라.
필수 여부? Hibernate 배포본 내에 있는 lib/README.txt 파일을 살펴보라. 이것은 Hibernate에 배포된 제 3의 라이브러리들의 최신 목록이다. 당신은 그곳에 열거된 모든 필수 라이브러리들과 옵션 라이브러리들을 찾게 될 것이다(여기서 "buildtime required"는 당신의 어플리케이션이 아니라 Hibernate에 대한 의미임을 노트하라).

우리는 이제 Tomcat과 Hibernate 양자에서 데이터베이스 풀링과 공유를 설정한다. 이것은 Tomcat이 (그것의 빌드되어 있는 DBCP 풀링 특징을 사용하여) 풀링된 JDBC 커넥션들을 제공할 것이고, Hibernate가 JNDI를 통해 이들 커넥션들을 요청한다는 것을 의미한다. 달리 당신은 Hibernate로 하여금 커넥션 풀을 관리하도록 할 수 있다. Tomcat은 그것의 커넥션 풀을 JNDI에 바인드 시킨다; 우리는 리소스 선언을 Tomcat 메인 구성 파일 TOMCAT/conf/server.xml에 추가한다: 

<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>

우리가 이 예제에서 구성하는 컨텍스트는 quickstart로 명명되고, 그것의 베이스는 TOMCAT/webapp/quickstart 디렉토리이다. 임의의 서블릿들에 접근하기 위해, (물론 당신의 web.xml 속에 매핑된 서블릿의 이름을 추가하여) 당신의 브라우저에서 http://localhost:8080/quickstart 경로를 호출하라. 당신은 또한 계속 진행하고 이제 공백의 process() 메소드를 가진 간단한 서블릿을 생성시킬 수 있다. 

Tomcat은 이제 java:comp/env/jdbc/quickstart로 JNDI을 통해 커넥션들을 제공한다. 만일 당신이 실행 중인 커넥션 풀을 얻는 것에 문제가 있다면 Tomcat 문서를 참조하라. 당신이 JDBC 드라이버 예외상황 메시지를 얻을 경우, 먼저 Hibernate 없이 JDBC 커넥션 풀을 셋업하라. Tomcat & JDBC 튜토리얼들은 그 웹 서이트에서 이용 가능하다.

당신의 다음 단계는 Hibernate를 구성하는 것이다. Hibernate는 그것이 JDBC 커넥션들을 얻는 방법을 알고 있어야 한다. 우리는 Hibernate의 XML 기반 구성을 사용한다.  properties 파일을 사용하는 다른 접근법은 거의 동일하지만 XML 구문이 허용하는 몇몇 특징들을 누락하고 있다.  XML 구성 파일은 hibernate.cfg.xml로서 컨텍스트 classpath (WEB-INF/classes) 내에  위치해 있다:

<?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>

우리는 SQL 명령들에 대한 로깅을 사용하지 않고 Hibernate에게 사용되는 데이터베이스 SQL direct가 무엇인지 그리고 (Tomcat 바인드된 풀의 JNDI 주소를 선언하여) JDBC 커넥션들을 얻는 곳을 알려준다. dialect는 필수적인 설정이고, 데이터베이스들은 SQL "표준"에 대한 그것들의 해석을 달리한다. Hibernate는 차이점들을 처리하고 모든 주요 상용 데이터베이스들 및 오픈 소스 데이터베이스들 용도의 direct들을 번들로 포함하고 있다.

SessionFactory 는 단일 데이터저장소에 관한 개념이고, 여러 데이터베이스들은 여러 개의 XML 구성 파일들을 생성시키고 당신의 어플리케이션 속에서 여러 개의 Configuration 및 SessionFactory 객체들을 생성시켜서 사용될 수 있다.

hibernate.cfg.xml의 마지막 요소는 영속 클래스 Cat에 대한 Hibernate XML 매핑 파일의 이름으로써 Cat.hbm.xml을 선언한다. 이 파일은 데이터베이스 테이블(또는 테이블들)로 POJO 클래스 Cat 을 매핑시키는 메타데이터를 포함한다. 우리는 곧 그 파일로 되돌아 갈 것이다. 먼저 POJO 클래스를 작성하고 그런 다음 그것을 위한 매핑 메타데이터를 선언하자.

1.2. 첫 번째 영속 클래스

Hibernate는 영속 클래스들에 대한 Plain Old Java Objects (POJOs, 종종 Plain Ordinary Java Objects로 명명된다) 프로그래밍 모형으로 가장 잘 동작한다.  POJO는 공용으로 가시적인 인터페이스로부터 내부적인 표상을 은폐시켜, getter와 setter 메소드들을 통해 접근가능한 클래스들의 프로퍼티들을 가진 자바빈과 꽤 유사하다(필요하다면 Hibernate는 또한 필드들에 직접 접근할 수 있다):

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;
    }

}

Hibernate는 그것의 프로퍼티 타입들의 사용에 제약되지 않고, 자바 콜렉션 프레임웍에서의 클래스들을 포함하여, 모든 자바 JDK 타입들과 (String, char Date 같은) 원시타입들이 매핑될 수 있다. 당신은 그것을 값들로서, 값들을 가진 콜렉션들로서, 또는 다른 엔티티들에 대한 연관들로서 매핑시킬 수 있다.  id 는 그 클래스의 데이터베이스 식별자(프라이머리 키)를 표현하는 특별한 프로퍼티이고, 그것은 Cat과 같은 엔티티들에 대해 매우 권장된다. Hibernate는 내부적으로만 식별자들을 사용할 수 있지만, 우리는 우리의 어플리케이션 아키텍처에서 어떤 유연성을 상실하게 될 것이다. 

특정 인터페이스는 영속 클래스들에 대해 구현되지 말아야 하거나 특정 루트 영속 클래스로부터 서브 클래스로 만들지 말아야 한다. Hibernate는 또한 바이트 코드 처리와 같은, 어떤 빌드 시 처리를 필요로 하지 않고, 그것은 오직 자바 reflection과 (CGLIB를 통한) 런타임 클래스 고양에만 의존한다. 따라서 Hibernate에 대한 POJO 클래스의 어떤 의존성 없이도, 우리는 그것을 데이터베이스 테이블로 매핑할 수 있다.

1.3. cat 매핑하기

Cat.hbm.xml 매핑파일은 객체/관계형 매핑에 필요한 메타데이터를 포함한다. 메타데이터는 영속 클래스들의 선언과 데이터베이스 테이블들에 대한 (컬럼들과 다른 엔티티들에 대한 foreign 키 관계들에 대한) 프로퍼티들의 매핑을 포함한다.

<?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.hex"/>
        </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>

모든 영속 클래스는 식별자 속성을 가져야 한다(실제로 value-타입의 클래스들에 의존하지 않는, 엔티티들을 표현하는 유일한 클래스들은 엔티티을 가진 컴포넌트들로 매핑된다). 이 프로퍼티는 영속 객체들을 구별짓는데 사용된다: 만일 catA.getId().equals(catB.getId())이 true일 경우, 두 개의 cat들은 같고, 이 개념은 database identity로 명명된다.  Hibernate는 (데이터베이스 시퀀스, hi/lo 식별자 테이블들, 그리고 어플리케이션 할당 식별자들에 대한 native 생성기들을 포함하는) 다른 시나리오들에 대해 여러 가지 식별자 생성기들을 번들로 갖고 있다. 우리는 UUID 생성기(데이터이스에 의해 생성된 정수 대용 키들이 선호될 것이므로, 테스트용으로만 권장됨)를 사용하고 또한  Hibernate 생성된 식별자 값을 위한 CAT 테이블의 CAT_ID 컬럼을 (테이블의 프라이머리 키로서) 지정한다. 

Cat 의 모든 다른 프로퍼티들은 동일한 테이블로 매핑된다. name 프로퍼티의 경우에, 우리는 그것을 명시적인 데이터베이스 컬럼 선언으로 매핑시켰다. 데이터베이스 스키마가 Hibernate의 SchemaExport  도구에 의해 매핑 선언으로부터 (SQL DDL 문장들로) 자동적으로 생성될 때 이것이 특별히 유용하다. 모든 다른 프로퍼티들은 Hibernate의 디폴트 설정들을 사용하여 매핑되고, 디폴트 설정들은 당신이 가장 많은 시간을 필요로 하는 것이다. 데이터베이스 내의 테이블 CAT 은 다음과 같다:

 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)

당신은 이제 수작업으로 당신의 데이터베이스 내에 이 테이블을 생성시킬 것이고, 만일 당신이 hbm2ddl 도구로 이 단계를 자동화 시키고자 원할 경우 20 장, 도구셋 안내를 읽어라. 이 도구는 테이블 정의, 맞춤형 컬럼 타입 컨스트레인트들, 유일 컨스트레인트들과 인덱스들을 포함하는, 전체 SQL DDL을 생성시킬 수 있다.

1.4. cat들에 작업하기

우리는 이제 Hibernate의 Session을 시작할 준비가 되어 있다. 그것은  persistence manager(영속 관리자)이고, 우리는 데이터베이스로 Cat를 저장하고 데이터베이스로부터 Cat를 검색하는데 그것을 사용한다. 그러나 먼저 우리는 SessionFactory로부터 Session (Hibernate의 작업 단위)를 얻어야 한다:

SessionFactory sessionFactory =
            new Configuration().configure().buildSessionFactory();

configure() 호출은 hibernate.cfg.xml 구성 파일을 로드시키고  Configuration  인스턴스를 초기화 시킨다. 당신이 SessionFactory(불변적임)를 빌드하기 이전에 당신은 Configuration에 접근함으로써 다른 프로퍼티들을 설정할 수 있다(그리고 심지어 매핑 메타데이터를 변경시킬 수 있다). 우리는 어디서 SessionFactory를 생성시키고 우리의 어플리케이션 속에서 어떻게 그것에 접근할 수 있나?

SessionFactory 는 대개 오직 한번만, 예를 들어 대개 load-on-startup 서블릿으로 시작 시에 빌드된다. 이것은 또한 당신이 당신의 서블릿들 내에 있는 인스턴스 변수 속에 그것을 유지하지 않을 것이지만 어떤 다른 위치에 유지시킬 것임을 의미한다. 더구나 우리는 어떤 종류의 Singleton을 필요로 하며, 따라서 우리는 어플리케이션 코드로 쉽게 SessionFactory 에 액세스 할 수 있다.  다음에 보여진 접근법은 두 문제 모두를 해결한다: 시작 구성과 SessionFactory에 대한 쉬운 접근.

리는 HibernateUtil helper 클래스를 구현한다:

import org.hibernate.*;
import org.hibernate.cfg.*;

public class HibernateUtil {

    private static Log log = LogFactory.getLog(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 currentSession() {
        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);
    }
}

이 클래스는 static 초기자를 가진 SessionFactory를 처리할 뿐만 아니라 또한 현재의 쓰레드를 위한 Session 을 보관하는 ThreadLocal변수를 갖는다. 이 helper를 사용하려고 시도하기 전에 thread-local 변수에 대한 자바 개념을 이해해야 한다. 보다 복잡하고 강력한 HibernateUtil 클래스는  http://caveatemptor.hibernate.org/의 CaveatEmptor에서 찾을 수 있다.

 SessionFactory는 threadsafe이고, 많은 쓰레드들이 동시에 그것에 접근할 수 있고 Session들을 요청할 수 있다. 하나의 Session은 데이터베이스에 대해 한 개의 단위 작업을 나타내는 non-threadsafe 객체이다.  Session들은 SessionFactory로부터 열려지고 모든 작업이 완료될 때 닫혀진다. 당신의 서블릿의 process() 메소드 내에 있는 예제는 다음과 같을 수 있다(예외상황 처리 없이): 

Session session = HibernateUtil.currentSession();
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();

하나의 Session 내에서 모든 데이터베이스 오퍼레이션은 데이터베이스 오퍼레이션들(심지어 읽기 전용 오퍼레이션들 조차도)을 격리시키는 하나의 트랜잭션 내부에서 발생한다. 우리는 기본 트랜잭션 방도(우리의 경우, JDBC 틀내잭션들)로부터 추상화시키는데 Hibernates Transaction API 를 사용한다. 이것은 우리의 코드가 임의의 변경들 없이도 (JTA를 사용하는) 컨테이너-관리되는 트랜잭션들에 배치되는 것을 허용해준다.

당신이 원하는 만큼 당신이 HibernateUtil.currentSession();을 호출할 수 있고, 당신은 이 쓰레드의 현재 Session을 항상 얻을 것임을 노트하라. 당신은 서블릿 코드 내에서든 또는 서블릿 필터 내에서든 HTTP response가 전송되기 전에, 당신의 단위 작업이 완료된 후에 Session을 확실히 닫아야 한다.  두 번째 옵션의 좋은 측면은 쉬운 lazy 초기화이다: 뷰가 렌더링 될 때 Session이 여전히 열려져 있어서,  Hibernate는 당신이 현재 객체 그래프를 네비게이트 하는 동안 초기화 되지 않은 객체들을 로드시킬 수 있다. 

Hibernate는 데이터베이스로부터 객체들을 검색하는데 사용될 수 있는 다양한 메소드들을 갖고 있다. 가장 유연한 방법은 Hibernate Query Language (HQL)을 사용하는 것이다. Hibernate Query Language (HQL)은 배우기가 쉽고 SQL에 대한 강력한 객체 지향 확장이다:

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();

Hibernate는 또한 type-safe 질의들을 공식화 시키는데 사용될 수 있는 객체 지향 query by criteria API을 제공한다. 물론 Hibernate는 데이터베이스와의 모든 SQL 통신을 위해 PreparedStatement들과 파라미터 바인딩을 사용한다. 당신은 또한 Hibernate 직접적인 SQL 질의 특징을 사용할 수도 있거나 드문 경우에 Session 로부터 plain JDBC 커넥션을 얻을 수도 있다.

1.5.  마지막으로

우리는 이 작은 튜토리얼 내에서 단지 Hibernate의 표면을 훑기만 했다. 우리는 우리의 예제들 속에 어떤 서블릿 지정적 코드를 포함하지 않음을 노트하라. 당신이 적합한지를 알려고 할 때 당신은 당신 자신의 서블릿을 생성시켜야 하고 Hibernate 코드를 삽입해야 한다. 

데이터 접근 계층으로서 Hibernate는 당신의 어플리케이션에 강하게 통합됨을 염두에 두라. 대개 모든 다른 레이어들은 영속 메커니즘에 의존했다. 당신은 이 설계의 함축을 확실히 이해하도록 하라.

보다 복잡한 어플리케이션 예제는 http://caveatemptor.hibernate.org/ 를 보고 http://caveatemptor.hibernate.org/에 있는 다른 튜토리얼들을 살펴보라.

제 2장. 아키텍처

2.1.  개요

Hibernate 아키텍처에 대한 (매우) 높은 수준의 개요: 

이 다이어그램은 어플리케이션에 영속화 서비스들(과 영속 객체들)을 제공하기 위해 데이터베이스와 컨피그레이션을 사용하는 Hibernate를 보여준다.

우리는 런타임 아키텍처에 대한 보다 상세한 뷰를 보여주고 싶다. 불행하게도, Hibernate는 유연하며 몇 가지 접근법들을 제공한다. 우리는 두 가지 극단을 보여줄 것이다. "경량급" 아키텍처는 그것 자신의 JDBC 커넥션들을 제공하고 그것 자신의 트랜잭션들을 관리하는 어플리케이션을 갖는다. 이 접근법은 Hibernate의 API의 최소 부분집합을 사용한다:

"전체 정수" 아키텍처는 기본 JDBC/JTA로부터 어플리케이션을 추상화 시키고 Hibernate로 하여금 상세한 것을 처리하게 한다.

다음은 다이어그램들 내에 있는 객체들에 대한 몇가지 정의들이다:

SessionFactory (org.hibernate.SessionFactory)

단일 데이터베이스에 대한 컴파일된 매핑들의 threadsafe (불변의) 캐시. SessionConnectionProvider의 클라이언트를 위한 팩토리. 프로세스 레벨 또는 클러스터 레벨에서 트랜잭션들 사이에 재사용 가능한 데이터의 선택적인(두 번째 레벨의) 캐시를 보관할 수도 있다. 

Session (org.hibernate.Session)

어플리케이션과 영속 저장소 사이의 대화를 표현하는 단일 쓰레드이고, 수명이 짧은 객체.  JDBC 커넥션을 포장한다.  Transaction 용 팩토리. 객체 그래프를 네비게이트 하거나 식별자로 객체들을 룩업할 때 사용되는 영속 객체들에 대한 필수적인(첫 번째 레벨의) 캐시를 보관한다.

영속 객체들과 콜렉션들

persistent 상태와 비지니스 기능을 포함하는 수명이 짧고, 단일 쓰레드인 객체들. 이것들은 통상의 JavaBeans/POJO들일 수 있고, 오직 그것들에 대한 오직 특별한 것은 그것들이 현재 (정확하게 한 개의)Session 과  연관되어 있다는 점이다. Session 이 닫히자마자, 그것들은 분리될(detached 상태가 될) 것이고 어플리케이션 레이어에서 사용하는 것이 자유로와진다(예를 들면. 프리젠테이션 으로의 그리고 으로부터의 데이터 전송 객체들로서 직접).

Transient 객체와 detached 객체 그리고 콜렉션들

Session과 현재 연관되어 있지 않은 영속 클래스들의 인스턴스. 그것들은 어플리케이션에 의해 초기화되었고 아직 영속화 되지 않았거나 그것들은 닫혀진 Session에 의해 초기화되었을 수도 있다.

트랜잭션 (org.hibernate.Transaction)

(옵션) 작업의 원자 단위를 지정하기 위해 어플리케이션에 의해 사용되는 단일 쓰레드이고, 수명이 짧은 객체. 기본 JDBC, JTA 또는 CORBA 트랜잭션으로부터 어플리케이션을 추상화 시킨다. 하나의 Session 은 몇몇 경우들에서 여러 개의 Transaction들에 걸칠 수 있다. 하지만 기본 API 또는 Transaction을 사용하는 트랜잭션 경계 설정은 결코 옵션이 아니다!

ConnectionProvider (org.hibernate.connection.ConnectionProvider)

(옵션) JDBC 커넥션들에 대한 팩토리(그리고 그것들의 pool). 기본 Datasource 또는 DriverManager로부터 어플리케이션을 추상화 시킨다. 어플리케이션에 노출되지는 않지만 개발자에 의해 확장/구현 된다.

TransactionFactory (org.hibernate.TransactionFactory)

(옵션) Transaction 인스턴스들에 대한 팩토리. 어플리케이션에 노출되지는 않지만 개발자에 의해 확장/구현 된다.

Extension Interfaces

Hibernate는 당신의 영속 계층의 특성을 맞춤화 시키기 위해 당신이 구현할 수 있는 선택적인 확장 인터페이스들을 제공한다.   상세한 것은 API 문서를 보라.

주어진 "경량급" 아키텍처의 경우, 어플리케이션은 JTA 또는 JDBC와 직접 대화하기 위해서 Transaction/TransactionFactory 과/또는 ConnectionProvider API들을 무시한다.

2.2.  인스턴스 상태들

영속 클래스들의 인스턴스는 세개의 상태들 중 하나 일 수 있다. 그것들(상태들)은 영속  컨텍스트(persistence context)에 대해 정의된다. Hibernate Session 객체는 영속 컨텍스트이다:

transient

인스턴스는 임의의 컨텍스트와 연관되어 있지 않고, 결코 연관된 적이 없었다. 그것은 영속 식별자(프라이머리 키 값)을 갖지 않는다.

persistent

인스턴스는 현재 영속 컨텍스트와 연관되어 있다. 그것은 영속 식별자(프라이머리 키 값) 그리고 아마 데이터베이스 내에 있는 대응하는 행을 갖는다. 특별한 영속 컨텍스트의 경우, Hibernate는 영속 identity가 Java identity(객체의 메모리 내 위치)와 같다는 점을 보증한다

detached

인스턴스는 영속 컨텍스트와 한번 연관되었지만, 그 컨텍스트가 닫혔거나, 그 인스턴스가 또 다른 프로세스로 직렬화 되었다. 그것은 영속 identity 그리고, 아마 데이터베이스 내의 대응하는 행을 갖는다. detached 인스턴스들의 경우, Hibernate는 영속 identity과 Java identity 사이의 관계를 보증하지 않는다.

2.3. JMX 통합

JMX는 자바 컴포넌트 관리를 위한 J2EE 표준이다. Hibernate는 JMX 표준 서비스를 통해 관리될 수도 있다. 우리는 배포본 내에 MBean 구현, org.hibernate.jmx.HibernateService 을 제공한다.

JBoss 어플리케이션 서버 상에 Hibernae를 JMX 서비스로서 배치하는 방법에 대한 예제는 JBoss 사용자 가이드를 보길 바란다. JBoss 어플리케이션 서버 상에서, 만일 당신이 JMX를 사용하여 배치할 경우 당신은 또한 다음 이점들을 얻는다:

  • Session 관리: Hibernate Session의 생명주기가 JTA 트랜잭션의 영역 내에 자동적으로 바인드 될 수 있다. 이것은 당신이 더이상 Session을 수작업으로 열고 닫지 않아도 됨을 의미하고, 이것은 JBoss EJB 인터셉터의 업무가 된다.  당신은 또한 더 이상 당신의 코드 어느 곳에서든 트랜잭션 경계설정에 대해 걱정하지 않아도 된다(당신이 물론 이식성 있는 영속 계층을 작성하고자 원하지 않는한, 이를 위해 옵션 Hibernate Transaction  API를 사용하라). 당신은 Session에 접근하기 위해 HibernateContext를 호출한다.
  • HAR 배치: 대개 당신은 JBoss 서비스 배치 디스크립터를 사용하여 Hibernate JMX 서비스를 (EAR 과/또는 SAR 파일로) 배치하고, 그것은 Hibernate SessionFactory의 통상적인 구성 옵션들 모두를 지원한다. 하지만 당신은 여전히 모든 당신의 매핑 파일들을 배치 디스크립터 속에 명명해야 한다. 만일 당신이 옵션 HAR 배치를 사용하고자 결정하는 경우, JBoss는 당신의 HAR 파일 내에 있는 모든 매핑 파일들을 자동적으로 검출해낼 것이다.

이들 옵션들에 대한 추가 정보는 JBoss 어플리케이션 서버 사용자 가이드를 참조하라.

JMX 서비스로서 이용 가능한 또다른 특징은 런타임 Hibernate 통계이다. 3.4.6절, “Hibernate statistics”를 보라.

2.4. JCA 지원

Hibernate는 JCA 커넥터로서 구성될 수도 있다. 상세한 것은 웹 사이트를 보길 바란다.

Hibernate JCA 지원은 여전히 실험적으로 검토 중에 있음을 노트하길 바란다.

제 3장. 구성

Hibernate가 많은 다른 환경들에서 동작하도록 설계되어 있으므로, 많은 개수의 구성 파라미터들이 존재한다. 다행히 대부분은 유의미한 디폴트 값들이고 Hibernate는 다양한 옵션들을 보여주는 etc/ 내 의 예제 파일 hibernate.properties로 배포된다.  당신은 대개 당신의 classpath 경로 속에 그 파일을 집어넣고 그것을 커스트마이징하기만 해야 한다.

3.1. 프로그램 상의 구성

org.hibernate.cfg.Configuration 의 인스턴스는 어플리케이션의 Java 타입들을 SQL 데이터베이스 타입으로의 전체 매핑 집합을 표현한다. Configuration 은 (불변의) SessionFactory를 빌드하는데 사용된다. 매핑들은 여러 가지 XML 매핑 파일들로부터 컴파일 된다.

당신은 Configuration 인스턴스를 초기화 함으로써 Configuration 인스턴스를 얻을 수 있다. 다음은 (classpath 내에 있는) 두 개의 XML 매핑 파일 속에 정의된 매핑들로부터 데이터저장소를 설정하는 예제이다:

Configuration cfg = new Configuration()
.addFile("Item.hbm.xml")
.addFile("Bid.hbm.xml");

(때때로 더 나은) 다른 방법은 getResourceAsStream()을 사용하여 Hibernate로 하여금 매핑 파일을 로드시키도록 하는 것이다:

Configuration cfg = new Configuration()
.addClass(org.hibernate.auction.Item.class)
.addClass(org.hibernate.auction.Bid.class);

그런 다음 Hibernate는 classpath 내에 /org/hibernate/auction/Item.hbm.xml/org/hibernate/auction/Bid.hbm.xml로 명명된 매핑 파일들을 룩업할 것이다. 이 접근법은 임의의 하드코딩된 파일 이름들을 제거한다. 

Configuration 은 또한 다양한 옵션 프로퍼티들을 지정한다: 

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");

이것은 컨피그레이션 프로퍼티들을 Hibernate에 전달하는 유일한 방법이 아니다. 여러 가지 옵션들은 다음을 포함한다:

  1. java.util.Properties 의 인스턴스를 Configuration.setProperties()에 전달한다 .
  2. classpath의 루트 디렉토리에 hibernate.properties 를 위치지운다.
  3. java -Dproperty=value를 사용하여 System properties를 설정한다.
  4. hibernate.cfg.xml<property> 요소들을 포함한다(나중에 논의됨).

hibernate.properties 는 당신이 빠르게 시작하고 원할 경우 가장 쉬운 접근법이다. 

Configuration 은 시작 시(startup-time) 객체로서 일단 SessionFactory가 생성되면 폐기되게끔 예정되어 있다. 

3.2. SessionFactory 얻기

모든 매핑들이 Configuration에 의해 파싱되었을 때, 어플리케이션은 Session 인스턴스들에 대한 팩토리를 얻어야 한다. 이 팩토리는 모든 어플리케이션 쓰레드들에 의해 공유되도록 고안되었다: 

SessionFactory sessions = cfg.buildSessionFactory();

하지만 Hibernate는 당신의 어플리케이션이 하나 이상의 SessionFactory를 초기화 시키는 것을 허용한다. 이것은 당신이 하나 이상의 데이터베이스를 사용하는 경우에 유용하다. 

3.3. JDBC 커넥션들

SessionFactory 는 사용자 제공 JDBC 커넥션 상에서 Session 을 열 수 있다. 이 설계 선택은 그것이 만족될 때마다 어플리케이션이 JDBC 커넥션들을 얻는 것을 자유롭게 해준다:

java.sql.Connection conn = datasource.getConnection();
Session session = sessions.openSession(conn);

// 어떤 데이터 액세스 작업을 행한다

어플리케이션은 동일한 JDBC 커넥션 상에서 두 개의 동시적인 Session들 을 열지 않도록 주의해야 한다!

우리는 사용자 제공 JDBC 커넥션들을 권장하지 않는다. 왜냐하면 Hibernate가 캐싱을 불가능하게 할 것이기 때문이고(그것은 당신이 주어진 커넥션 상에서 실행할 수 있다는 사실을 알지 못한다) 대개 다음 옵션들 중 하나가 더 적절하기 때문이다.

대개 당신은 SessionFactory 를 생성시키고 당신을 위한 JDBC 커넥션들을 풀링시키고자 원한다. 만일 당신이 이 접근법을 취하라 경우, Session을 여는 것은 다음과 같이 간단하다:

Session session = sessions.openSession(); // 새로운 Session을 연다

데이터베이스에 대한 업근을 필요로 하는 어떤 것을 당신이 행하자 마자, JDBC 커넥션이 그 풀로부터 획득될 것이다.

이것이 동작하도록 하기 위해, 우리는몇몇 JDBC 커넥션 프로퍼티들을 Hibernate에 전달할 필요가 있다. 모든 Hibernate 프로퍼티 이름들과 의미들은 org.hibernate.cfg.Environment 클래스 상에 정의되어 있다.우리는 이제 JDBC 커넥션 구성을 위한 가장 중요한 설정들을 설명할 것이다.

당신이 다음 프로퍼티들을 설정할 경우, Hibernate는 java.sql.DriverManager를 사용하여 커넥션들을 획득(그리고 풀링)할 것이다.:

표 3.1. Hibernate JDBC 프로퍼티들

Property name Purpose
hibernate.connection.driver_class jdbc 드라이버 클래스
hibernate.connection.url jdbc URL
hibernate.connection.username 데이터베이스 사용자
hibernate.connection.password 데이터베이스 사용자 패스워드
hibernate.connection.pool_size 풀링된 커넥션들의 최대 개수

하지만 Hibernate 자신의 커넥션 풀링 알고리즘은 아주 기본적이다. 그것은 당신이 시작하는 것을 도와주려고 의도되었고 제품 시스템 용도 또는 퍼포먼스 테스트용으로 고안되지 않았다. 최상의 퍼포먼스와 안정성을 위해서는 제 3의 풀을 사용하라. 즉 hibernate.connection.pool_size 프로퍼티를 커넥션 풀 지정 설정들로 대체하라. 이것은 Hibernate의 내부 pool을 오프시킬 것이다. 예를 들어 당신은 C3P0를 사용할 수도 있다.

C3P0는 lib 디펙토리 속에 Hibernate에 배포된 오픈 소스 JDBC 커넥션 풀이다. 당신이 hibernate.c3p0.* 프로퍼티들을 설정할 경우  Hibernate는  커넥션 풀링을 위해 그것의 C3P0ConnectionProvider 를 사용할 것이다. 만일 당신이 Proxool 을 사용하고자 원할 경우 패키지화 된 hibernate.properties 를 참조하고 추가 정보는 Hibernate 웹 사이트를 참조하라.

다음은 C3P0에 대한 사용하는 예제 hibernate.properties 파일이다: 

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

어플리케이션 서버 내부의 용도로, 당신은 JNDI로 등록된 어플리케이션 서버 Datasource로부터 커넥션을 얻기 위해 항상 Hibernate를 구성해야 한다. 당신은 적어도 다음 프로퍼티들 중 하나를 설정할 필요가 잇을 것이다.

표 3.2. Hibernate Datasource 프로퍼티들

프로퍼티 이름 용도
hibernate.connection.datasource datasource JNDI 이름
hibernate.jndi.url NDI 프로바이더의 URL(옵션)
hibernate.jndi.class JNDI InitialContextFactory의 클래스 (옵션)
hibernate.connection.username 데이터베이스 사용자(옵션)
hibernate.connection.password 데이터베이스 사용자 패스워드(옵션)

다음은 어플리케이션 서버 제공 JNDI 데이터소스용 예제 hibernate.properties 파일이다:

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

JNDI datasource로부터 얻어진 JDBC 커넥션들은 어플리케이션 서버의 컨테이너에 의해 관리되는 트랜잭션들에 자동적으로 참여할 것이다.

임의의 커넥션 프로퍼티들은 프로퍼티 이름 앞에 "hibernate.connnection" 을 첨가하여 부여될 수 있다. 예를 들어 당신은 hibernate.connection.charSet을 사용하여 charSet을 지정할 수도 있다.

당신은 org.hibernate.connection.ConnectionProvider 인터페이스를 구현함으로써 JDBC 커넥션들을 얻는 당신 자신의 플러그인 방도를 정의할수도 있다. 당신은 hibernate.connection.provider_class를 설정하여 맞춤형 구현을 선택할 수도 있다.

3.4.  선택적인 구성 프로퍼티들

실행 시에 Hibernate의 행위를 제어하는 많은 다른 프로퍼티들이 존재한다. 모든 것이 옵션이지만 합당한 디폴트 값들을 갖는다. 

경고: 이들 프로퍼티들 중 몇몇은 ''system-level" 전용이다. 시스템 레벨 프로퍼티들은 오직 java -Dproperty=value 또는 hibernate.properties를 통해서만 설정될 수 있다. 그것들은 위에 설명된 다른 기법들에 의해 설정될 수 없다.  . 

표 3.3. Hibernate 구성 프로퍼티들

프로퍼티 이름 용도
hibernate.dialect Hibernate Dialect - 의 클래스명은 어떤 플랫폼 의존적인 특징들을 가능하도록 해준다. 

예. full.classname.of.Dialect

hibernate.show_sql 모든 SQL 문장들을 콘솔에 기록한다

예. true | false

hibernate.default_schema 생성된 SQL 내에 주어진 schema/tablespace로서 unqualified tablenames을 qualify 시킨다.  

예. SCHEMA_NAME

hibernate.default_catalog 주어진 SQL 내에 주어진 카타록으로서 unqualified tablenames을 qualify 시킨다.  

eg. CATALOG_NAME

hibernate.session_factory_name SessionFactory는 그것이 생성된 후에 JNDI 내에 있는 이 이름에 자동적으로 바인드 될 것이다.  

예. jndi/composite/name

hibernate.max_fetch_depth single-ended 연관관계들(one-to-one, many-to-one)의 경우에 outer join fetch 트리의 최대 "깊이"를 설정한다. 0 은 디폴트 outer join fetching을 사용불가능하게 만든다. 

예. 권장 03 사이의 값들이권장된다

hibernate.default_batch_fetch_size 연관들의 Hibernate 배치 페칭에 대한 디폴트 크기를 설정한다.

예. 권장되는 값들은 4, 8, 16

hibernate.default_entity_mode SessionFactory로부터 열려진 모든 세션들에 대해 엔티티 표현을 default 모드로 설정한다

dynamic-map, dom4j, pojo

hibernate.order_updates 업데이트 주인 항목들의 프라이머리 키 값에 의해 SQL 업데이트들이 순서(ordering) 지워지도록 Hibernate에게 강제시킨다. 이것은 고도의 동시성 시스템들에서 더 적은 트랜잭션 데드락들로 귀결될 것이다. 

예. true | false

hibernate.generate_statistics 가능할 경우, Hibernate는 퍼포먼스 튜닝에 유용한 통계들을 수집할 것이다.

예. true | false

hibernate.use_identifer_rollback 가능할 경우, 생성된 식별자 프로퍼티들은 객체가 삭제될 때 디폴트 값들로 재설정될 것이다.

예. true | false

hibernate.use_sql_comments 사용가능이 되면, Hibernate는 보다 쉬운 디버깅을 위해 SQL 내에 주석들을 생성시킬 것이다. 디폴트는 false.

예. true | false

표 3.4. Hibernate JDBC 및 커넥션 프로퍼티들

프로퍼티 이름 용도
hibernate.jdbc.fetch_size 0 아닌 값은 JDBC fetch 사이즈를 결정한다(Statement.setFetchSize()을 호출한다 ).
hibernate.jdbc.batch_size 0 아닌 값은 Hibernate에 의한 JDBC2 배치 업데이트의 사용을 이용 가능하게 한다. 

예. 권장되는 값들은 530 사이의 값

hibernate.jdbc.batch_versioned_data 당신의 JDBC 드라이버가 executeBatch()로부터 정확한 행 카운트들을 반환할 경우에 이 프로퍼티를 true 로 설정하라(대개 이 옵션을 사용 가능하게 하는 것이 안전하다). 그러면 Hibernate는 자동적으로 버전화 된 데이터에 대해 배치화된(batched) DML을 사용할 것이다. 디폴트는  false.

예. true | false

hibernate.jdbc.factory_class 맞춤형 Batcher를 선택한다. 대부분의 어플리케이션들은 이 구성 프로퍼티를 필요로 하지 않을 것이다. 

예. classname.of.Batcher

hibernate.jdbc.use_scrollable_resultset Hibernate에 의한 JDBC2 스크롤 가능한 결과셋들의 사용을 가능하게 해준다. 이 프로퍼티는 사용자가 제공한 JDBC커넥션들을 사용할 때에만 필수적이고, 그 밖의 경우 Hibernate는 커넥션 메타데이터를 사용한다.

예. true | false

hibernate.jdbc.use_streams_for_binary JDBC로 binary 또는 serializable 타입들을 기록하고/JDBC로부터 binary 또는 serializable타입 들을 읽어들일 때 스트림들을 사용한다(시스템 레벨 프로퍼티).

예. true | false

hibernate.jdbc.use_get_generated_keys insert 후에 고유하게 생성된 키들을 검색하는데 JDBC3 PreparedStatement.getGeneratedKeys()의 사용을 이용 가능하도록 만든다. JDBC3+ 드라이버와 JRE1.4+를 필요로 하고, 당신의 드라이버가 Hibernate 식별자 생성자들에 문제가 있을 경우에 false로 설정하라. 디폴트로 커넥션 메타 데이터를 사용하여 드라이버 가용성들을 결정하도록 시도하라.

예. true|false

hibernate.connection.provider_class Hibernate에 JDBC 커넥션들을 제공하는 맞춤형 ConnectionProvider의 클래스명.

예. classname.of.ConnectionProvider

hibernate.connection.isolation JDBC transaction isolation 레벨을 설정한다. 의미있는 값들로 java.sql.Connection을 체크하지만 대부분의 데이터베이스들이 모든 isolate 레벨들을 지원하지 않음을 유의하라.

예. 1, 2, 4, 8

hibernate.connection.autocommit JDBC 풀링된 커넥션들에 대해 자동커밋을 이용 가능하도록 한다(권장되지 않음).

예. true | false

hibernate.connection.aggressive_release Hibernate로 하여금 만일 지원될 경우 ConnectionProvider에 의해 지원되는 JDBC Connection들을 적극적으로 해제하는 것을 가능하도록 한다. 디폴트로 (연결 해제된 상태를 제외하면) 한 개의 JDBC 커넥션은 Session의 수명 동안 보관된다; 이것은 커넥션 "containment(봉쇄)" 체크들을 구현하는 관리 환경들에서는 잘 동작하지 않는다. 관리 환경들에서 권장됨.

eg. true | false

hibernate.connection.<propertyName> JDBC 프로퍼티 propertyNameDriverManager.getConnection()에 전달한다.
hibernate.jndi.<propertyName> propertyName 프로퍼티를 JNDI InitialContextFactory에 전달한다

표 3.5. Hibernate Cache 프로퍼티들

프로퍼티 이름 용도
hibernate.cache.provider_class 맞춤형 CacheProvider의 클래스명.

예. classname.of.CacheProvider

hibernate.cache.use_minimal_puts 읽기가 매우 빈번한 경우에, 쓰기를 최소화 시키기 위해 second-level 캐시 연산을 최적화 시킨다. 이 설정은 클러스터된 캐시들에 가장 유용하고, Hibernate3에서는 클러스터링된 캐시 구현들에 대해 디폴트로 이용 가능하다.

예. true|false

hibernate.cache.use_query_cache 질의 캐시를 가능하게 만든다. 개별적인 질의들은 여전히 캐시 가능으로 설정되어야 한다.

예. true|false

hibernate.cache.use_second_level_cache second-level 캐시를 완전히 사용 불가능하게 하는데 사용될 수 있고, 그것은 <cache> 매핑을 지정하는 클래스들에 대해 디폴트로 이용 가능이다.

예. true|false

hibernate.cache.query_cache_factory 맞춤형 QueryCache 인터페이스의 클래스명. 디폴트는 미리 빌드된  StandardQueryCache

예. classname.of.QueryCache

hibernate.cache.region_prefix second-level 캐시 영역 이름들에 사용할 접두어.

예. prefix

hibernate.cache.use_structured_entries 인간에게 보다 더 친숙한 형식으로 second-level 캐시 속에 데이터를 저장하도록 Hibernate에게 강제시킨다.

예. true|false

표 3.6. Hibernate Transaction 프로퍼티들

프로퍼티 이름 용도
hibernate.transaction.factory_class Hibernate Transaction API 에 사용할 TransactionFactory의 클래스 이름.(디폴트는 JDBCTransactionFactory).

예. classname.of.TransactionFactory

jta.UserTransaction 어플리케이션 서버로부터 JTA UserTransaction을  얻기 위해 JTATransactionFactory에 의해 사용되는 JNDI 이름.

예. jndi/composite/name

hibernate.transaction.manager_lookup_class TransactionManagerLookup 의 클래스명- JVM 레벨의 캐싱이 이용 가능할 때 또는 JTA 환경에서 hilo generator를 사용할 때 필요하다. 

예. classname.of.TransactionManagerLookup

hibernate.transaction.flush_before_completion 만일 사용가능토록 하면, 트랜잭션의 before completion 단계 동안에 세션이 자동적으로 flush 될 것이다.(CMT에 대해 Hibernate를 사용할 때 매우 유용하다.)

예. true | false

hibernate.transaction.auto_close_session 만일 사용가능토록 하면, before completion 단계 동안에 세션이 자동적으로 닫혀질 것이다. (CMT에 대해 Hibernate를 사용할 때 매우 유용하다.)

예. true | false

표 3.7. 여러가지 프로퍼티들

프로퍼티 이름 용도
hibernate.query.factory_class Chooses the HQL 파서 구현을 선택한다.

예. org.hibernate.hql.ast.ASTQueryTranslatorFactory 또는 org.hibernate.hql.classic.ClassicQueryTranslatorFactory

hibernate.query.substitutions Hibernate 질의들 내의 토큰들로부터 SQL 토큰들로의 매핑(예를 들어 토큰들은 함수 이름 또는 리터럴 이름일 수 있다).

예. hqlLiteral=SQL_LITERAL, hqlFunction=SQLFUNC

hibernate.hbm2ddl.auto SessionFactory 가 생성될 때 스키마 DDL을 데이터베이스로 자동적으로 내보낸다.  create-drop의 경우, SessionFactory 가 명시적으로 닫혀질 때,, 데이터베이스 스키마가 드롭될 것이다.

예. update | create | create-drop

hibernate.cglib.use_reflec
tion_optimizer
런타임 reflection 대신에 CGLIB의 사용을 가능하도록 만든다(시스템 레벨 프로퍼티).  Reflection은 문제가 발생할 시에 때때로 유용할 수 있고, 당신이 optimizer를 사용하지 않을 경우조차도 Hibernate는 항상 필요로 함을 유의하라. 당신은 ibernate.cfg.xml 속에 이 프로퍼티를 설정할수 없다.

예. true | false

3.4.1. SQL Dialects

당신은 항상 당신의 데이터베이스를 위해 hibernate.dialect 프로퍼티를 정확한 org.hibernate.dialect.Dialect 서브클래스로 설정해야 한다. 만일 당신이 dialect를 지정할 경우, 당신이 프로퍼티들을 수작업으로 지정하는 노력을 절약하도록 Hibernate는 위에 열거된 다른 프로퍼티들 중 몇몇에 대해  의미있는 디폴트들을 사용할 것이다.

표 3.8. Hibernate SQL Dialects (hibernate.dialect)

RDBMS Dialect
DB2 org.hibernate.dialect.DB2Dialect
DB2 AS/400 org.hibernate.dialect.DB2400Dialect
DB2 OS390 org.hibernate.dialect.DB2390Dialect
PostgreSQL org.hibernate.dialect.PostgreSQLDialect
MySQL org.hibernate.dialect.MySQLDialect
Oracle (any version) org.hibernate.dialect.OracleDialect
Oracle 9/10g org.hibernate.dialect.Oracle9Dialect
Sybase org.hibernate.dialect.SybaseDialect
Sybase Anywhere org.hibernate.dialect.SybaseAnywhereDialect
Microsoft SQL Server org.hibernate.dialect.SQLServerDialect
SAP DB org.hibernate.dialect.SAPDBDialect
Informix org.hibernate.dialect.InformixDialect
HypersonicSQL org.hibernate.dialect.HSQLDialect
Ingres org.hibernate.dialect.IngresDialect
Progress org.hibernate.dialect.ProgressDialect
Mckoi SQL org.hibernate.dialect.MckoiDialect
Interbase org.hibernate.dialect.InterbaseDialect
Pointbase org.hibernate.dialect.PointbaseDialect
FrontBase org.hibernate.dialect.FrontbaseDialect
Firebird org.hibernate.dialect.FirebirdDialect

3.4.2. Outer Join Fetching

만일 당신의 데이터베이스가 ANSI, Oracle, 또는 Sybase 스타일의 outer join들을 지원할 경우, outer join fetching은 (데이터베이스 그 자체에 의해 보다 더 많은 작업이 수행되는 비용으로) 데이터베이스로의 그리고 데이터베이스로부터의 라운드 트립들의 개수를 제한함으로써 종종 퍼포먼스를 증가시킬 것이다. Outer join fetching은 many-to-one, one-to-many, many-to-many,one-to-one  연관관계들이 에 의해 연결된 객체들의 전체 그래프가  하나의 SQL SELECT 속에서 검색되게끔 허용해준다.

Outer join fetching은 hibernate.max_fetch_depth  프로퍼티를 0으로 설정함으로써 전역적으로 사용 불가능하게 할 수 있다. 1 이상의 값을 설정하는 것은 fetch="join"으로 매핑되었던 모든 one-to-one 및 many-to-one 연관관계들에 대해 outer join fetching을 사용 가능하도록 만든다.

추가 정보는 19.1 절, “페칭 방도들”를 보라

3.4.3. Binary Streams

Oracle은 JDBC 드라이버 로/부터 전달되는 byte  배열들의 크기를 제한시킨다. 만일 당신이 binary 또는 serializable 타입의 대형 인스턴스를 사용하고자 원할 경우에, 당신은 hibernate.jdbc.use_streams_for_binary를 사용 가능하게 해야 할 것이다.  이것은 오직 시스템 레벨 설정이다.

3.4.4.  두 번째 레벨 캐시 및  query 캐시

hibernate.cache  접두어가 붙은 프로퍼티들은 Hibernate에 대해 프로세스 또는 클러스터 범위의 두 번째 레벨 캐시 시스템을 사용하는 것을 허용해준다. 상세한 것은 19.2 절, “Second Level 캐시”를 보라. 

3.4.5. Query Language 치환

당신은 hibernate.query.substitutions을 사용하여 새로운 Hibernate 질의 토큰들을 정의할 수 있다. 예를 들어:

hibernate.query.substitutions true=1, false=0

truefalse 토큰들로 하여금 생성된 SQL 내에서 정수 리터럴들로 번역되도록 강제할 것이다.

hibernate.query.substitutions toLowercase=LOWER

은 SQL LOWER  함수 이름을 변경하는 것을 당신에게 허용해 줄 것이다.

3.4.6. Hibernate 통계

만일 당신이 hibernate.generate_statistics를 사용 가능하도록 할 경우, Hibernate는 을 SessionFactory.getStatistics() 통해 시스템 실행을 튜닝할 때 유용한 많은 측정들을 노출시킬 것이다. Hibernate는 심지어 JMX를 통해 이들 통계들을 노출시키도록 구성될 수 있다. 추가 정보는 org.hibernate.stats에 있는 인터페이스에 관한 Javadoc를 읽어라.

3.5. 로깅

Hibernate는 Apache commons-logging를 사용하여 다양한 이벤트들을 로그시킨다. 

commons-logging 서비스는 (만일 당신이 classpath 내에 log4j.jar를 포함할 경우) Apache Log4j로 또는 (JDK1.4 이상의 버전에서 실행될 경우) JDK 1.4 로깅으로 직접 출력할 것이다. 당신은 http://jakarta.apache.org에서 Log4j를 다운로드 할 수 있다. Log4j를 사용하기 위해, 당신은 log4j.properties 파일을 당신의 classpath 내에 위치지울 필요가 있을 것이고, 예제 properties 파일은 Hibernate의  src/ 디렉토리 내에 배포되어 있다.

우리는 당신이 Hibernate의 로그 메시지들에 익숙해지는 것을 강력하게 권장한다. 많은 작업은 Hibernate 로그를 읽기 불가능하게 만들지 않게끔 가능한 한 상세하게 Hibernate 로그를 집어 넣었다. 그것은 본질적인 문제던지기 장치이다. 가장 흥미로운 로그 카테고리들이 다음에 있다:

표 3.9. Hibernate Log 카테고리들

카테고리 기능
org.hibernate.SQL SQL DML 문장들이 실행될 때 그것들 모두를 로그 시킨다
org.hibernate.type 모든 JDBC 파라미터들을 로그시킨다
org.hibernate.tool.hbm2ddl SQL DDL 문장들이 실행될 때 그것들 모두를 로그 시킨다
org.hibernate.pretty flush 시점에서 세션과 연관된 모든 엔티티들(최대 20개의 엔티티들)의 상태를 로그 시킨다
org.hibernate.cache 모든 second-level 캐시 액티비티를 로그시킨다
org.hibernate.transaction 트랜잭션 관련 액티비티를 로그 시킨다
org.hibernate.jdbc 모든 JDBC 리소스 취득을 로그 시킨다
org.hibernate.hql.ast HQL AST와 SQL AST 그리고 질의 파싱에 관한 다른 정보를 로그시킨다
org.hibernate.secure 모든 JAAS 허가 요청들을 로그시킨다
org.hibernate 모든 것을 로그시킨다(많은 정보이지만, 문제해결에 매우 유용하다)

Hibernate로 어플리케이션들을 개발할 때, 당신은 거의 항상 org.hibernate.SQL 카테고리에 대해 debug 모드로 설정하거나 hibernate.show_sql 프로퍼티를 이용가능하게 하여 작업해야 할 것이다.

3.6. NamingStrategy 구현하기

 org.hibernate.cfg.NamingStrategy 인터페이스는 데이터베이스 객체들과 스키마 요소들에 대한 "네이밍 표준"을 지정하는 것을 당신에게 허용해준다.

당신은 Java 식별자들로부터 데이터베이스 식별자들을 자동적으로 생성시키거나 매핑 파일에 주어진 "논리적" 컬럼과 테이블 이름들을 "물리적" 테이블과 컬럼 이름들로 자동적으로 처리하는 규칙들을 제공할 수 있다. 이 특징은 반복되는 노이즈(예를 들어 TBL_접두어들)를 제거함으로써, 매핑 문서의 말많은 장황함을 감소시키도록 도와준다. Hibernate에 의해 사용되는 디폴트 방도는 아주 작은 작품이다.

당신은 매핑들을 추가하기 이전에 Configuration.setNamingStrategy()를 호출함으로써 다른 방도를 지정할 수 있다:

SessionFactory sf = new Configuration()
.setNamingStrategy(ImprovedNamingStrategy.INSTANCE)
.addFile("Item.hbm.xml")
.addFile("Bid.hbm.xml")
.buildSessionFactory();

org.hibernate.cfg.ImprovedNamingStrategy 는 어떤 어플리케이션들에 대한 유용한 시작점일 수 있는 미리 빌드된 방도이다.

3.7. XML 구성 파일

구성에 대한 다른 접근법은 hibernate.cfg.xml로 명명된 파일 속에 전체 구성을 지정하는 것이다. 이 파일은 hibernate.properties 파일에 대한 대용물로서 사용될 수 있거나, 만일 둘 다 존재할 경우에 프로퍼티들을 중복정의하는데 사용될 수 있다.

XML 구성 파일은 디폴트로 당신의 CLASSPATH의 루트에 존재하는 것이 기대된다. 다음은 예제이다:

<?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 class="org.hibernate.auction.Item.bids" usage="read-write"/>

    </session-factory>

</hibernate-configuration>

당신이 볼 수 있듯이, 이 접근법의 장점은 구성에 대한 매핑 파일 이름들을 구체화 시키는 것이다. hibernate.cfg.xml은 또한 당신이 Hibernate 캐시를 튜닝해야할 때 보다 편리하다. hibernate.properties 또는 hibernate.cfg.xml 어느 것을 사용하는가는 당신의 선택이다. XML 구문을 사용하는 위에 언급된 이점들을 제외하면 둘다 같은 것임을 노트하라.

Hibernate 구성을 사용할 경우, Hibernate 사용은 다음과 같이 간단하다

SessionFactory sf = new Configuration().configure().buildSessionFactory();

당신은 다음을 사용하여 다른 XML 구성 파일을 찾아낼 수 있다

SessionFactory sf = new Configuration()
.configure("catdb.cfg.xml")
.buildSessionFactory();

3.8. J2EE 어플리케이션 서버 통합

Hibernate는 J2EE 인프라스트럭처에 대한 다음 통합 점들을 갖고 있다:

  • Container-managed datasources: Hibernate는 컨테이너에 의해 관리되는 JDBC 커넥션들을 사용할 수 있고 JNDI를 통해 제공된다. 대개 JTA 호환 TransactionManagerResourceManager는 트랜잭션 관리(CMT), 특히 몇몇 데이터소스들을 가로질러 분산된 트랜잭션 핸들링을 처리한다. 물론 당신은 또한 프로그램 상으로 트랜잭션 경계들을 한정할 수도 있거나(BMT) 당신은 당신의 코드가 이식성을 유지하도록 이것에 대한 선택적인 Hibernate Transaction API를 사용하고자 원할 수도 있다. 
  • 자동적인 JNDI 바인딩: Hibernate는 시작 후에 그것의 SessionFactory를 JNDI에 바인드 시킬 수 있다.
  • JTA Session 바인딩: Hibernate Session은 당신이 EJB들을 사용하고자 원할 경우에 JTA 트랜잭션들의 영역(scope)에 자동적으로 바인드 시킬 수도 있다. 간단하게 JNDI로부터 SessionFactory를 룩업하고 현재 Session을 얻어라. Hibernate로 하여금 당신의 JTA 트랜잭션이 완료될 때 Session을 flush시키고 닫는 것을 처리하도록 하라. 트랜잭션 경계 설정은 EJB 배치 디스크립터들 내에서 선언적이다. 
  • JMX 배치: 만일 당신이 JMX 가용성이 있는 어플리케이션 서버(예를 들면 JBoss AS)를 갖고 있다면, 당신은 Hibernate를 하나의 managed MBean으로서 배치하는 것을 선택할 수 있다. 이것은 Configuration으로부터 당신의 SessionFactory를 빌드 시키는 한 줄의 시작 코드를 절약해준다. 컨테이너는 당신의 HibernateService를 시작할 것이고, 또한 이상적으로 서비스 의존성들을 처리할 것이다(데이터소스는 Hibernate가 시작되기 전에 이용 가능해야 한다).

당신의 환경에 따라, 당신은 당신의 어플리케이션 서버가 "connection containment(연결 봉쇄)" 예외상황들을 보일 경우에 구성 옵션 hibernate.connection.aggressive_release를 true로 설정해야 될 수도 있다.

3.8.1. 트랜잭션 방도 구성

Hibernate Session API는 당신의 아카텍처 내에서 임의의 트랜잭션 관할 시스템에 독립적이다. 만일 당신이 Hibernate로 하여금 커넥션 풀을 통해 직접 JDBC를 사용하도록 강제할 경우, 당신은 JDBC API를 호출하여 당신의 트랜잭션을 시작하고 끝낼 수 있다. 만일 당신이 J2EE 어플리케이션 서버를 실행 중이라면, 당신은 필요할 때 bean-managed 트랜잭션들을 사용하고 JTA API와 UserTransaction을 호출하고자 원할 수 있다. 

이들 두 개의 (그리고 다른) 환경들에서 당신의 코드에 이식성을 유지하기 위해 우리는 기본 시스템을 포장하고 은폐시키는 선택적인 Hibernate Transaction API를 권장한다. 당신은 Hibernate 구성 프로퍼티 hibernate.transaction.factory_class를 사용하여 Transaction 인스턴스들에 대한 팩토리 클래스를 지정해야 한다.

세 개의 표준(미리 만들어진) 선택들이 존재한다:

org.hibernate.transaction.JDBCTransactionFactory
데이터베이스 (JDBC) 트랜잭션들에게 위임시킨다(디폴트)
org.hibernate.transaction.JTATransactionFactory
기존의 트랜잭션이 이 컨텍스트(예를 들면 EJB session bean 메소드) 내에서 진행 중일 경우에 container-managed transaction에게 위임시키고, 그 밖의 경우 새로운 트랜잭션이 시작되고 bean-managed transaction이 사용된다. 
org.hibernate.transaction.CMTTransactionFactory
container-managed JTA 트랜잭션들에게 위임시킨다

당신은 또한 당신 자신의 트랜잭션 방도들(예를 들면 CORBA 트랜잭션 서비스)을 정의할 수도 있다.

Hibernate에 있는 몇몇 특징들(예를 들면. second level 캐시, 자동적인 JTA 및 Session 바인딩, 기타)은 관리되는 환경에서 JTA TransactionManager에 대한 접근을 필요로 한다. 어플리케이션 서버에서 당신은 Hibernate가 TransactionManager에 대한 참조를 획득하는 방법을 지정해야 한다. 왜냐하면 J2EE가 한 개의 메커니즘을 표준화 시키고 있지 않기 때문이다:

표 3.10. JTA TransactionManagers

트랜잭션 팩토리 어플리케이션 서버
org.hibernate.transaction.JBossTransactionManagerLookup JBoss
org.hibernate.transaction.WeblogicTransactionManagerLookup Weblogic
org.hibernate.transaction.WebSphereTransactionManagerLookup WebSphere
org.hibernate.transaction.WebSphereExtendedJTATransactionLookup WebSphere 6
org.hibernate.transaction.OrionTransactionManagerLookup Orion
org.hibernate.transaction.ResinTransactionManagerLookup Resin
org.hibernate.transaction.JOTMTransactionManagerLookup JOTM
org.hibernate.transaction.JOnASTransactionManagerLookup JOnAS
org.hibernate.transaction.JRun4TransactionManagerLookup JRun4
org.hibernate.transaction.BESTransactionManagerLookup Borland ES

3.8.2. JNDI-bound SessionFactory

하나의 JNDI 바인드된 Hibernate SessionFactory는 그 팩토리에 대한 룩업과 새로운 Session들의 생성을 단순화 시킬 수 있다. 이것은 JNDI 바인드된 Datasource에 관련되어 있지 않고, 단순하게 둘 다 동일한 레지스트리를 사용한다는 점을 노트하라! 

만일 당신이 SessionFactory를 하나의 JNDI namespace에 바인드 시키고자 원할 경우, hibernate.session_factory_name 프로퍼티를 사용하여 한 개의 이름(예를 들면. java:hibernate/SessionFactory)을 지정하라. 만일 이 프로퍼티가 생략될 경우, SessionFactory는 JNDI에 바인드 되지 않을 것이다. (이것은 읽기-전용 JNDI 디폴트 구현을 가진 환경들, 예를 들면 Tomcat에서 특히 유용하다.)

SessionFactory를 JNDI에 바인드 시킬 때, Hibernate는 초기 컨텍스트를 초기화 시키기 위해 hibernate.jndi.url, hibernate.jndi.class의 값들을 사용할 것이다. 만일 그것들이 지정되어 있지 않을 경우, 디폴트 InitialContext가 사용될 것이다.

Hibernate는 당신이 cfg.buildSessionFactory()를 호출한 후에 SessionFactory를 JNDI 내에 자동적으로 위치지울 것이다. 이것은 당신이 (나중에 논의되는) HibernateService를 가진 JMX 배치를 사용하지 않는 한, 당신이 적어도 당신의 어플리케이션 내에 있는 어떤 시작 코드 (또는 유틸리티 클래스) 내에서 이것을 호출할 것임을 의미한다. 

만일 당신이 하나의 JNDI SessionFactory를 사용할 경우, 하나의 EJB 또는 어떤 다른 클래스는 JNDI 룩업을 사용하여 SessionFactory를 얻을 수 있다. 만일 당신이 제 1장에서 소개된 하나의 Singleton 레지스트리로서 행동하는 HibernateUtil helper 클래스를 사용할 경우 이 셋업이 필수적이지 않음을 노트하라. 하지만 HibernateUtil은 관리되지 않는 환경에서 보다 공통적이다.

3.8.3. 자동적인 JTA 및 Session 바인딩

관리되지 않는 환경들에서 우리는 static SessionFactory, 그리고 Hibernate Session에 대한 ThreadLocal 관리를 가진 HibernateUtil을 제안했다. 몇몇 EJB들이 동일 트랜잭션 내에서 실행되지만 동일 쓰레드 내에서 실행되지 않을 수 있으므로, 이 접근법은 EJB 환경에서 사용하기가 쉽지 않다. 우리는 당신이 관리되는 환경에서 SessionFactory를 JNDI에 바인드 시키는 것을 권장한다. 

당신 자신의 유틸리티를 조작하는 대신, Hibernate Session을 얻는데 SessionFactory 상의 getCurrentSession() 메소드를 사용하라. 만일 현재의 JTA 트랜잭션 내에 Hibernate Session이 존재하지 않을 경우, 세션이 시작되고 할당될 것이다. hibernate.transaction.flush_before_completionhibernate.transaction.auto_close_session 구성 옵션 둘 다 모든 Session에 대해 자동적으로 설정될 것이고 당신은 getCurrentSession()으로 검색하여서, 세션들은 또한 컨테이너가 JTA 트랜잭션들을 끝낼 때 자동적으로 flush되고 닫혀질 것이다. 

예를 들어 만일 당신이 당신의 영속 계층을 작성하는데 DAO 디자인 패턴을 사용할 경우, 모든 DAO는 필요할 때 SessionFactory를 룩업하고 "현재(current)" Session을 연다. 제어 코드와 DAO 코드 사이에서 SessionFactory 또는 Session의 인스턴스들을 전달할 필요가 없다. 

3.8.4. JMX 배치

cfg.buildSessionFactory() 줄은 여전히 JNDI에 붙은 하나의 SessionFactory를 얻기 위해 어딘가에서 실행되어야 한다. 당신은 (내에 있는 것처럼) static initializer 블록 속에서 이것을 행할 수 있거나 당신은 Hibernate를 managed service로서 배치할 수 있다.

Hibernate는 JBoss AS와 같은 JMX 가용성들을 가진 어플리케이션 서버 상의 배치를 위해 org.hibernate.jmx.HibernateService를 배포하고 있다. 실제 배치와 구성은 벤더 지정적이다. 다음은 JBoss 4.0.x를 위한 jboss-service.xml 예제이다:

<?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>

이 파일은 META-INF로 명명된 디렉토리 속에 배치되고 확장자 .sar (service archive)를 가진 한 개의 JAR 파일 속에 패키징된다. 당신은 또한 Hibernate, 그것의 필요한 제 3의 라이브러리들, 당신의 컴파일된 영속 클래스들 뿐만 아니라 당신의 매핑 파일들을 동일한 아카이브 속에 패키징할 필요가 있다. 당신의 엔터프라이즈 빈즈(대개 session beans)는 그것들 자신의 JAR 파일 속에 유지될 수 있지만, 당신은 한 개의 (hot-)배치 가능한 단위를 얻기 위해 메인 서비스 아카이브 속에 이 EJB JAR 파일을 포함시킬 수도 있다. JMX 서비스와 EJB 배치에 관한 추가 정보는 JBoss AS 문서를 참조하라.

제 4장. 영속 클래스들

영속 클래스들은 비지니스 문제의 엔티티들(예를 들어 E-Commerce 어플리케이션에서 고객이나 주문)을 구현하는 어플리케이션 내의 클래스들이다. 영속 클래스들의 인스턴스들은 영속 상태에 있는 것으로 전혀 간주되지 않는다 - 대신에 하나의 인스턴스는 transient 또는 detached 상태일 수 있다.

Hibernate는 이들 클래스들이 Plain Old Java Object (POJO) 프로그래밍 모형으로서 알려진, 몇몇 간단한 규칙들을 따를 경우에 가장 잘 동작한다. 하지만 이들 규칙들 중 어떤 것도 어려운 사양들이 아니다. 진정 Hibernate3는 당신의 영속 객체들의 특징에 대해 매우 적은 것을 가정한다. 당신은 다른 방법들로 도메인 모형을 표현할 수 있다 : 예를 들어 Map 인스턴스의 트리들을 사용하여.

4.1.  간단한 POJO 예제

대부분의 자바 어플리케이션들은 고양이과들을 표현하는 영속 클래스를 필요로 한다.

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);
    }
}

준수할 네 개의 주요 규칙들이 다음에 있다:

4.1.1.  영속 필드들을 위한 accessor들과 mutator들을 선언하라

Cat 은 그것의 모든 영속 필드들에 대해 accessor 메소드들을 선언한다. 많은 다른 ORM 도구들은 직접 인스턴스 변수들을 영속화 시킨다. 우리는 이 구현 상세를 영속 메커니즘과 분리시키는 것이 훨씬 더 낫다고 생각한다. Hibernate는 자바빈즈 스타일의 프로퍼티들을 영속화 시키고, getFoo, isFoo, setFoo 형식의 메소드 이름들을 인지한다.  하지만 당신은 필요할 경우 특정 프로퍼티들에 대해 직접적인 필드 접근으로 전환할 수도 있다.

프로퍼티들은 public 으로 선언될 필요가 없다 - Hibernate는 디폴트로 protected get/set 쌍 또는 private  get/set 쌍을 가진 프로퍼티를 영속화 시킬 수 있다. 

4.1.2.  아규먼트 없는 생성자를 구현하라

Cat 은 아규먼트 없는 생성자를 갖는다. 모든 영속 클래스들은 Hibernate는 Constructor.newInstance ()를 사용하여 그것들을 초기화 시킬 수 있도록 디폴트 생성자(public이 아닐 수 있다)를 가져야 한다. 우리는 Hibernate에서 실행 시 프락시 생성을 위한 최소한의  package visibility를 가진 생성자를 가질 것을 권장한다.

4.1.3.  identifier 프로퍼티를 제공하라(옵션)

Catid로 명명된 하나의 프로퍼티를 갖는다. 이 프로퍼티는 데이터베이스 테이블의 프라이머리 키 컬럼으로 매핑된다. 이 프로퍼티는  어떤 것으로 명명될 수도 있고, 그것의 타입은 임의의 원시 타입, 원시 "wrapper" 타입, java.lang.String 또는 java.util.Date일 수 있다. (만일 당신의 리거시 데이터베이스 테이블이 composite 키들을 갖고 있다면, 당신은 이들 타입들을 가진 사용자 정의 클래스를 사용할 수도 있다 - 나중에 composite 식별자들에 대한 절을 보라)

identifier 프로퍼티는 엄격하게 옵션이다. 당신은 그것을 생략할 수도 있고, Hibernate로 하여금 내부적으로 객체 식별자들을 추적하도록 할 수 있다. 하지만 우리는 이것을 권장하지 않는다.

사실, 어떤 기능은 identifier 프로퍼티를 선언하는 클래스들에 대해서만 이용 가능하다:

를 보라.

우리는 당신이 영속 클래스들에 대해 일관되게 명명된 identifier 프로퍼티들을 선언할 것을 권장한다. 게다가 우리는 당신이 nullable 타입(예를 들어 non-primitive)을 사용할 것을 권장한다.

4.1.4.  final이 아닌 클래스들을 선호하라(옵션)

Hibernate의 중심 특징인, 프락시(proxy)들은 final이 아닌 영속 클래스들 또는 모두 public 메소드들로 선언된 인터페이스의 구현인 영속 클래스들에 의존한다.

당신은 Hibernate로 인터페이스를 구현하지 않은 final 클래스들을 영속화 시킬 수 있지만 당신은 lazy 연관 페칭(lazy association fetching)에 대해 프락시들을 사용할 수 없을 것이다 -그것은 퍼포먼스 튜닝을 위한 당신의 옵션들을 제한시킬 것이다.

당신은 또한 non-final 클래스들 상에 public final 메소드들을 선언하는 것을 피해야 한다. 만일 당신이 public final 메소드를 가진 클래스를 사용하고자 원할 경우, 당신은 lazy="false"를 설정함으로써 명시적으로 프락싱을 불가능하도록 해야 한다.

4.2. 상속 구현하기

서브클래스는 또한 첫 번째 규칙들과 두 번째 규칙들을 주시해야 한다. 그것은 슈퍼클래스 Cat 로부터 그것의 identifier 프로퍼티를 상속받는다. 

package eg;

public class DomesticCat extends Cat {
        private String name;

        public String getName() {
                return name;
        }
        protected void setName(String name) {
                this.name=name;
        }
}

4.3. equals()hashCode() 구현하기

만일 당신이 영속 클래스들의 인스턴스들을 Set(many-valued 연관관계들에 대해 권장되는 방법)  속에 집어넣고자 원하고 detached 인스턴스들의 reattachment(재첨부)를 사용하려고 할 경우에 당신은 equals()hashCode() 메소드들을 오버라이드 시켜야 한다.

Hibernate는 특정 session 범위 내에서만 persistent identity(데이터베이스 행)과 Java identity의 같음을 보장한다.  따라서 우리가 다른 세션들에서 검색된 인스턴스들을 혼합시키자마자, 우리가 Set들에 대해 유의미하게 만들고자 원할 경우,  우리는 equals()hashCode()를 구현해야 한다.

가장 명백한 방법은 두 객체들의 identifier 값을 비교함으로써 equals()/hashCode()를 구현하는 것이다. 만일 그 값이 동일하다면, 둘다 동일한 데이터베이스 행이어야 하고, 그러므로 그것들은 같다(둘다 하나의 Set에 추가되는 경우에, 우리는 Set 속에서 하나의 요소만을 갖게 될 것이다). 불행하게도, 우리는 생성된 식별자들에 대해 그 접근법을 사용할 수 없다! Hibernate는 오직 identifier 값들을 영속화 되는 객체들에 할당할 것이고, 새로이 생성된 인스턴스는 임의의 identifier 값을 갖지 않을 것이다! 만일 인스턴스가 저장되지 않고 현재 Set 속에 있을 경우, 그것을 저장하는것은 하나의 identifier 값을 그 객체에게 할당할 것이다. 만일 equals()와  hashCode()가 identifier 값에 기초할 경우, hash 코드는 Set의 계약을 파기하여 변경될 것이다. 이 문제에 대한 전체 논의에 대해서는 Hibernate 웹 사이트를 보라. 이것은 Hibernate 쟁점이 아니지만, 객체 identity와 equality에 관한 통상의 자바 의미론임을 노트하라.

우리는 Business key equality를 사용하여 equals()hashCode()를 구현할 것 권장한다. Business key equality는 equals() 메소드가 비지니스 키, 즉 실세계에서 우리의 인스턴스를 식별하게 될 키(natural 후보 키)를 형성하는 프로퍼티들만을 비교한다는 점을 의미한다 :

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;
    }

}

하나의 비지니스 키는 데이터베이스 프라이머리 키 후보 만큼 견고하지 않아야 한다(11.1.3절, “객체 identity 고려하기”를 보라.). 대개 변경할 수 없는 프로퍼티 또는 유일한(unique) 프로퍼티는 대개 비지니스 키에 대한 좋은 후보들이다.

4.4. 동적인 모형들

다음 특징들은 현재 실험적으로 고려되고 있으며 장래의 특징에서 변경될 수 있다.

영속 엔티티들은 반드시 실행시에 POJO 클래스들로 또는 자바빈즈 객체들로 표현되어야할 필요는 없다. Hibernate는 또한 (실행 시에 Map들을 가진 Map들을 사용하여) 동적인 모형들을 지원하고 DOM4J 트리로서 엔티티들의 표현을 지원한다. 이 접근법으로, 당신은 영속 클래스들을 작성하지 않고, 오직 매핑 파일들 만을 작성한다.

디폴트로, Hibernate는 통산의 POJO 모드로 동작한다. 당신은 default_entity_mode 구성 옵션을 사용하여 특별한 SessionFactory에 대해 디폴트 엔티티 표현 모드를 설정할 수 있다( 3.3, “Hibernate 구성 프로퍼티들”을 보라).

다음 예제들은 Map들을 사용하는 표현을 설명한다. 먼저 매핑 파일에서, entity-name이 클래스 이름 대신에(또는 클래스 이름에 덧붙여) 선언되어야 한다:

<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>

런타임 시에, 당신은 단지 HashMaps를 초기화 시키고 특별한 타입을 참조하는데 Hibernate 엔티티 이름을 사용한다:

심지어 비록 연관들이 대상(target) 클래스 이름들을 사용하여 선언될지라도, 연관들의 대상(target) 타입은 또한 POJO가 아닌 동적인 엔티티일 수 있음을 노트하라.

SessionFactory에 대한 디폴트 엔티티 모드를 dynamic-map으로 설정한 후에, 우리는 Map들을 가진 Map들에 대해 실행 시에 동작할 수 있다:

Session s = openSession();
Transaction tx = s.beginTransaction();
Session s = openSession();

// 고객을 생성시킨다 
Map david = new HashMap();
david.put("name", "David");

// 조직을 생성시킨다 
Map foobar = new HashMap();
foobar.put("name", "Foobar Inc.");

// 양자를 연결한다
david.put("organization", foobar);

// 양자를 저장한다
s.save("Customer", david);
s.save("Organization", foobar);

tx.commit();
s.close();

dynamic 매핑의 장점들은 엔티티 클래스 구현에 대한 필요 없이도 프로토타이핑을 위한 빠른 전환 시간이다. 하지만 당신은 컴파일 시 타입 체킹을 잃고 실행 시에 많은 예외상황들을 다루게 될 것이다. Hibernate 매핑 덕분에, 데이터베이스 스키마는 고유한 도메인 모형 구현을 나중에 상단에 추가하는 것을 허용하여 쉽게 정규화 되고 소리가 울려 퍼질 수 있다.

엔티티 표현 모드들은 또한 하나의 단위 Session 기준에 대해 설정될 수 있다:

Session dynamicSession = pojoSession.getSession(EntityMode.MAP);

// 고객을 생성한다
Map david = new HashMap();
david.put("name", "David");
dynamicSession.save("Customer", david);
...
dynamicSession.flush();
dynamicSession.close()
...
// pojoSession을 계속 진행한다

EntityMode 를 사용하는 getSession() 호출은 SessionFactory가 아닌, Session API에 대한 것임을 노트하길 바란다. 그 방법으로, 새로운 Session은 기본 JDBC 커넥션, 트랜잭션, 그리고 다른 컨텍스트 정보를 공유한다. 이것은 당신이 두 번째 에 대해 flush()close()를 호출하지 말아야 하고 또한 트랜잭션과 커넥션 핸들링을 주된 작업 단위에게 위임하지 말아야 함을 의미한다.

XML 표현 가용성들에 대한 추가 정보는 18 장, XML 매핑에서 찾을 수 있다.

TODO: property 패키지와 proxy 패키지 내에 user-extension 프레임웍을 문서화 할 것.

제 5장. 기본 O/R 매핑

5.1.  매핑 선언

객체/관계형 매핑들은 대개 XML 문서로 정의된다. 매핑 문서는 가독성이 있고 수작업 편집이 가능하도록 설계되어 있다. 매핑 언어는 매핑들이 테이블 선언들이 아닌, 영속 클래스 선언들로 생성된다는 의미에서 자바 중심적이다.

심지어 많은 Hibernate 사용자들이 수작업으로 XML을 작성하고자 선택할지라도, XDoclet, Middlegen, 그리고 AndroMDA를 포함하는, 매핑 문서를 생성시키는 많은 도구들이 존재한다는 점에 주목하라.

예제 매핑으로 시작하자:

<?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>

우리는 이제 매핑 문서의 내용을 논의할 것이다. 우리는 Hibernate에 의해 실행 시에 사용되는 문서 요소들과 속성들 만을 설명할 것이다. 매핑 문서는 또한 스키마 내보내기 도구에 의해 내보내진 데이터베이스 스키마에 영향을 주는 어떤 특별한 옵션 속성들과 요소들을 포함한다. (예를 들어 not-null 속성.)

5.1.1. Doctype

모든 XML 매핑들은 doctype이 보이게 선언해야 한다. 실제 DTD는 위의 URL에서, hibernate-x.x.x/src/org/hibernate 디렉토리 내에서 또는 hibernate3.jar 내에서 찾을 수 있다. Hibernate는 항상 첫 번째로 그것의 classpath 속에서 DTD를 찾게 될 것이다. 만일 당신이 인터넷 연결을 사용하는 DTD에 대한 룩업들을 겪게 될 경우, 당신의 classpath의 컨텐츠에 대해 당신의 DTD 선언을 체크하라.

5.1.2. hibernate-mapping

이 요소는 몇 개의 선택적인 속성들을 갖는다. schema 속성과 catalog 속성은 이 매핑 내에서 참조된 테이블들이 명명된 schema 와/또는 catalog에 속한다는 점을 지정한다. 만일 지정될 경우, 테이블 이름들은 주어진 schema 이름과 catalog 이름에 의해 한정(수식)될 것이다. 누락될 경우, 테이블 이름들은  한정되지((수식어가 붙지) 않을 것이다. default-cascade 속성은 cascade 속성을 지정하지 않은 프로퍼티들과 콜렉션들에 대해 전제될 cascade 스타일이 무엇인지를 지정한다.  auto-import 속성은 디폴트로 우리가 질의 언어 속에서 수식어가 붙지 않은(unqualified) 클래스 이름들을 사용하게 할 것이다.

<hibernate-mapping
         schema="schemaName"                          (1)
         catalog="catalogName"                        (2)
         default-cascade="cascade_style"              (3)
         default-access="field|property|ClassName"    (4)
         default-lazy="true|false"                    (5)
         auto-import="true|false"                     (6)
         package="package.name"                       (7)
 />
(1)

schema (옵션): 데이터베이스 스키마의 이름.

(2)

catalog (옵션): 데이터베이스 카다록의 이름.

(3)

default-cascade (옵션 - 디폴트는 none): 디폴트 cascade 스타일.

(4)

default-access (옵션 - 디폴트는 property): Hibernate가 모든 프로퍼티들에 액세스하는데 사용하게 될 방도. PropertyAccessor의 맞춤형 구현일 수 있다.

(5)

default-lazy (옵션 - 디폴트는 true): class 매핑과 collection 매핑의 지정되지 않은 lazy 속성들에 대한 디폴트 값.

(6)

auto-import (옵션 - 디폴트는 true): 우리가 질의 언어 내에 (이 매핑에서 클래스들에 대해) 수식어가 붙지 않은 클래스 이름들을 사용할 수 있는지를 지정한다.

(7)

package (옵션): 매핑 문서 내에서 수식어가 붙지 않은 클래스 이름들에 대해 가정할 패키지 접두어를 지정한다.

만일 당신이 동일한 (수식어가 붙지 않은) 이름을 가진 두 개의 영속 클래스들을 갖고 있다면, 당신은 auto-import="false"를 설정해야 한다. 만일 당신이 두 개의 클래스들에 동일한 "imported" 이름을  할당하려고 시도할 경우에 Hibernate는 예외상황을 던질 것이다.

위에 보여진 것처럼 hibernate-mapping 요소는 몇몇 영속 <class> 매핑들을 내부에 포함하는 것을 허용해준다는 점을 노트하라. 하지만 한 개의 매핑 파일 속에 한 개의 영속 클래스(또는 한 개의 클래스 계층구조) 만을 매핑하고 영속 서브 클래스 뒤에 그것을 명명하는 것이 좋은 연습이다 (그리고 몇몇 도구들에 의해 기대된다). 예를 들면 Cat.hbm.xml, Dog.hbm.xml 또는 상속을 사용할 경우에는 Animal.hbm.xml.

5.1.3. class, dynamic-class

당신은 class 요소를 사용하여 영속 클래스를 선언할 수도 있다:

<class
        name="ClassName"                              (1)
        table="tableName"                             (2)
        discriminator-value="discriminator_value"     (3)
        mutable="true|false"                          (4)
        schema="owner"                                (5)
        catalog="catalog"                             (6)
        proxy="ProxyInterface"                        (7)
        dynamic-update="true|false"                   (8)
        dynamic-insert="true|false"                   (9)
        select-before-update="true|false"             (10)
        polymorphism="implicit|explicit"              (11)
        where="arbitrary sql where condition"         (12)
        persister="PersisterClass"                    (13)
        batch-size="N"                                (14)
        optimistic-lock="none|version|dirty|all"      (15)
        lazy="true|false"                             (16)
        entity-name="EntityName"                      (17)
        check="arbitrary sql check condition"         (18)
        rowid="rowid"                                 (19)
        subselect="SQL expression"                    (20)
        abstract="true|false"                         (21)
        entity-name="EntityName"
/>
(1)

name: 영속 클래스(또는 인터페이스)의 전체 수식어가 붙은 Java 클래스 이름. 만일 이 속성이 누락될 경우, 매핑이 비-POJO 엔티티라고 가정된다.

(2)

table (옵션- 디폴트는 수식어가 붙지 않은 클래스명): 그것의 데이터베이스 테이블의 이름.

(3)

discriminator-value (옵션 - 디폴트는 클래스명): 다형성(polymorphic) 특징에 사용되는 개별 서브 클래스들를 구별짓는 값. 허용가능한 값은 null과  not null을 포함한다.

(4)

mutable (옵션, 디폴트는 true): 클래스들의 인스턴스들이 가변적인지를(가변적이지 않은지를) 지정한다.

(5)

schema (옵션): 루트 <hibernate-mapping> 요소에 의해 지정된 schema 이름을 오버라이드 한다.

(6)

catalog (옵션): 루트 <hibernate-mapping> 요소에 의해 지정된 catalog 이름을 오버라이드 한다.

(7)

proxy (옵션): lazy initializing proxy들에 사용할 인터페이스를 지정한다. 당신은 클래스 그 자체의 이름을 지정할 수 도 있다.

(8)

dynamic-update (옵션, 디폴트는 false): UPDATE SQL이 실행 시에 생성되고 그들 컬럼들의 값들이 변경된 그들 컬럼들 만을 포함할 것인지를 지정한다.

(9)

dynamic-insert (옵션, 디폴트는 false): 생성될 INSERT SQL이 실행 시에 생성되고 그들 컬럼들의 값이 null이 아닌 컬럼들 만을 포함할 것인지를 지정한다.

(10)

select-before-update (옵션, 디폴트는 false): 객체가 실제로 변경되는 것이 확실하지 않는 한, Hibernate가 SQL UPDATE결코 실행하지 않을 것인지를 지정한다. 어떤 경우들에서(실제로 transient 객체가 update()를 사용하여 새로운 session에 연관되었을 때에만), 이것은 UPDATE 가 실제로 필요한 경우인지 여부를 결정하기 위해 Hibernate가 특별한 SQL SELECT를 실행할 것이라는 점을 의미한다.

(11)

polymorphism (옵션, 디폴트는 implicit): implicit 질의 다형성 또는 explicit 질의 다형성 중 어느 것이 사용될 것인지를 결정한다. 

(12)

where (옵션) 이 클래스의 객체들을 검색할 때 사용될 임의적인 SQL WHERE 조건을 지정한다.

(13)

persister (옵션): 맞춤형 ClassPersister를 지정한다.

(14)

batch-size (옵션, 디폴트는 1): 이 클래스의 인스턴스들을 identifier로 페칭하는 "배치 사이즈"를 지정한다.

(15)

optimistic-lock (옵션, 디폴트는 version): optimistic 잠금 방도를 결정한다.

(16)

lazy (옵션): Lazy fetching은 lazy="false"를 설정함으로써 전체적으로 사용불가능하게 될 수 있다.

(17)

entity-name (옵션): Hibernate3는  클래스가 (잠정적으로 다른 테이블들로) 여러 번 매핑되는 것을 허용하고, 자바 레벨에서 Map들과 XML에 의해 표현되는 엔티티 매핑들을 허용하고 Java 레벨에서 Map들 또는 XML에 의해 표현되는 엔티티 매핑들을 허용한다. 이들 경우들에서, 당신은 그 엔티티들에 대한 명시적인 이름을 제공해야 한다. 추가 정보는 4.4 절, “동적인 모형들”18 장, XML 매핑을 보라.

(18)

check (옵션): 자동적인 스키마 생성을 위한 multi-row check constraint를 생성시키는데 사용되는 SQL 표현식.

(19)

rowid (옵션):  Hibernate는 지원되는 데이터베이스들 예를 들면 Oracle 상에서 이른바 ROWID들을 사용할 수 있고, Hibernate는 당신이 이 옵션을 rowid로 설정한 경우에 빠른 업데이트를 위해 특별한 rowid 컬럼을 사용할 수 있다. ROWID는 구현 상세이고 저장된 튜플(tuple)의 물리적이니 위치를 표현한다.

(20)

subselect (옵션): 불변의 읽기 전용 엔티티를 데이터베이스 subselect로 매핑시킨다. 당신이 기본 테이블 대신에 뷰를 갖고자 원할 경우에 유용하지만, 사용을 자제하라. 추가 정보는 아래를 보라.

(21)

abstract (옵션): <union-subclass> 계층 구조들 내에서 abstract superclass들을 마크하는데 사용된다.

명명된 영속 클래스가 인터페이스가 되는 것은 완전히 수용가능하다. 그런 다음 당신은 <subclass> 요소를 사용하여 그 인터페이스에 대한 구현 클래스들을 선언할 것이다. 당신은 임의의 static inner 클래스를 영속화 시킬 수도 있다.  당신은 표준 형식, 예를 들어 eg.Foo$Bar를 사용하여 클래스 이름을 지정해야 한다.

변할 수 없는 클래스, mutable="false"은 어플리케이션에 의해 업데이트되지 않을 것이거나 삭제되지 않을 것이다. 이것은  Hibernate로 하여금 어떤 마이너 퍼포먼스 최적화를 행하게끔 허용해준다.

선택적인 proxy 속성은 그 클래스의 영속 인스턴스들에 대한 lazy initialization을 가능하게 해준다. Hibernate는 명명된 인터페이스를 구현하는 CGLIB 프락시들을 초기에 반환할 것이다. 실제 영속 객체는 프락시의 메소드가 호출될 때 로드될 것이다. 아래 "Lazy 초기화를 위한 프락시들"을 보라.

Implicit 다형성은 클래스의 인스턴스들이 어떤 서브클래스나 구현된 인터페이스 또는 클래스를 명명하는 질의에 의해 반환될 것임을 의미하고 그 클래스의 어떤 서브클래스에 대한 인스턴스들이 그 클래스 자체를 명명하는 질의에 의해 반환될 것임을 의미한다.  Explicit 다형성은 클래스 인스턴스들이 그 클래스를 명시적으로 명명하는 질의들에 의해서만 반환될 것임을 의미고 그 클래스를 명명하는 질의들이 <class> 선언 내부에서 <subclass> 또는 <joined-subclass>로 매핑된 서브 클래스들의 인스턴스들 만을 반환하게 될 것임을 의미한다. 대부분의 용도로, 디폴트인 polymorphism="implicit"가 적절하다.두 개의 다른 클래스들이 동일한 테이블로 매핑될 때 Explicit 다형성이 유용하다(이것은 테이블 컬럼들의 서브셋을 포함하는 "경량급" 클래스를 허용한다). 

persister 속성은 클래스에 사용되는 영속화 방도를 당신이 커스트마이징 할 수 있도록 해준다. 예를 들어 당신은 org.hibernate.persister.EntityPersister에 대한 당신 자신의 서브클래스를 지정할 수도 있거나 당신은 심지어 예를 들어  플랫 파일들이나 LDAP로의 직렬화,내장 프로시저 호출들을 통해 영속화를 구현하는 인터페이스 org.hibernate.persister.ClassPersister에 대한 완전히 새로운 구현을 제공할 수도 있다. (Hashtable에 대한 "영속"에 관한)  간단한 예제는 org.hibernate.test.CustomPersister를 보라. 

dynamic-update 설정과 dynamic-insert 설정은 서브클래스들에 의해 상속되지 않고 따라서 또한 <subclass> 또는 <joined-subclass>요소들 상에 지정될 수도 있음을 노트하라. 이들 설정들은 몇몇 경우들에서 퍼포먼스를 증가시키지만 다른 경우들에서는 퍼포먼스를 실제로 감소시킬 수도 있다. 적절하게 사용하라.

Use of select-before-update 사용은 대개 퍼포먼스를 감소시킬 것이다. 당신이 detached 인스턴스들의 그래프를 Session에 다시첨부할 경우에 그것은  데이터베이스 업데이트 트리거가 불필요하게 호출되는 것을 방지하는데 매우 유용하다.

dynamic-update을 사용가능하게 할 경우, 당신은 다음 optimistic 잠금 전략들을 선택하게 될 것이다:

  • version 은 version/timestamp 컬럼들을 체크한다
  • all 은 모든 컬럼들을 체크한다 
  • dirty 은 몇몇 동시성 업데이트들을 허용하여, 변경된 컬럼들을 체크한다 
  • none 은 optimistic 잠금을 사용하지 않는다

우리는 당신이 Hibernate에서 optimistic 잠금을 위해 version/timestamp 컬럼들을 사용할 것을 매우 강력하게 권장한다. 이것은 퍼포먼스에 대해 최적의 방도이고 detached 인스턴스들에 대해 행해진 변경들을 정확하게 핸들링하는 유일한 방도이다(예를 들어 Session.merge()가 사용될 때).

Hibernate 매핑의 경우에 베이스 테이블과 뷰 사이에 차이점이 존재하지 않는다. 왜냐하면 이것이 데이터베이스 레벨에서는 투명하다고 기대되기 때문이다(몇몇 DBMS는 뷰를 고유하게 지원하지 않고 특히 뷰 업데이트를 지원하지 않음을 노트하라). 때때로 당신이 뷰를 사용하고자 원하지만, (예를 들어 리거시 스키마로) 데이터베이스 속에 뷰를 생성시킬 수 없다. 이 경우에, 당신은 불변의 읽기 전용 엔티티를 주어진 SQL subselect 표현식으로 매핑시킬 수  있다:

<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>

auto-flush가 정확하게 발생하도록 하고, 그리고 파생된 엔티티에 대한 질의들이 쓸효성 없는 데이터를 반환하지 않도록 함으로써, 이 엔티티와 동기화 될 테이블을 선언하라. <subselect> 는 속성과 내포된 매핑 요소 양자로서 이용 가능하다.

5.1.4. id

매핑된 클래스들은 데이터베이스 테이블의 프라이머리 키 컬럼을 선언해야 한다. 대부분의 클래스들은 또한 인스턴스의 유일 식별자를 소유하는 자바빈즈-스타일 프로퍼티를 가질 것이다. <id> 요소는 그 프로퍼티로부터 프라이머리 키 컬럼으로의 매핑을 정의한다.

<id
        name="propertyName"                                     (1)
        type="typename"                                         (2)
        column="column_name"                                    (3)
        unsaved-value="null|any|none|undefined|id_value"        (4)
        access="field|property|ClassName">                      (5)

        <generator class="generatorClass"/>
</id>
(1)

name (옵션): 식별자 프로퍼티의 이름.

(2)

type (옵션): Hibernate 타입을 나타내는 이름.

(3)

column (옵션 - 디폴트는 프로퍼티 이름): 프라이머리 키 컬럼의 이름.

(4)

unsaved-value (옵션 - 디폴트는 "sensible" 값): 이전 세션에서 저장되었거나 로드되었던 detached(분리된) 인스턴스들로부터 그것을 구분지우도록, 인스턴스가 새로이 초기화되어 있음(unsaved)을 나타내는 식별자 프로퍼티 값.

(5)

access (옵션 - 디폴트는 property): Hibernate가 프로퍼티 값에 액세스하는데 사용할 방도.

name 속성이 누락되면, 클래스는 식별자 프로퍼티를 갖지 않는다고 가정된다. 

unsaved-value 속성은 중요하다! 만일 당신의 클래스의 식별자 프로퍼티가 디폴트로 통상의 Java 디폴트 값(null 또는 0)에 대해 디폴트가 아닐 경우, 당신은 실제 디폴트를 지정해야 할 것이다.

composite 키들로서 리거시 데이터에 액세스하는 것을 허용해주는 대체적인 <composite-id> 선언이 존재한다. 우리는 그 밖의 어떤것에 대한 그것의 사용에 대해 강력하게 반대한다.

5.1.4.1. generator

선택적인 <generator> 자식 요소는 영속 클래스의 인스턴스들에 대한 유일 식별자들을 생성시키는데 사용되는 자바 클래스를 명명한다. 만일 임의의 파라미터들이 생성자 인스턴스를 구성하거나 초기화 시키는데 필요할 경우, 그것들은 <param> 요소 를 사용하여 전달된다. 

<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>

모든 생성자들은 org.hibernate.id.IdentifierGenerator 인터페이스를 구현한다. 이것은 매우 간단한 인터페이스이다; 몇몇 어플리케이션들은 그것들 자신의 특화된 구현들을 제공하도록 선택할 수 있다. 하지만 Hibernate는 미리 빈드된 구현들의 영역들을 제공한다. 빌드-인 생성자(generator)들에 대한 단축 이름들이 존재한다:

increment

동일한 테이블 속으로 데이터를 입력하는 다른 프로세스가 없을 때에만 유일한 long, short 또는 int 타입의 식별자들을 생성시킨다. 클러스터 내에서는 사용하지 말라.

identity

DB2, MySQL, MS SQL Server, Sybase, HypersonicSQL.에서 식별 컬럼들을 지원한다. 반환되는 식별자는 long, short 또는 int타입이다.  

sequence

DB2, PostgreSQL, Oracle, SAP DB, McKoi 에서 시퀀스를 사용하거나 Interbase에서 생성자(generator)를 사용한다. 반환되는 식별자는 long, short 또는 int 타입이다.

hilo

 테이블과 컬럼(디폴트로 각각 hibernate_unique_keynext_hi)이 hi 값들의 소스로서 주어지면, long, short 또는 int 타입의 식별자들을 효과적으로 생성시키는데 hi/lo 알고리즘을 사용한다.  hi/lo 알고리즘은 특정 데이터베이스에 대해서만 유일한 식별자들을 생성시킨다.

seqhilo

명명된 데이터베이스 시퀀스가 주어지면, long, short 또는 int 타입의 식별자들을 효과적으로 생성시키는데 hi/lo 알고리즘을 사용한다. 

uuid

네트웍 내에서 유일한(IP 주소가 사용된다) string 타입의 식별자들을 생성시키기 위해 128 비트 UUID 알고리즘을 사용한다. UUID는 길이가 32인 16진수들의 문자열로서 인코딩 된다.

guid

MS SQL Server와 MySQL 상에서 데이터베이스 생성 GUID 문자열을 사용한다.

native

기본 데이터베이스의 가용성들에 의존하여 identity, sequence 또는 hilo를 찾아낸다.

assigned

어플리케이션으로 하여금 save()가 호출되기 전에 식별자를 객체에 할당하도록 한다. <generator> 요소가 지정되지 않을 경우 이것이 디폴트 방도이다.

select
어떤 유일 키에 의해 행을 select하고 프라이머리 키 값을 검색함으로써 데이터베이스 트리거에 의해 할당된 프라이머리 키를 검색한다.
foreign

또 다른 연관된 객체의 식별자를 사용한다. 대개 <one-to-one>  프라이머리 키 연관관계와 함께 사용된다. 

5.1.4.2. Hi/Lo 알고리즘

hiloseqhilo 생성자들은 식별자 생성에 대한 마음에 드는 접근법인, hi/lo 알고리즘에 대한 두 개의 대체 구현들은 제공한다. 첫 번째 구현은 다음에 이용 가능한 "hi" 값을 수용하기 위한 "특별한" 데이터베이스 테이블을 필요로 한다. 두 번째는 (지원되는) Oracle 스타일의 시퀀스를 사용한다.

<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>
<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>

불행히도 당신은 Hibernate에 당신 자신의 Connection을 제공할 때  hilo 를 사용할 수 없다. Hibernate가 JTA의 도움을 받는 커넥션들을 얻기 위해 어플리케이션 서버 데이터소스를 사용할 때 당신은 hibernate.transaction.manager_lookup_class를 적절하게 구성해야 한다.

5.1.4.3. UUID 알고리즘

UUID 는 다음을 포함한다: IP 주소, JVM의 시작 시간(정확히 1/4 초), 시스템 시간과 (JVM 내에서 유일한) counter 값. Java 코드로부터 MAC 주소 또는 메모리 주소를 얻는 것은 불가능하여서, 이것은 우리가 JNI를 사용하지 않고서 행할 수 있는 최상의 것이다.

5.1.4.4.  식별 컬럼들과 시퀀스들

식별 컬럼들을 지원하는 데이터베이스들(DB2, MySQL, Sybase, MS SQL)의 경우, 당신은 identity 키 생성을 사용할 수 있다. 시퀀스들을 지원하는 데이터베이스들(DB2, Oracle, PostgreSQL, Interbase, McKoi, SAP DB)의 경우, 당신은 sequence 스타일 키 생성을 사용할 수도 있다.  이들 방도들 모두 새로운 객체를 insert 하기 위해 두 개의 SQL 질의들을 필요로 한다.

<id name="id" type="long" column="person_id">
        <generator class="sequence">
                <param name="sequence">person_id_sequence</param>
        </generator>
</id>
<id name="id" type="long" column="person_id" unsaved-value="0">
        <generator class="identity"/>
</id>

크로스 플랫폼 개발을 위해서, native 방도가 기준 데이터베이스들의 가용성들에 따라  identity, sequence, hilo 방도 중에서 선택될 것이다.

5.1.4.5.  할당된 식별자들

(Hibernate로 하여금 식별자들을 생성시키도록 하는 것과는 반대로) 당신이 어플리케이션으로 하여금 식별자들을 할당하도록 원할 경우,  당신은 assigned 생성자를 사용할 수 있다. 이 특별한 생성자는 객체의 identifier 프로퍼티에 이미 할당된 식별자 값을 사용할 것이다.  이 생성자(generator)는 프라이머리 키가 대용(surrogate ) 키 대신에 natural 키일 때 사용된다. 당신이 <generator> 요소를 지정하지 않을 경우에 이것이 디폴트 특징이다.

assigned 생성자(generator)를 선택하는 것은 , version 또는 timestamp 프로퍼티가 존재하지 않는한 또는 당신이 Interceptor.isUnsaved ()를 정의하지 않는한, 하나의 인스턴스가 transient 또는 detached인지를 결정하기 위해 Hibernae로 하여금 데이터베이스에 접촉하도록 강제하는, unsaved-value="undefined"를 Hibernate에게 사용하도록 한다.

5.1.4.6. 트리거들에 의해 할당된 프라이머리 키들

리거시 스키마에 대해서만(Hibernate는 트리거들을 가진 DDL을 생성시키지 않는다).

<id name="id" type="long" column="person_id">
        <generator class="select">
                <param name="key">socialSecurityNumber</param>
        </generator>
</id>

위의 예제에서, natural 키로서 클래스에 의해 socialSecurityNumber로 명명된 유일 값을 가진 프로퍼티가 존재하고, 트리거에 의해 그 값이 생성되는 person_id로 명명된 대용키가 존재한다.

5.1.5. composite-id

<composite-id
        name="propertyName"
        class="ClassName"
        unsaved-value="undefined|any|none"
        access="field|property|ClassName">

        <key-property name="propertyName" type="typename" column="column_name"/>
        <key-many-to-one name="propertyName class="ClassName" column="column_name"/>
        ......
</composite-id>

composite 키를 가진 테이블의 경우, 당신은 클래스의 여러 프로퍼티들을 식별자 프로퍼티들로서 매핑할 수 있다. <composite-id> 요소는 자식 요소들로서 <key-property> 프로퍼티 매핑과 <key-many-to-one> 매핑들을 허용한다.

<composite-id>
        <key-property name="medicareNumber"/>
        <key-property name="dependent"/>
</composite-id>

당신의 영속 클래스는 composite 식별자 동등성을 구현하기 위해서 equals() 와  hashCode()를 오버라이드 시켜야 한다. 그것은 또한 Serializable을 구현해야 한다.

불행히도, composite 식별자들에 대한 이 접근법은 영속 객체가 그것 자신의 식별자라는 점을 의미한다. 객체 자신 외의 다른 "핸들"이 존재하지 않는다. 당신은 당신이 composite key에 연관된 영속 상태를 load() 할 수 있기 이전에 영속 클래스 그 자체의 인스턴스를 초기화 하고 그것의 식별자 프로퍼티들을 군집화 시켜야 한다. 우리는 8.4 절, “composite 식별자들로서 컴포넌트들”에서 composite 식별자가 한 개의 별도의 클래스로서 구현되는 훨씬 더 편리한 접근법을 설명할 것이다. 아래에 설명된 속성들은 이 대체 접근법에만 적용된다: 

  • name (옵션): composite 식별자를 갖고 있는 컴포넌트 타입의 프로퍼티(다음 절을 보라).
  • class (옵션 - 디폴트는 reflection에 의해 결정된 프로퍼티 타입): composite 식별자로서 사용된 컴포넌트 클래스(다음 절을 보라).
  • unsaved-value (옵션 - 디폴트는 undefined): any로 설정될 경우에 transient 인스턴스들이 새로이 초기화 된 것으로 간주되고 또는 none으로 설정된 경우, transient 인스턴스들이 detached 된 것으로 간주될 것임을 나타낸다. 모든 클래스에서 디폴트 값으로 남겨두는 것이 최상이다.

5.1.6. discriminator

<discriminator> 요소는 table-per-class-hierarchy(테이블 당 클래스 계층구조) 매핑 방도를 사용하는 다형성 영속화에 필요하고 테이블의 discriminator(판별자) 컬럼을 선언한다.  discriminator 컬럼은 특정 행에 대해 초기화 시킬서브 클래스가 무엇인지를 영속 계층에 알려주는 표시자 값들을 포함한다. 타입들의 제한적인 집합이 사용될 수 있다:  string, character, integer, byte, short, boolean, yes_no, true_false.

<discriminator
        column="discriminator_column"                      (1)
        type="discriminator_type"                          (2)
        force="true|false"                                 (3)
        insert="true|false"                                (4)
        formula="arbitrary sql expression"                 (5)
/>
(1)

column (옵션 - 디폴트는 class) discriminator 컬럼명

(2)

type (옵션 - 디폴트는 string) Hibernate 타입을 나타내는 이름

(3)

force (옵션 - 디폴트는 false) 이것은 Hibernate로 하여금 루트 클래스의 모든 인스턴스들을 검색할 때조차도 허용된 discriminator 값들을 지정하도록 "강제한다".

(4)

insert (옵션 - 디폴트는 true) 당신의 discriminator 컬럼이 또한 매핑된 composite 식별자의 부분일 경우에 이것을 false 로 설정하라. (Hibernate에게  SQL INSERT들 속에 그 컬럼을 포함하지 않도록 통보한다.)

(5)

formula (옵션) 타입이 평가 되어야 할 때 실행되는 임의의 SQL 표현식. 컨텐츠 기반의 판별을 허용해준다.

discriminator 컬럼의 실제 값들은 <class> 요소와 <subclass> 요소의 discriminator-value 속성에 의해 지정된다.

force 속성은 테이블이 영속 클래스로 매핑되지 않는 "특별한" discriminator 값들을 가진 행들을 포함할 경우에(만) 유용하다. 이것은 대개 그 경우가 아닐 것이다. 

formula 속성을 사용하여 당신은 행의 타입을 판단하는데 사용될 임의의 SQL 표현식을 선언할 수 있다:

<discriminator
    formula="case when CLASS_TYPE in ('a', 'b', 'c') then 0 else 1 end"
    type="integer"/>

5.1.7. version (옵션)

<version> 요소는 옵션이고 테이블이 버전화된 데이터를 포함한다는 것을 나타낸다. 이것은 당신이 긴 트랜잭션(long transaction)들을 사용할 계획이라면 특히 유용하다(아래를 보라).

<version
        column="version_column"                            (1)
        name="propertyName"                                (2)
        type="typename"                                    (3)
        access="field|property|ClassName"                  (4)
        unsaved-value="null|negative|undefined"            (5)
/>
(1)

column (옵션 - 디폴트는 프로퍼티 명): 버전 번호를 가진 컬럼의 이름.

(2)

name: 영속 클래스의 프로퍼티 명.

(3)

type (옵션 - 디폴트는 integer): 버전 번호의 타입.

(4)

access (옵션 - 디폴트는 property): Hibernate가 프로퍼티 값에 액세스하는데 사용할 방도.

(5)

unsaved-value (옵션 - 디폴트는 undefined): 이전 세션에서 저장되었거나 로드되었던 detached 인스턴스로부터 구별지어서, 인스턴스가 새로이 초기화됨(unsaved)을 나타내는 version 프로퍼티 값. (undefined는 식별자 프로퍼티 값이 사용될 것임을 지정한다. )

버전 번호들은 long, integer, short, timestamp 또는 calendar 타입일 수 있다.

version 또는 timestamp 프로퍼티는 detached 인스턴스에 대해 결코 null일 수가 없어서, Hibernate는 다른 unsaved-value 방도들이 지정되는 것에 상관없이, null version이나 timestamp를 가진 임의의 인스턴스를 transient로서 검출할 것이다. null 허용되는 version 이나 property를 선언하는 것은 Hibernate에서 transitive reattachment에 대한 임의의 문제들을 피하는 쉬운 방법이고, assigned 식별자들이나 composite key들을 사용하는 사람들에게 특히 유용하다!

5.1.8. timestamp (옵션)

옵션 <timestamp> 요소는 테이블이 타임스탬프화 된 데이터를 포함함을 나타낸다. 이것은 버전화에 대한 대체물로서 고안되었다. Timestamp은 고유하게 optimistic 잠금에 대한 다소 안전한 구현이다. 하지만 때때로 어플리케이션은 다른 방법들로 timestamp들을 사용할 수도 있다.  

<timestamp
        column="timestamp_column"           (1)
        name="propertyName"                 (2)
        access="field|property|ClassName"   (3)
        unsaved-value="null|undefined"      (4)
/>
(1)

column (옵션 - 디폴트는 프로퍼티 명): 타임스탬프를 포함하는 컬럼 명.

(2)

name: 영속 클래스의 자바 Date 또는 Timestamp 타입을 가진 자바빈즈 스타일의 프로퍼티 이름.

(3)

access (옵션 - 디폴트는 property): Hibernate가 프로퍼티 값에 접근하는데 사용할 방도.

(4)

unsaved-value (옵션 - 디폴트는 null): 이전 세션에서 저장되었거나 로드되었던 detached 인스턴스로부터 인스턴스를 구별지우는, 인스턴스가 새로이 초기화됨(unsaved)을 나타내는 version 프로퍼티 값. (undefined 는 식별자 프로퍼티 값이 사용될 것임을 지정한다. )

<timestamp><version type="timestamp">과 같음을 노트하라.

5.1.9.  프로퍼티

<property> 요소는 클래스의 자바빈즈 스타일의 영속 프로퍼티를 선언한다. 

<property
        name="propertyName"                 (1)
        column="column_name"                (2)
        type="typename"                     (3)
        update="true|false"                 (4)
        insert="true|false"                 (4)
        formula="arbitrary SQL expression"  (5)
        access="field|property|ClassName"   (6)
        lazy="true|false"                   (7)
        unique="true|false"                 (8)
        not-null="true|false"               (9)
        optimistic-lock="true|false"        (10)
/>
(1)

name: 첫 소문자로 시작하는 프로퍼티 이름.

(2)

column (옵션 - 디폴트는 프로퍼티 이름): 매핑된 데이터베이스 테이블 컬럼의 이름. 이것은 또한 내부에 포함되는 <column>요소 (들)에 의해 지정될 수도 있다.

(3)

type (옵션): Hibernate 타입을 나타내는 이름.

(4)

update, insert (옵션 - 디폴트는 true) : 매핑된 컬럼들이 UPDATE 와/또는 INSERT 문장들속에 포함될 것임을 지정한다. 둘다 false 로 설정하는 것은  그 값이 동일한 컬럼(들)로 매핑되는 어떤 다른 프로퍼티로부터 또는 트리거에 의해 또는 다른 어플리케이션으로부터 초기화 되는 순수하게 "파생된(derived)" 프로퍼티를 허용해준다.

(5)

formula (옵션): 계산되는 프로퍼티에 대해 값을 정의하는 SQL 표현식. 계산되는 프로퍼티들은 그것들 자신에 대한 컬럼 매핑을 갖지 않는다. 

(6)

access (옵션 - 디폴트는 property): Hibernate가 프로퍼티 값에 접근하는데 사용할 방도.

(7)

lazy (옵션 - 디폴트는 false): 인스턴스 변수가 처음으로 액세스 될 때 이 프로퍼티가 lazily하게 페치될 것임을 지정한다(빌드-시 바이트코드 수단을 필요로 한다).

(8)

unique (옵션): 컬럼들에 대한 유일 컨스트레인트의 DDL 생성을 가능하게 만든다. 또한 이것이 property-ref의 타켓이 되는 것을 허용해준다.

(9)

not-null (옵션): 컬럼들에 대해 null 가능 컨스트레인트의 DDL 생성을 가능하게 만든다.

(10)

optimistic-lock (옵션 - 디폴트는 true): 이 프로퍼티에 대한 업데이트들이 optimistic 잠금을 획득하는 것을 필요로 하거나 필요로 하지 않음을 지정한다. 

typename 은 다음일 수 있다:

  1. Hibernate 기본 타입의 이름 (예를 들어. integer, string, character, date, timestamp, float, binary, serializable, object, blob).
  2. 디폴트 기본 타입을 가진 Java 클래스의 이름(예를 들어. int, float, char, java.lang.String, java.util.Date, java.lang.Integer, java.sql.Clob).
  3. serializable Java 클래스의 이름.
  4. 맞춤 타입의 클래스 이름(예를 들어. com.illflow.type.MyCustomType).

만일 당신이 타입을 지정하지 않을 경우, Hibernate는 정확한 Hibernate 타입을 추정하기 위해 명명된 프로퍼티에 대해 reflection을 사용할 것이다. Hibernate는 그 순서에서 2,3,4 규칙들을 사용하여  프로퍼티 getter의 반환 클래스의 이름을 해석하려고 시도할 것이다. 하지만 이것은 항상 충분하지는 않다. 어떤 경우들에서, 당신은 여전히 type 속성을 필요로 할 것이다. (예를 들어, Hibernate.DATEHibernate.TIMESTAMP 사이를 구별하기 위해, 또는 맞춤 타입을 지정하기 위해.)

access 속성은 당신으로 하여금 Hibernate가 런타임 시에 프로퍼티에 액세스하는 방법을 제어하도록 해준다. 디폴트로 Hibernate는 프로퍼티 get/set 쌍을 호출할 것이다. 만일 당신이 access="field"를 지정할 경우, Hibernate는 get/set 쌍을 피하고 reflection을 사용하여 직접 필드에 액세스 할 것이다. 당신은 org.hibernate.property.PropertyAccessor 인터페이스를 구현하는 클래스를 명명함으로써 프로퍼티 접근을 위한 당신 자신의 방도를 지정할 수도 있다.

특별히 강력한 특징은 파생된 플로퍼티들이다. 이들 프로퍼티들은 정의상 읽기 전용이고, 그 프로퍼티 값은 로드 시에 계산된다. 당신은 그 계산을 SQL 표현식으로 선언하고, 이것은 인스턴스를 로드시키는 SQL 질의 내의 SELECT  절 서브질의로 번역된다:

<property name="totalPrice"
    formula="( SELECT SUM (li.quantity*p.price) FROM LineItem li, Product p
                WHERE li.productId = p.productId
                AND li.customerId = customerId
                AND li.orderNumber = orderNumber )"/>

당신은 특정 컬럼(주어진 예제에서는 customerId)에 대해 alias를 선언하지 않음으로써 엔티티들 자신의 테이블을 참조할 수 있음을 노트하라. 또한 당신은 만일 당신이 그 속성을 사용하고 싶지 않을 경우에 내포된 <formula> 매핑 요소를 사용할 수 있음을 노트하라.

5.1.10. many-to-one

또 다른 영속 클래스에 대한 정규 연관관계는 many-to-one 요소를 사용하여 선언된다. 관계형 모형은 many-to-one 연관관계이다.: 하나의 테이블 내에 있는 foreign 키는 대상 테이블의 프라이머리 키 컬럼(들)을 참조하고 있다.

<many-to-one
        name="propertyName"                                (1)
        column="column_name"                               (2)
        class="ClassName"                                  (3)
        cascade="cascade_style"                            (4)
        fetch="join|select"                                (5)
        update="true|false"                                (6)
        insert="true|false"                                (6)
        property-ref="propertyNameFromAssociatedClass"     (7)
        access="field|property|ClassName"                  (8)
        unique="true|false"                                (9)
        not-null="true|false"                              (10)
        optimistic-lock="true|false"                       (11)
        lazy="true|false"                                  (12)
        not-found="ignore|exception"                       (13)
        entity-name="EntityName"
/>
(1)

name: 프로퍼티의 이름

(2)

column (옵션): foreign key 컬럼의 이름. 이것은 또한 내포된 <column> 요소(들)에 의해  지정된다.

(3)

class (옵션 - 디폴트는 reflection에 의해 결정된 프로퍼티 타입): 연관된 클래스의 이름.

(4)

cascade (옵션): 어느 오퍼레이션들이 부모 객체로부터 연관된 객체로 케스케이드 될 것인지를 지정한다.

(5)

fetch (옵션- 디폴트는 select): outer-join 페칭 또는 sequential select 페칭 사이에서 선택하라.

(6)

update, insert (옵션 - 디폴트는 true) 매핑된 컬럼들이 SQL UPDATE와/또는 INSERT 문장들 속에 포함될 것인지를 지정한다. 둘다 false로 설정하는 것은  그 값이 동일한 컬럼(들)로 매핑시키는 어떤 다른 컬럼들로부터 초기화 되거나 트리거나 다른 어플리케이션에 의해 초기화되는 단순한 "파생된" 연관관계 값을 허용한다.

(7)

property-ref: (옵션) 이 foreign key에 조인되는 연관된 클래스의 프로퍼티 이름. 지정되지 않을 경우, 연관 클래스의 프라이머리 키가 사용된다.

(8)

access (옵션 - 디폴트는 property): Hibernate가 프로퍼티 값에 접근하는데 사용할 방도.

(9)

unique (옵션): foreign-key 컬럼을 위한 유일 컨스트레인트의 DDL 생성을 가능하도록 해준다. 또한 이것이 property-ref의 대상이 되는 것을 허용해준다. 이것은 연관 다중성(association multiplicity)을 효율적으로 일 대 일로 만든다.

(10)

not-null (옵션): foreign key 컬럼들을 위한 null 가능한 컨스트레인트의 DDL 생성을 가능하도록 해준다.

(11)

optimistic-lock (옵션 - 디폴트는 true): 이 프로퍼티에 대한 업데이트들이 optimistic lock의 획득을 필요로 하는지 아닌지 여부를 지정한다. 달리 말해 이 프로퍼티가 dirty일 때 version 증가가 발생해야 할 경우인지를 결정한다.

(12) lazy (옵션 - 디폴트는 false): 인스턴스 변수가 처음 액세스될 때 이 프로퍼티가 lazily하게 페치되어야 하는지를 지정한다(빌드 시 바이트코드 방편을 필요로 한다). 이것은 -클래스 매핑 또는 콜렉션 매핑 상의 lazy 속성 처럼- Hibernate의 proxy 행위에 영향을 주지 않지만, deferred loading(연기된 로딩)을 위해 인터셉션을 사용한다는 점을 노트하라.
(13) not-found (옵션 - 디폴트는 exception): 누락된 행들을 참조하는 foreign key들이 어떻게 처리될 것인지를 지정한다: ignore는 한 개의 누락된 행을 한 개의 null 연관으로서 취급할 것이다. 

cascade 속성의 값을 none이 아닌 어떤 의미있는 다른 값으로 설정하는 것은 어떤 오퍼레이션들을 연관된 객체에게 보급할 것이다. 의미 있는 값들은 Hibernate의 기본 오퍼레이션들의 이름들 create, merge, delete, save-update, evict, replicate, lock, refresh 뿐만 아니라 특별한 값들 delete-orphan, all 그리고 오퍼레이션 이름들의 쉼표 분리된 조합들이다.예를 들면 cascade="create,merge,evict" 또는 cascade="all,delete-orphan". 전체 설명은 10.11 절, “Transitive 영속화”를 보라.

일반적인 many-to-one 선언은 다음과 같이 간단하게 보인다:

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

property-ref 속성은 오직 foreign key가 프라이머리 키가 아닌 연관된 테이블의 유일 키를 참조하는 리거시 데이터를 매핑하는데만 사용된다. 이것은 꼴사나운 관계형 모형이다. 예를 들어, Product 클래스가 프라이머리 키를 아닌, 유일한 시리얼 번호를 갖는다고 가정하자.(unique 속성은 SchemaExport 도구로 Hibernate의 DDL 생성을 제어한다.)

<property name="serialNumber" unique="true" type="string" column="SERIAL_NUMBER"/>

그런 다음 OrderItem 에 대한 매핑은 다음을 사용할 것이다:

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

하지만 이것은 확실히 권장되지 않는다.

만일 참조된 유일 키가 연관된 엔티티의 여러 프로퍼티들을 포함할 경우, 당신은 명명된 <properties> 요소 내부에 참조된 프로퍼티들을 매핑할 것이다.

5.1.11. one-to-one

또 다른 영속 클래스에 대한 one-to-one 연관관계는 one-to-one 요소를 사용하여 선언된다.

<one-to-one
        name="propertyName"                                (1)
        class="ClassName"                                  (2)
        cascade="cascade_style"                            (3)
        constrained="true|false"                           (4)
        fetch="join|select"                                (5)
        property-ref="propertyNameFromAssociatedClass"     (6)
        access="field|property|ClassName"                  (7)
        formula="any SQL expression"                       (8)
        entity-name="EntityName"
/>
(1)

name: 프로퍼티의 이름.

(2)

class (옵션 - 디폴트는 reflection에 의해 결정된 프로퍼티 타입): 연관된 클래스의 이름.

(3)

cascade (옵션) 어느 오퍼레이션들이 부모 객체로부터 연관된 객체로 케스케이드 될 것인지를 지정한다.

(4)

constrained (옵션) 매핑된 테이블의 프라이머리 키에 대한 foreign 키 컨스트레인트가 연관된 클래스의 테이블을 참조하는지 여부를 지정한다. 이 옵션은  save()와 delete()가 케스케이드 되는 순서에 영향을 주고, 그 연관이 프락시 될 것인지 여부를 결정한다(또한 스키마 내보내기 도구에 의해 사용된다).

(5)

fetch (옵션 - 디폴트는 select): outer-join 페칭 또는 순차적인 select 페칭 중에서 선택하라.

(6)

property-ref: (옵션) 이 클래스의 프라이머리 키에 연결된 연관 클래스의 프로퍼티의 이름. 만일 지정되지 않을 경우, 연관 클래스의 프라이머리 키가 사용된다.

(7)

access (옵션 - 디폴트는 property): Hibernate가 프로퍼티 값에 접근 하는데 사용할 방도.

(8) formula (옵션): 거의 모든 one to one 연관관계들은 소유하는 엔티티의 프라이머리 키로 매핑된다. 이 것이 그 경우가 아닌 드문 경우들에서, 당신은 SQL formula 사용에 결합시킬 몇몇 다른 컬럼, 컬럼들, 또는 표현식을 지정할 수 있다.(예제는 org.hibernate.test.onetooneformula를 보라.)

one-to-one 연관관계에는 두 가지 변종이 존재한다:

  • 프라이머리 키 연관관계들
  • 유일 foreign 키 연관관계들

프라이머리 키 연관들은 특별한 테이블 컬럼을 필요로 하지 않는다; 만일 두 개의 행들이 그 연관에 의해  관계지워지면, 두 개의 테이블 행들은 동일한 프라이머리 키 값을 공유한다. 따라서 만일 두 개의 객체들이 프라이머리 키 연관에 의해 관계지워지도록 당신이 원할 경우, 당신은 그것들에 동일한 식별자 값이 할당되도록 해야 한다!

프라이머리 키 연관에 대해, 다음 매핑들을 각각 EmployeePerson에 추가하라.

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

이제 우리는 PERSON 과 EMPLOYEE 테이블들에서 관계지워진 행들의 프라이머리 키들이 동일함을 확실히 해야 한다! 우리는 foreign로 명명되는 특별한 Hibernate 식별자 생성 방도를 사용한다: 

<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>

그때 Person의 새로이 저장된 인스턴스는 그 Personemployee 프로퍼티에 대해 참조된 Employee 인스턴스와 동일한 프라이머리 키를 할당받는다.

달리, Employee로부터 Person으로의 유일 컨스트레인트를 가진 foreign key는 다음과 같이 표현될 수 있다:

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

그리고 이 연관은 다음을 Person 매핑에 추가함으로써 양방향이 될 수 있다:

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

5.1.12. component, dynamic-component

<component> 요소는 자식 객체의 프로퍼티들을 부모 클래스에 대한 테이블의 컬럼들로 매핑시킨다. 컴포넌트들은 그것들 자신의 프로퍼티들, 컴포넌트들, 또는 콜렉션들을 선언한다. 이래 "컴포넌트들"을 보라.

<component 
        name="propertyName"                 (1)
        class="className"                   (2)
        insert="true|false"                 (3)
        update="true|false"                 (4)
        access="field|property|ClassName"   (5)
        lazy="true|false"                   (6)
        optimistic-lock="true|false"        (7)
        unique="true|false"                 (8)
>
        
        <property ...../>
        <many-to-one .... />
        ........
</component>
(1)

name: 프로퍼티의 이름

(2)

class (옵션 - 디폴트는  reflection에 의해 결정된 프로퍼티 타입): 컴포넌트(자식) 클래스의 이름.

(3)

insert: 매핑된 컬럼들이 SQL INSERT들 속에 나타나야 하는가?

(4)

update: 매핑된 컬럼들이 SQL UPDATE들 속에 나타나야 하는가?

(5)

access (옵션 - 디폴트는 property): Hibernate가 프로퍼티 값에 액세스하는데 사용할 방도.

(6)

lazy (옵션 - 디폴트는 to false): 인스턴스 변수가 처음으로 액세스될 때 이 컴포넌트가 lazily(느리게) 페치되어야 하는지 여부를 지정한다(빌드 시 바이트코드 수단을 필요로 한다).

(7) optimistic-lock (옵션 - 디폴트는 true): 이 컴포넌트에 대한 업데이트들이 optimistic 잠금을 획득하는 것을 필요로 하는지 여부를 지정한다. 달리 말해 이 프로퍼티가 dirty 일 때 버전 증가가 발생할 것인지 여부를 결정한다.
(8) unique (옵션 - 디폴트는 false): 유일 컨스트레인트가 컴포넌트의 모든 매핑된 컬럼들에 대해 존재하는지 여부를 지정한다. 

자식 <property> 태그들은 자식 클래스의 프로퍼티들을 테이블 컬럼들로 매핑시킨다.

<component> 요소는 컴포넌트 클래스의 프로퍼티를 포함하는 엔티티에 대한 참조로서 매핑시키는 <parent> 서브요소를 허용한다. 

<dynamic-component> 요소는 컴포넌트로서 매핑될 Map을 허용한다. 여기서 프로퍼티 이름들은 map의 키들을 참조한다.  8.5절, “동적인 컴포넌트들”을 보라.

5.1.13. properties

<properties> 요소는 클래스의 프로퍼티들의 명명된, 논리적 그룹핑에 대한 정의를 허용한다. 그 구조에 대한 가장 중요한 사용은 그것이 프로퍼티들의 조합이 property-ref의 대상이 되는 것을 허용해준다는 점이다. 또한 그것은 다중 컬럼 유일 컨스트레인느를 정의하는 편리한 방법이다.

<properties 
        name="logicalName"                  (1)
        insert="true|false"                 (2)
        update="true|false"                 (3)
        optimistic-lock="true|false"        (4)
        unique="true|false"                 (5)
>
        
        <property ...../>
        <many-to-one .... />
        ........
</properties>
(1) name: 그룹핑의 논리적 이름 - 실제 프로퍼티 이름이 아니다.
(2) insert: 매핑된 컬럼들이 SQL INSERT들 내에 나타날 것인가?
(3) update: 매핑된 컬럼들이 SQL UPDATE들 내에 나타날 것인가?
(4) optimistic-lock (옵션 - 디폴트는 true): 이들 프로퍼티들에 대한 업데이트들이 optimistic 잠금의 획득을 필요로 하는지 여부를 지정한다. 달리 말해 이 프로퍼티가 dirty 일 때 버전 증가가 발생할 것인지 여부를 결정한다.
(5) unique (옵션 - 디폴트는 false): 유일 컨스트레인트가 컴포넌트의 모든 매핑된 컬럼들에 대해 존재하는지 여부를 지정한다.

예를 들어, 만일 우리가 다음 <properties> 매핑을 가질 경우:

<class name="Person">
    <id name="personNumber"/>
    ...
    <properties name="name" 
            unique="true" update="false">
        <property name="firstName"/>
        <property name="initial"/>
        <property name="lastName"/>
    </properties>
</class>

그 때 우리는 프라이머리 키가 아닌, Person  테이블의 이 유일 키를 참조하는 어떤 리거시 데이터 연관을 가질 수 있다:

<many-to-one name="person" 
         class="Person" property-ref="name">
    <column name="firstName"/>
    <column name="initial"/>
    <column name="lastName"/>
</many-to-one>

우리는 리거시 데이터를 매핑시키는 컨텍스트 바깥에서 이런 종류의 것을 사용하는 것을 권장하지 않는다.

5.1.14. subclass

마지막으로, 다형성 영속성은 루트 영속 클래스에 대한 각각의 서브클래스 선언을 필요로 한다. (권장되는) table-per-class-hierarchy(테이블 당 클래스  계층구조) 매핑 방도의 경우, <subclass> 선언이 사용된다.

<subclass
        name="ClassName"                              (1)
        discriminator-value="discriminator_value"     (2)
        proxy="ProxyInterface"                        (3)
        lazy="true|false"                             (4)
        dynamic-update="true|false"
        dynamic-insert="true|false"
        entity-name="EntityName">

        <property .... />
        .....
</subclass>
(1)

name: 서브클래스의 전체 수식어가 붙은 클래스 이름.

(2)

discriminator-value (옵션 - 디폴트는  클래스 이름): 개개의 서브클래스들을 구분짓는 값.

(3)

proxy (옵션): lazy 초기화 프락시들을 사용하는데 클래스 또는 인터페이스를 지정한다.

(4)

lazy (옵션 - 디폴트는  true): lazy="false" 설정은 lazy 페칭의 사용을 불가능하게 만든다.

각각의 서브클래스는 그것 자신의 영속 프로퍼티들과 서브클래스들을 선언할 것이다. <version> 프로퍼티와 <id> 프로퍼티는 루트 클래스로부터 상속된다고 가정된다. 계층구조 내에 있는 각각의 서브클래스는 유일한 discriminator-value를 정의해야 한다. 계층구조 내에서 각각의 서브클래스는 unique로 정의되어야 한다. 지정되지 않을 경우, 전체 수식어가 붙은 자바 클래스 이름이 사용된다.

별도의 매핑 문서들 내에서 바로 hibernate-mapping 밑에 subclass, union-subclass, joined-subclass 매핑들을 정의하는 것이 가능하다. 이것은 단지 새로운 매핑 파일을 추가함으로써 클래스 계층구조를 확장하는 것을 당신에게 허용해준다. 당신은 서브클래스 매핑에서 이전에 매핑된 슈퍼클래스를 명명하여 extends 속성을 지정해야 한다. 노트 : 이전 버전에서 이 특징은 매핑 문서들의 순서를 중요하게 만들었다. Hibernate3에서는, 매핑 파일들의 순서는 extends 키워드를 사용할 때 관계 없다. 하나의 매핑 파일들 내의 순서는 여전히 서브클래스들 앞에 슈퍼클래스들로서 정의될 필요가 있다.

<hibernate-mapping>
    <subclass name="DomesticCat" extends="Cat" discriminator-value="D">
         <property name="name" type="string"/>
    </subclass>
</hibernate-mapping>

상속 매핑들에 대한 정보는 9장, 상속 매핑을 보라.

5.1.15. joined-subclass

다른 방법으로 각각의 서브클래스는 그것 자신이 테이블로 매핑될 수 있다(table-per-subclass 매핑 방도). 상속된 상태는 슈퍼클래스의 테이블과 조인함으로써 검색된다. 우리는 <joined-subclass> 요소를 사용한다.

<joined-subclass
        name="ClassName"                    (1)
        table="tablename"                   (2)
        proxy="ProxyInterface"              (3)
        lazy="true|false"                   (4)
        dynamic-update="true|false"
        dynamic-insert="true|false"
        schema="schema"
        catalog="catalog"
        extends="SuperclassName"
        persister="ClassName"
        subselect="SQL expression"
        entity-name="EntityName">

        <key .... >

        <property .... />
        .....
</joined-subclass>
(1)

name: 서브클래스의 전체 수식어가 붙은 클래스 명 .

(2)

table: 서브클래스 테이블의 이름.

(3)

proxy (옵션): 프락시들을 lazy 초기화 시키는데 사용할 클래스 또는 인터페이스를 지정한다.

(4)

lazy (옵션, 디폴트는 true): lazy="false" 설정은 lazy 페칭을 사용불가능하게 만든다.

판별자(discriminator) 컬럼은 이 매핑 방도에 필요하지 않다. 하지만 각각의 서브클래스는 <key> 요소를 사용하여 객체 식별자를 보관하는 테이블 컬럼을 선언해야 한다. 이 장의 시작 부분에 있는 매핑은 다음과 같이 다시 작성될 것이다:

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
        "-//Hibernate/Hibernate Mapping DTD//EN"
        "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping package="eg">

        <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>

상속 매핑들에 대한 정보는 9장, 상속 매핑을 보라.

5.1.16. union-subclass

제3의 옵션은 상속 계층구조의 concrete 클래스들 만을 테이블들로 매핑하는 것이다 (table-per-concrete-class 방도). 여기서 각각의 테이블은 상속된 상태를 포함하여 클래스의 모든 영속 상태를 정의한다. Hibernate에서, 그것은 그런 상속 계층구조들을 명시적으로 매핑하는데 필수적이지 않다. 당신은 별도의 <class> 선언을 가진 각각의 클래스를 간단히 매핑시킬 수 있다. 하지만 당신이 다형성 연관관계들(예를 들면 당신의 계층구조의 슈퍼클래스에 대한 연관)을 사용하고자 원할 경우, 당신은 <union-subclass> 매핑을 사용할 필요가 있다.

<union-subclass
        name="ClassName"                    (1)
        table="tablename"                   (2)
        proxy="ProxyInterface"              (3)
        lazy="true|false"                   (4)
        dynamic-update="true|false"
        dynamic-insert="true|false"
        schema="schema"
        catalog="catalog"
        extends="SuperclassName"
        abstract="true|false"
        persister="ClassName"
        subselect="SQL expression"
        entity-name="EntityName">

        <property .... />
        .....
</union-subclass>
(1)

name: 서브클래스의 전체 수식어가 붙은 클래스 명 .

(2)

table: 서브클래스 테이블의 이름.

(3)

proxy (옵션): 프락시들을 lazy 초기화 시키는데 사용할 클래스 또는 인터페이스를 지정한다.

(4)

lazy (옵션, 디폴트는 true): lazy="false" 설정은 lazy 페칭을 사용불가능하게 만든다. 

이 매핑 방도에는 판별자 컬럼이나 키 컬럼이 필요하지 않다.

상속 매핑들에 대한 정보는 9장, 상속 매핑을 보라.

5.1.17. join

<join> 요소를 사용하면, 한 개의 클래스의 프로퍼티들을 몇 개의 테이블들로 매핑시키는 것이 가능하다.

<join
        table="tablename"                        (1)
        schema="owner"                           (2)
        catalog="catalog"                        (3)
        fetch="join|select"                      (4)
        inverse="true|false"                     (5)
        optional="true|false">                   (6)
        
        <key ... />
        
        <property ... />
        ...
</join>
(1)

tabe: 조인된 테이블의 이름.

(2)

schema (옵션): 루트 <hibernate-mapping> 요소에 의해 지정된 스키마 이름을 오버라이드 시킨다.

(3)

catalog (옵션): 루트 <hibernate-mapping> 요소에 의해 지정된 카타록 이름을 오버라이드 시킨다.

(4)

fetch (옵션, 디폴트는 join): join으로 설정될 경우, 디폴트로 Hibernate는 하나의 클래스 또는 그것의 슈퍼 클래스들에 의해 정의된 <join>을 검색하는데 inner join을 사용하고 슈퍼클래스에 의해 정의된 <join>을 검색하는데 outer join을 사용할 것이다. 마일 select 로 설정할 경우, Hibernate는 슈퍼클래스에 대해 정의된 <join>에 대해 sequential select를 사용할 것이고, 그것은 한 행이 서브클래스의 인스턴스를 표현하는 것으로 판명되는 경우에만 명령이 내려질 것이다. inner join들은 여전히 클래스와 그것의 슈퍼클래스들에 의해 정의된 <join>을 검색하는데 사용될 것이다. 

(5)

inverse (옵션, 디폴트는 false): 이용 가능할 경우, Hibernate는 이 조인에 의해 정의된 프로퍼티들을 삽입시키거나 업데이트하려고 시도하지 않을 것이다.

(6)

optional (옵션, 디폴트는 false): 이용 가능할 경우, Hibernate는 이 조인에 의해 정의된 프로퍼티들이 null이 아닐 경우에만 한 행을 삽입시킬 것이고 항상 그 프로퍼티들을 검색하는데 outer join을 사용할 것이다.

예를 들어, (모든 프로퍼티들에 대해 value 타입 의미를 유지하면서) 개인의 주소 정보는 별도의 테이블에 매핑될 수 있다:

<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>
    ...

이 특징은 자주 리거시 데이터 모형들에 대해서만 유용하고, 우리는 클래스들과 잘 정제된 도메인 모형 보다 더 적은 테이블들을 권장한다. 하지만 뒷 부분에 설명되어 있듯이 그것은 하나의 계층구조 내에 있는 상속 매핑 방도들 사이를 전환하는 것에 유용하다.

5.1.18. key

우리는 지금까지 몇 번 나타났던 <key> 요소를 보았다. 그것은 부모 매핑 요소가 새로운 테이블에 대한 조인을 정의하는 어느 곳에서나 나타나고, 그것은 조인된 테이블의 foreign 키를 정의하고, 그것은 원래의 테이블의 프라이머리 키를 참조한다.

<key
        column="columnname"                      (1)
        on-delete="noaction|cascade"             (2)
        property-ref="propertyName"              (3)
        not-null="true|false"                    (4)
        update="true|false"                      (5)
        unique="true|false"                      (6)
/>
(1)

column (옵션): foreign key 컬럼의 이름. 이것은 또한 내포된 <column> 요소(들)에 의해 지정될 수 있다.

(2)

on-delete (옵션, 디폴트는 noaction): foreign key 컨스트레인트가 데이터베이스 레벨의 cascade delete를 사용가능하도록 할 것인지 여부를 지정한다.

(3)

property-ref (옵션): foreign key가 원래의 테이블의 프라이머리 키가 아닌 컬럼들을 참조함을 지정한다. (리거시 데이터에 제공됨.)

(4) not-null (옵션): foreign 키 컬럼들이 not null 임를 지정한다(이것은 foreign 키가 또한 프라이머리 키의 부분일 때마다 함축된다).
(5) update (옵션): foreign 키가 결코 업데이트되지 않아야 함을 지정한다(이것은 foreign 키가 또한 프라이머리 키의 부분일 때마다 함축된다).
(6) unique (옵션): foreign 키가 유일 컨스트레인트를 가져야 함을 지정한다 (이것은 foreign 키가 또한 프라이머리 키의 부분일 때마다 함축된다).

우리는 delete 퍼포먼스가 중요한 시스템들에 대해 권장하고, 모든 키들은 on-delete="cascade"로 정의되고, Hibernate는 많은 DELETE 문장들 대신에, 데이터베이스 레벨의 ON CASCADE DELETE 컨스트레인트를 사용할 것이다. 이 특징은 Hibernate의 통상적인 버전화된 데이터에 대한 optimistic 잠금 방도를 무시한다는 점을 알고 있어라.

not-null 속성과 update 속성들은 단방향 one to many 연관관계를 매핑할 때 유용하다.  만일 당신이 단방향 one to many를 null이 허용되지 않는 foreign 키로 매핑할 경우, 당신은 <key not-null="true">를 사용하여 그 키 클럼을 선언해야 한다.

5.1.19. column 요소와 formula 요소

column 속성을 허용하는 임의의 매핑 요소는 대안적으로 하나의 <column> 서브요소를 수용할 것이다.  비슷하게 <formula>formula 속성에 대한  대안이다.

<column
        name="column_name"
        length="N"
        precision="N"
        scale="N"
        not-null="true|false"
        unique="true|false"
        unique-key="multicolumn_unique_key_name"
        index="index_name"
        sql-type="sql_type_name"
        check="SQL expression"/>
<formula>SQL expression</formula>

column 속성과 formula 속성은 예를 들어 신종 조인 조건들을 표현하기 위해 동일한 property 또는 연관관계 매핑 내에 결합될 수 있다.

<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>

5.1.20. import

당신의 어플리케이션이 동일한 이름을 가진 두 개의 영속 클래스들을 갖고, 당신이 Hibernate 질의들 내에서 전체 수식어가 붙은 (패키지)이름을 지정하는 것을 원하지 않는다고 가정하자. 클래스들은 auto-import="true"에 의존하기 보다 명시적으로 "import" 될 것이다. 당신은 심지어 명시적으로 매핑되지 않는 클래스들과 인터페이스들을 import 시킬 수 있다.

<import class="java.lang.Object" rename="Universe"/>
<import
class="ClassName" (1) rename="ShortName" (2) />
(1)

class: 임의의 Java 클래스의 전체 수식어가 붙은 클래스 이름.

(2)

rename (옵션- 디폴트는 수식어가 붙지 않은 클래스 이름): 질의 언어 내에서 사용될 이름.

5.1.21. any

하나 이상의 프로퍼티 매핑 타입이 존재한다.  <any> 매핑 요소는 여러 테이블들로부터 클래스들에 대한 하나의 다형성 연관관계를 정의한다. 이 매핑 타입은 언제나 하나 이상의 컬럼을 필요로 한다. 첫 번째 컬럼은 연관된 엔티티의 타입을 보관한다. 나머지 컬럼들은 식별자를 보관한다. 이런 종류의 연관관계들에 대해 foreign key 컨스트레인트를 지정하는 것이 불가능해서, 이것은 (다형성) 연관관계들을 매핑하는 통상적인 방법으로서 가장 확실한 수단이 아니다. 당신은 매우 특별한 경우들(예를 들어 감사 로그들, 사용자 세션 데이터 등)에서만 이것을 사용해야 한다.

meta-type 속성은 어플리케이션으로 하여금 데이터베이스 컬럼 값들을 id-type에 의해 지정된 타입의 식별자 프로퍼티들을 가진 영속 클래스들로 매핑시키는 맞춤형 타입을 지정하도록 한다.  당신은 meta-type의 값들로부터 클래스 이름들로의 매핑을 지정해야 한다.

<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>
<any
        name="propertyName"                      (1)
        id-type="idtypename"                     (2)
        meta-type="metatypename"                 (3)
        cascade="cascade_style"                  (4)
        access="field|property|ClassName"        (5)
        optimistic-lock="true|false"             (6)
>
        <meta-value ... />
        <meta-value ... />
        .....
        <column .... />
        <column .... />
        .....
</any>
(1) name: 프로퍼티 이름
(2) id-type: 식별자 타입.
(3) meta-type (옵션-디폴트는 string): discriminator 매핑에 허용되는 임의의 타입.
(4) cascade (옵션-디폴트는 none): cascade 스타일.
(5) access (옵션-디폴트는 property): Hibernate가 프로퍼티 값에 접근하는데 사용할 방도.
(6) optimistic-lock (옵션-디폴트는 true): 이 프로퍼티에 대한 업데이트들이 optimistic 잠금 획득을 필요로 하는지 여부를 지정한다. 달리 말해, 이 프로퍼티가 dirty일 경우에 버전증가가 발생할 것인지 여부를 정의한다.

5.2. Hibernate Types

5.2.1. Entities and values

영속 서비스에 관한 여러 Java 언어-레벨의 객체들을 이해하기 위해, 우리는 그것들을 다음 두 개의 그룹들로 분류할 필요가 있다:

entity 는 엔티티에 대한 참조들을 보관하는 임의의 다른 객체들과는 독립적으로 존재한다. 참조되지 않은 객체가 쓰레기 수집되는 통상의 자바 모형을 가진 이것과는 대조적이다. (저장들과 삭제들이 부모 엔티티로부터 그것의 자식으로의 케스케이드 되는 경우를 제외하면) 엔티티들은 명시적으로 저장되고 삭제되어야 한다. 이것은 도달 가능성(reachablity)에 의한 객체 영속성의 ODMG 모형과는 다르다 - 그리고 어플리케이션 객체들이 대형 시스템들에서 대개 어떻게 사용되는가에 훨씬 더 가깝게 대응한다. 엔티티들은 순환 참조와 공유 참조들을 지원한다. 그것들 또한 버전화 될 수 있다.

엔티티의 영속 상태는 다른 엔티티들에 대한 참조들과 value  타입들로 구성된다. 값들은 원시 타입들, 콜렉션들(하나의 콜렉션 내부에 있지 않는 것들), 컴포넌트들, 그리고 어떤 불변의 객체들이다. entities와는 달리, (특별한 콜렉션들과 컴포넌트들에서) 값들은 도달가능성(reachability)에 의해 영속화 되고 삭제 된다. value 객체들(과 원시 타입들)이 그것들의 포함하는 엔티티에 따라 영속화 되고 삭제 되므로, 그것들은 독립적으로 버전화 되지 않는다. 값들은 독립적인 엔티티를 갖지 않아서, 그것들은 두 개의 엔티티들이나 콜렉션들에 의해 공유될 수 없다.

지금까지 우리는 엔티티들을 참조하기 위해 "영속 클래스"를 사용해 왔다. 우리는 그것을 계속 사용할 것이다. 하지만 엄격히 말해, 영속 상태를 가진 모든 사용자 정의 클래스들은 엔티티들이 아니다. 컴포넌트는 value 의미를 가진 사용자 정의 클래스이다. java.lang.String 타입의 자바 프로퍼티는 또한 value 의미를 갖는다. 이 정의가 주어지면, 우리는 JDK에 의해 제공된 모든 타입들(클래스들)이 자바에서 value 타입 의미를 갖고, 반면에 사용자 정의 타입들은 엔티티 또는 type 의미로서 매핑된다고 말할 수 있다. 이 판단은 어플리케이션 개발자에게 달려 있다. 도메인 모형에서 엔티티 클래스에 대한 좋은 힌트는 그 클래스의 하나의 인스턴스에 대한 공유된 참조들인 반면에, composition이나 aggregation은 대개 value 타입으로 변환된다.

우리는 문서를 통해 두 개념들을 다시 고찰할 것이다.

도점점은 Java type 시스템(과 엔티티들 및 value 타입들에 대한 개발자의 정의)를 SQL/데이터베이스 type 타입으로 매핑하는 것이다. 두 시스템들 사이의 다리는 Hibernate에 의해 제공된다: 엔티티들의 경우 우리는 <class>, <subclass> 등을 사용한다.value 타입들의 경우 우리는 대개 type 속성을 가진 <property>, <component> 등을 사용한다. 이 속성의 값은 Hibernate 매핑 타입의 이름이다. Hibernate는 (표준 JDK value 타입들에 대해) 많은 매핑들을 제공한다. 나중에 보게 되듯이, 당신은 당신 자신의 매핑 타입들을 작성할 수 있고 마찬가지로 당신의 맞춤형 변환 방도들을 구현할 수 있다. 

콜렉션들을 제외한 모든 미리 빌드된 Hibernate 타입들은 null 의미를 지원한다.

5.2.2. 기본 value 타입들

기존 타입들은 대략 다음과 같이 카테고리로 분류된다

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

자바 원시타입들이나 wrapper 클래스들로부터 적절한(벤더-지정적인) SQL 컬럼 타입들로의 타입 매핑. boolean, yes_no, true_false 는 Java boolean 또는 java.lang.Boolean에 대한 모든 대체적인 인코딩들이다.

string

java.lang.String 로부터 VARCHAR (또는 Oracle VARCHAR2)로의 타입 매핑.

date, time, timestamp

java.util.Date 와 그것의 서브클래스로부터 SQL 타입들 DATE, TIME , TIMESTAMP (또는 등가물)로의 타입 매핑.

calendar, calendar_date

java.util.Calendar 로부터 SQL 타입들 TIMESTAMP, DATE (또는 등가물)로의 타입 매핑.

big_decimal, big_integer

java.math.BigDecimaljava.math.BigInteger로부터 NUMERIC (또는 Oracle NUMBER)로의 타입 매핑들.

locale, timezone, currency

java.util.Locale, java.util.TimeZone, java.util.Currency 로부터 VARCHAR (또는 Oracle VARCHAR2)로의 타입 매핑. Locale Currency 의 인스턴스들은 그것드의 ISO 코드들로 매핑된다. TimeZone의 인스턴스들은 그것들의 ID로 매핑된다.

class

java.lang.Class 로부터 VARCHAR (또는 Oracle VARCHAR2)로의 타입 매핑. Class 는 그것의 전체 수식어가 붙은 이름으로 매핑된다.

binary

byte 배열들을 적절한 SQL 바이너리 타입으로 매핑시킨다.

text

long Java 문자열을 SQL CLOB 또는 TEXT 타입으로 매핑시킨다.

serializable

serializable Java 타입들을 적절한  SQL binary 타입으로 매핑시킨다. 당신은 또한 디폴트로 기본 타입이 아닌 serializable  자바 클래스 또는 인터페이스의 이름을 가진 Hibernate 타입 serializable 을 나타낼 수도 있다.

clob, blob

java.sql.Clobjava.sql.Blob JDBC 클래스들에 대한 타입 매핑들.  이들 타입들은 몇몇 어플리케이션들에서는 불편하다. 왜냐하면 blob 또는 clob 객체는 트랜잭션 외부에서 재사용될 수 없기 때문이다.(게다가 드라이버 지원이 비일관적이고 페치되어야 한다)

엔트리들과 콜렉션들의 유일 식별자들은 binary, blob, clob를 제외한 기본 타입 중 어느 것일 수 있다. (Composite 식별자들이 또한 허용된다. 아래를 보라.)

기본 value 타입들은 org.hibernate.Hibernate에 정의된 대응하는 Type 컨스트레인트들을 갖는다. 예를 들어, Hibernate.STRINGstring 타입을 표현한다.

5.2.3. 맞춤형 value 타입들

개발자들이 그들 자신들의 value 타입들을 생성시키는 것이 상대적으로 쉽다. 예를 들어, 당신은 java.lang.BigInteger 타입의 프로퍼티들을 VARCHAR 컬럼들로 영속화 시키고자 원할 수 있다. Hibernate는 이것을 위한 사전에 만들어진 타입을 제공하지 않는다. 그러나 맞춤형 타입들은 프로퍼티(또는 콜렉션 요소)를 하나의 테이블 컬럼으로의 매핑에 제약되지 않는다. 따라서 예를 들어, 당신은 FIRST_NAME, INITIAL, SURNAME 컬럼들로 영속화 되는 java.lang.String 타입의 자바 프로퍼티 getName()/setName()를 가질 수 있다. 

맞춤형 타입을 구현하려면, org.hibernate.UserType 또는 org.hibernate.CompositeUserType 을 구현하고 그 타입의 전체 수식어가 붙은 클래스명을 사용하여 프로퍼티들을 선언하라. 가능한 종류의 것들을 보려면 org.hibernate.test.DoubleStringType 을 체크하라. 

<property name="twoStrings" type="org.hibernate.test.DoubleStringType">
    <column name="first_string"/>
    <column name="second_string"/>
</property>

하나의 프로퍼티를 여러 개의 컬럼들로 매핑시키는 <column> 태그의 사용을 주목하라.

CompositeUserType, EnhancedUserType, UserCollectionType 그리고 UserVersionType 인터페이스들은 더 많은 특화된 사용들에 대한 지원을 제공한다.

당신은 매핑 파일 속에 UserType에 대한 파라미터들을 제공할 수도 있다. 이것을 행하기 위해, 당신의 UserTypeorg.hibernate.usertype.ParameterizedType 인터페이스를 구현해야 한다. 당신의 맞춤형 타입에 파라미터들을 제공하기 위해, 당신은 당신의 매핑 파일들 속에 <type> 요소를 사용할 수 있다.

<property name="priority">
    <type name="com.mycompany.usertypes.DefaultValueIntegerType">
        <param name="default">0</param>
    </type>
</property>

UserType은 이제 그것에 전달된 Properties 객체로부터 default로 명명된 파라미터에 대한 값을 검색할 수 있다.

만일 당신이 매우 자주 어떤 UserType을 사용할 경우, 그것은 그것에 대한 더 짧은 이름을 정의하는 것이 유용할 수 있다. <typedef> 요소를 사용하여 이것을 행할 수 있다. Typedef들은 이름을 맞춤형 타입에 할당하고, 또한 만일 그 타입이 파라미터화 된 경우에 디폴트 파라미터 값들의 리스트를 포함할 수도 있다.

<typedef class="com.mycompany.usertypes.DefaultValueIntegerType" name="default_zero">
    <param name="default">0</param>
</typedef>
<property name="priority" type="default_zero"/>

property 매핑 상에 type 파라미터들을 사용함으로써 경우에 맞게 typedef 내에 제공된 파라미터들을 오버라이드 시키는 것이 가능하다.

비록 Hibernate의 풍부한 범위의 미리 만들어진 타입들과 컴포넌트들에 대한 지원이 당신이 가끔 맞춤형 타입을 사용할 필요가 거의 없을 것임을 의미할 지라도, 그럼에도 불구하고 그것은 당신의 어플리케이션에서 자주 발생하는 (엔티티가 아닌) 클래스들에 대해 맞춤형 타입들을 사용하는 좋은 형식으로 간주된다. 예를 들어 MonetaryAmount 클래스는 비록 그것이 컴포넌트로서 쉽게 매핑될 수 있을지라도,  CompositeUserType에 대한 좋은 후보이다. 이것에 대한 하나의 동기는 추상화이다. 맞춤형 타입으로, 당신의 매핑 문서들은 화폐 값들을 표현하는 당신의 방법에서 가능한 변경들에 대해 장차 검증될 것이다.

5.3. SQL 인용부호 표시된 식별자들

당신은 매핑 문서 내에서 테이블 또는 컬럼 이름을 역인용기호(`)들 속에 넣어서 생성된 SQL에서 식별자를 인용부호 처리하도록 Hibernate에게 강제할 수도 있다. Hibernate는 SQL Dialect 에 대해 정확한 인용 스타일을 사용할 것이다(대개 이중 인용부호 이지만, SQL Server의 경우에는 모난 괄호들이고 MySQL의 경우에는 역인용부호(`)).

<class name="LineItem" table="`Line Item`">
    <id name="id" column="`Item Id`"/><generator class="assigned"/></id>
    <property name="itemNumber" column="`Item #`"/>
    ...
</class>

5.4. Metadata 대안들

XML은 모든 사람들을 위한 것이 아니지만, Hibernate에서 O/R 매핑 메타데이터를 정의하는 몇몇 대안적인 방법들이 존재한다.

5.4.1. XDoclet 마크업 사용하기

많은 Hibernate 사용자들은 XDoclet @hibernate.tag들을 사용하여 소스 코드 속에 직접 매핑 정보를 삽입시키는 것을 선호한다.  우리는 이 문서에서 이 접근법을 다루지 않을 것이다. 왜냐하면 엄격하게 그것은 XDoclet의 부분으로 간주되기 때문이다. 하지만 우리는 XDoclet 매핑들을 가진 Cat 클래스에 관한 다음 예제를 포함한다.

package eg;
import java.util.Set;
import java.util.Date;

/**
 * @hibernate.class
 *  table="CATS"
 */
public class Cat {
    private Long id; // identifier
    private Date birthdate;
    private Cat mother;
    private Set kittens
    private Color color;
    private char sex;
    private float weight;

    /*
     * @hibernate.id
     *  generator-class="native"
     *  column="CAT_ID"
     */
    public Long getId() {
        return id;
    }
    private void setId(Long id) {
        this.id=id;
    }

    /**
     * @hibernate.many-to-one
     *  column="PARENT_ID"
     */
    public Cat getMother() {
        return mother;
    }
    void setMother(Cat mother) {
        this.mother = mother;
    }

    /**
     * @hibernate.property
     *  column="BIRTH_DATE"
     */
    public Date getBirthdate() {
        return birthdate;
    }
    void setBirthdate(Date date) {
        birthdate = date;
    }
    /**
     * @hibernate.property
     *  column="WEIGHT"
     */
    public float getWeight() {
        return weight;
    }
    void setWeight(float weight) {
        this.weight = weight;
    }

    /**
     * @hibernate.property
     *  column="COLOR"
     *  not-null="true"
     */
    public Color getColor() {
        return color;
    }
    void setColor(Color color) {
        this.color = color;
    }
    /**
     * @hibernate.set
     *  inverse="true"
     *  order-by="BIRTH_DATE"
     * @hibernate.collection-key
     *  column="PARENT_ID"
     * @hibernate.collection-one-to-many
     */
    public Set getKittens() {
        return kittens;
    }
    void setKittens(Set kittens) {
        this.kittens = kittens;
    }
    // addKitten not needed by Hibernate
    public void addKitten(Cat kitten) {
        kittens.add(kitten);
    }

    /**
     * @hibernate.property
     *  column="SEX"
     *  not-null="true"
     *  update="false"
     */
    public char getSex() {
        return sex;
    }
    void setSex(char sex) {
        this.sex=sex;
    }
}

XDoclet 와 Hibernate 에 관한 추가 예제들은 Hibernate 웹 사이트를 보라.

5.4.2. Using JDK 5.0 Annotations

JDK 5.0은 언어 레벨에서 XDoclet-스타일의 주석들, type-safe와 컴파일 시 체킹을 도입했다. 이 메커니즘은 XDoclet 주석들 보다 더 강력하고 도구들과 IDE들에 의해 더 좋게 지원된다. 예를 들어 IntelliJ IDEA는 JDK 5.0 주석들에 대한 자동-완성 기능과 구문 강조를 지원한다. EJB 명세서의 새로운 개정판(JSR-220)은 엔티티 빈즈에 대한 프라이머리 메타데이터 메커니즘으로서 JDK 5.0 주석들을 사용한다. Hibernate3는 JSR-220의 EntityManager(영속 API)를 구현하고, 매핑 메타데이터에 대한 지원은 별도의 내려받기로서 Hibernate Annotations 패키지를 통해 이용 가능하다. EJB3 (JSR-220) 과 Hibernate3 metadata 양자가 지원된다.

다음은 EJB 엔티티 빈으로서 주석이 붙은 POJO 클래스에 관한 예제이다:

@Entity(access = AccessType.FIELD)
public class Customer implements Serializable {

    @Id;
    Long id;

    String firstName;
    String lastName;
    Date birthday;

    @Transient
    Integer age;

    @Dependent
    private Address homeAddress;

    @OneToMany(cascade=CascadeType.ALL,
               targetEntity="Order")
    @JoinColumn(name="CUSTOMER_ID")
    Set orders;

    // Getter/setter and business methods
}

JDK 5.0 주석들 (과 JSR-220)에 대한 지원은 여전히 작업이 진행 중이고 완성되지 않았음을 노트하라.

6장. 콜렉션 매핑

6.1. 영속 콜렉션들

예를 들어 Hibernate는 영속 콜렉션-값을 가진 필드들이 인터페이스 타입으로서 선언되는 것을 필요로 한다:

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; }
}

실제 인터페이스는 java.util.Set, java.util.Collection, java.util.List, java.util.Map, java.util.SortedSet, java.util.SortedMap 또는 당신이 좋아하는 어떤 것일 수 있다!(여기서 "당신이 좋아하는 어떤 것"은 당신이 org.hibernate.usertype.UserCollectionType에 대한 구현을 작성해야 함을 의미한다.)

우리가 HashSet의 인스턴스를 가진 인스턴스 변수를 초기화 시켰던 방법을 주목하라. 이것은 새로이 초기화 된(비-영속) 인스턴스들을 가진 콜렉션 값 프로퍼티들을 초기화 시키는 최선의 방법이다. 당신이 -예를 들어 persist()를 호출하여- 인스턴스를 영속화 시킬 때 Hibernate는 실제로 HashSet을 Hibernate 자신의 Set 구현의 인스턴스로 대체시킬 것이다. 다음과 같은 오류들을 관찰하라:

Cat cat = new DomesticCat();
Cat kitten = new DomesticCat();
....
Set kittens = new HashSet();
kittens.add(kitten);
cat.setKittens(kittens);
session.persist(cat);
kittens = cat.getKittens(); // 좋다, kittens 콜렉션은 Set이다
(HashSet) cat.getKittens(); //오류!

Hibernate에 의해 도입된 영속 콜렉션들은 인터페이스 타입에 따라 HashMap, HashSet, TreeMap, TreeSet 또는 ArrayList과 같이 행위한다. 

콜렉션 인스턴스들은 value 타입들을 가진 통상의 특징을 갖는다. 그것들은 영속 객체에 의해 참조될 때 자동적으로 영속화 되고 참조 해제될 때 자동적으로 삭제된다. 만일 하나의 콜렉션이 하나의 영속 객체로부터 또 다른 영속 객체로 전달될 때, 그것의 요소들은 하나의 테이블로부터  다른 테이블로 이동될 수 있다. 두 개의 엔티티들은 동일한 콜렉션 인스턴스에 대한 참조를 공유하지 않는다. 기본 관계형 모형 때문에 콜렉션 값 프로퍼티들은 null 값 의미들을 지원하지 않는다; Hibernate는 null 콜렉션 참조와 공백의 콜렉션 사이를 구별 짓지 않는다.

당신은 이것의 어떤 것에 대해 너무 많이 걱정하지 않아도 될 것이다. 당신이 통상의 자바 콜렉션들을 사용하는 것과 동일한 방법으로 영속 콜렉션들을 사용하라. 단지 당신이 양방향 연관관계들에 대한 의미를 확실히 이해하도록 하라(나중에 논의됨).

6.2. 콜렉션 매핑하기

콜렉션을 매핑하는데 사용되는 Hiberante 매핑 요소는 인터페이스의 타입에 의존한다. 예를 들어 <set> 요소는 Set 타입의 매핑 프로퍼티들에 사용된다.

<class name="Product">
    <id name="serialNumber" column="productSerialNumber"/>
    <set name="parts">
        <key column="productSerialNumber" not-null="true"/>
        <one-to-many class="Part"/>
    </set>
</class>

<set>과는 별도로, 또한 <list>, <map>, <bag>, <array>, <primitive-array> 매핑 요소들이 존재한다. <map> 요소가 대표적이다:

<map
    name="propertyName"                                         (1)
    table="table_name"                                          (2)
    schema="schema_name"                                        (3)
    lazy="true|false"                                           (4)
    inverse="true|false"                                        (5)
    cascade="all|none|save-update|delete|all-delete-orphan"     (6)
    sort="unsorted|natural|comparatorClass"                     (7)
    order-by="column_name asc|desc"                             (8)
    where="arbitrary sql where condition"                       (9)
    fetch="join|select|subselect"                               (10)
    batch-size="N"                                              (11)
    access="field|property|ClassName"                           (12)
    optimistic-lock="true|false"                                (13)
>

    <key .... />
    <map-key .... />
    <element .... />
</map>
(1)

name 콜렉션 프로퍼티 이름

(2)

table (옵션-디폴트는 프로퍼티 이름) 콜렉션 테이블의 이름(one-to-many 연관관계들에 대해서는 사용되지 않음)

(3)

schema (옵션) 루트 요소 상에 선언된 스키마를 오버라이드 시키는 테이블 스키마의 이름

(4)

lazy (옵션-디폴트는 true) lazy 초기화를 가능하게 한다 (배열들에 대해서는 이용 불가능함)

(5)

inverse (옵션-디폴트는 false) 이 콜렉션을 양방향 연관관계의 "inverse" 끝(end)으로 표시한다

(6)

cascade (옵션-디폴트는 none) 오퍼레이션들이 자식 엔티티들에 대해 케스케이드하는 것을  이용 가능하게 한다

(7)

sort (옵션) natural 정렬 순서로 정렬된 콜렉션 또는 주어진 comparator 클래스를 지정한다

(8)

order-by (옵션, JDK1.4 에서만) asc 또는 desc 옵션과 함께 Map, Set 또는 bag의 반복 순서를 정의하는 테이블 컬럼(또는 컬럼들)을 지정한다

(9)

where (옵션) 콜렉션을 검색하거나 제거할 때 사용될 임의적인 SQL WHERE 조건을 지정한다(콜렉션이 오직 이용 가능한 데이터의 부분집합 만을 포함할 경우에 유용하다) specify an arbitrary SQL WHERE condition to be used when retrieving or removing the collection (useful if the collection should contain only a subset of the available data)

(10)

fetch (옵션,디폴트는 select) outer-join 페칭과 순차적인 select에 의한 페칭, 그리고 순차적인 subselect 페칭에 의한 페칭 사이에서 선택하라. 오직 하나의 콜렉션 만이 SQL SELECT에 대한 outer join에 의해 페치될 수 있다.

(11)

batch-size (옵션,디폴트는 1) 이 콜렉션의 lazily fetching 인스턴스에 대해 "배치 사이즈"를 지정하라.

(12)

access (옵션-디폴트는 property): Hibernate가 프로퍼티 값에 접근하는데 사용할 방도.

(13) optimistic-lock (옵션-디폴트는 true): 콜렉션의 상태에 대한 변경들이 소유하는 엔티티의 버전의 증가로 귀결될 것인지를 지정한다. (one to many 연관들에 대해, 이 설정을 사용 불가능하게 하는 것이 종종 합당하다.)

6.2.1. 콜렉션 foreign 키들

콜렉션 인스턴스들은 그 콜렉션을 소유하는 엔티티의 foreign 키에 의해 데이터베이스 내에서 구별지워진다. 이 foreign 키는 그 콜렉션 테이블의 콜렉션 키 컬럼 (또는 컬럼들)로서 참조된다. 그 콜렉션 키 키러럼은 <key> 요소에 의해 매핑된다.

foreign 키 컬럼에 대한 null 허용 가능 컨스트레인트가 존재할 수 있다. 대부분의 콜렉션들에 대해, 이것이 당연히 수반된다. 단방향 one to many 연관들의 경우, foreign 키는 디폴트로 null 허용 가능하여서, 당신은  not-null="true"를 지정할 필요가 있을 수 있다.

<key column="productSerialNumber" not-null="true"/>

foreign 키 컨스트레인트는 ON DELETE CASCADE를 사용할 수도 있다.

<key column="productSerialNumber" on-delete="cascade"/>

<key> 요소에 대한 전체 정의는 앞 장을 보라. 

6.2.2. 콜렉션 요소들

콜렉션들은 모든 기본 타입들, 컴포넌트들, 그리고 물론 다른 엔티티들에 대한 참조들을 포함하여 거의 대부분의 어떤 다른 Hibernate 타입을 포함할 수도 있다. 이것은 중요한 구분이다: 콜렉션 내에 있는 객체는 "값(value)" 의미로 처리될 수도 있거나(그것의 생명주기는 콜렉션 소유자에 의존한다) 그것은 그것 자신의 생명주기를 가진 또 다른 엔티티에 대한 참조일 수 있다. 후자의 경우, 두 개의 객체들 사이의 "링크" 만이 그 콜렉션에 의해 소유된 상태로 간주된다.

포함된 타입은 콜렉션 요소 타입으로서 불려진다. 콜렉션 요소들은 <element> 또는 <composite-element>에 의해 매핑되거나, 엔티티 참조들의 경우에 <one-to-many> 또는 <many-to-many>로서 매핑된다. 처음 두 개는 요소들을 value 의미로 매핑시키고 다음 두개는 엔티티 연관들을 매핑하는데 사용된다.

6.2.3. 인덱싱 된 콜렉션들

set 과 bag 의미들을 가진 것들을 제외하면 모든 콜렉션 매핑들은 콜렉션 테이블 내에 인덱스 컬럼-배열 인덱스, 또는 List 인덱스 또는 Map 키로 매핑시키는 컬럼-을 필요로 한다. Map의 인덱스는 <map-key>로 매핑된 어떤 기본 타입일 수 있고, 그것은 <map-key-many-to-many>로 매핑된 엔티티 참조일 수 있거나, 그것은 <composite-map-key>로 매핑된 composite 타입일 수 있다. 배열 또는 리스트의 인덱스는 항상 integer 타입이고 <list-index> 요소를 사용하여 매핑된다.  매핑된 컬럼은 순차적인 정수들을 포함한다(디폴트로 0에서 시작하는 번호가 붙여짐).

<list-index 
        column="column_name"                (1)
        base="0|1|..."/>
(1) column_name (필수): 콜렉션 인덱스 값들을 보관하는 컬럼의 이름.
(1) base (옵션 디폴트는 0): 리스트 또는 배열의 첫 번째 요소에 대응하는 인덱스 컬럼의 값.
<map-key 
        column="column_name"                (1)
        formula="any SQL expression"        (2)
        type="type_name"                    (3)
        length="N"/>
(1) column (옵션): 콜렉션 인덱스 값들을 보관하는 컬럼의 이름.
(2) formula (옵션): map의 키를 평가하는데 사용되는 SQL formula.
(3) type (옵션, 디폴트는 integer): 콜렉션 인덱스의 타입.
<map-key-many-to-many
        column="column_name"                (1)
        formula="any SQL expression"        (2)
        class="ClassName"                   (3)
/>
(1) column (옵션): 콜렉션 인덱스 값들에 대한 foreign 키 컬럼의 이름.
(2) formula (옵션): map의 foreign 키를 평가하는데 사용되는 SQL formula.
(3) class (필수): 콜렉션 인덱스로서 사용되는 엔티티 클래스.

만일 당신의 테이블이 인덱스 컬럼을 가지 않고, 당신이 여전히 프로퍼티 타입으로서 List 를 사용하고자 원할 경우, 당신은 그 프로퍼티를 Hibernate <bag>으로서 매핑해야 한다. bag이 데이터베이스로부터 검색될 때 그것은 그것의 순서를 보유하지 않지만, 그것은 선택적으로 정렬(sorting)되거나 ordering될 수도 있다.

많은 공통된 관계형 모형들을 다루는, 콜렉션들에 대해 생성될 수 있는 매핑들의 영역이 꽤 존재한다. 여러가지 매핑 선언들이 데이터베이스 테이블들로 변환되는 방법을 당신이 느끼려면 스키마 생성으로 실험하기를 우리는 제안한다.

6.2.4. value들을 가진 콜렉션들과 many-to-many 연관들

어떤 값들을 가진 콜렉션과 many-to-many 연관은 foreign 키 컬럼이나 컬럼들, 콜렉션 요소 컬럼이나 컬럼들 그리고 가능하면 인덱스 컬럼들이나 컬럼들을 가진 전용 콜렉션 테이블을 필요로 한다.

값들을 가진 콜렉션의 경우, 우리는 <element> 태그를 사용한다.

<element
        column="column_name"                (1)
        formula="any SQL expression"        (2)
        type="typename"                     (3)
        length="N"
        precision="N"
        scale="N"
        not-null="true|false"
        unique="true|false"
/>
(1) column (옵션): 콜렉션 요소 값들을 보관하는 컬럼의 이름.
(2) formula (옵션): 요소를 평가하는데 사용되는 SQL formula.
(3) type (필수): 콜렉션 요소의 타입.

many-to-many 연관은  <many-to-many> 요소를 사용하여 지정된다.

<many-to-many
        column="column_name"                               (1)
        formula="any SQL expression"                       (2)
        class="ClassName"                                  (3)
        fetch="select|join"                                (4)
        unique="true|false"                                (5)
        not-found="ignore|exception"                       (6)
        entity-name="EntityName"
    />
(1) column (옵션): 요소 foreign 키 컬럼의 이름.
(2) formula (옵션): 요소 foreign 키 값을 평가하는데 사용되는 SQL formula.
(3) class (필수): 연관된 클래스의 이름.
(4) fetch (옵션- 디폴트는 join): 이 연관에 대해 outer-join 페칭 또는 sequential select 페칭을 이용 가능하게 만든다. 이것은 특별한 경우이다; 엔티티 그리고 다른 엔티티들에 대한 그것의 many-to-many 관계들에 대한 (하나의 SELECT 내에서) 전체 eager 페칭의 경우, 당신은 콜렉션 그 자체에 대해서 뿐만 아니라 내포된 요소 <many-to-many> 상의 이 속성에 대해 join 페칭을 이용 가능하게 할 것이다.
(5) unique (옵션): foreign-key 컬럼에 대한 유일 컨스트레인트의 DDL 생성을 가능하도록 한다. 이것은 연관 다중성(association multiplicity)을 효과적으로 one to many로 만든다. 
(6) not-found (옵션- 디폴트는 exception): 누락된 행들을 참조하는 foreign key들이 어떻게 처리될 것인지를 지정한다: ignore는 한 개의 누락된 행을 하나의 null 연관으로 처리할 것이다.

몇몇 예제들, 먼저 문자열들을 가진 set:

<set name="names" table="person_names">
    <key column="person_id"/>
    <element column="person_name" type="string"/>
</set>

(order-by  속성에 의해 결정되는 반복 순서를 가진) 정수들을 포함하는 bag :

<bag name="sizes" 
        table="item_sizes" 
        order-by="size asc">
    <key column="item_id"/>
    <element column="size" type="integer"/>
</bag>

엔티티들을 가진 배열 - 이 경우에, many to many 연관 :

<array name="addresses" 
        table="PersonAddress" 
        cascade="create">
    <key column="personId"/>
    <list-index column="sortOrder"/>
    <many-to-many column="addressId" class="Address"/>
</array>

date들에 대한 문자열 인덱스들을 가진 map :

<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>

컴포넌트들의 리스트(다음 장에서 논의됨):

<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>

6.2.5. One-to-many 연관들

one to many 연관은 중재하는 콜렉션 테이블 없이 foreign 키를 통해 두 개의 클래스들의 테이블들을 연결시킨다. 이 매핑은 통상의 자바 콜렉션들의 어떤 의미를 상실한다:

  • 포함된 엔티티 클래스의 인스턴스는 그 콜렉션의 하나 이상의 인스턴스에 속하지 않는다
  • 포함된 엔티티 클래스의 인스턴스는 콜렉션 인덱스의 하나 이상의 값에서 나타나지 않는다

Product로부터 Part로의 연관은 foreign 키 컬럼과 Part 테이블에 대한 인덱스 컬럼의 존재를 필요로 한다. <one-to-many> 태그는 이것이 one to many 연관임을 나타낸다.

<one-to-many 
        class="ClassName"                                  (1)
        not-found="ignore|exception"                       (2)
        entity-name="EntityName"/>
(1) class (필수): 연관된 클래스의 이름.
(2) not-found (옵션- 디폴트는 exception): 누락된 행들을 참조하는 foreign key들이 어떻게 처리될 것인지를 지정한다: ignore는 한 개의 누락된 행을 하나의 null 연관으로 처리할 것이다.

<one-to-many> 요소는 어떤 컬럼들을 선언하는데 필요하지 않음을 주목하라. 어딘가에 table 이름을 지정하는 것도 필수적이지 않다.

매우 중요한 노트:  만일 <one-to-many> 연관의 foreign 키 컬럼이 NOT NULL로 선언될 경우,  당신은 <key> 매핑 not-null="true"를 선언해야 하거나 inverse="true"로 마크된 콜렉션 매핑을 가진 양방향 연관을 사용해야 한다. 양방향 연관들에 대한 논의는 이 장의 뒷부분을 보라.

이 예제는 name으로 Part 엔티티들을 가진 map을 보여준다(여기서 partNamePart의 영속 프로퍼티이다).  formula-기반 index의 사용을 주목하라.

<map name="parts"
        cascade="all">
    <key column="productId" not-null="true"/>
    <map-key formula="partName"/>
    <one-to-many class="Part"/>
</map>

6.3. 개선된 콜렉션 매핑들

6.3.1. Sorted 콜렉션들

Hibernate는 java.util.SortedMapjava.util.SortedSet를 구현하는 콜렉션들을 지원한다. 당시은 이 매핑 파일 속에 하나의 comparator를 지정해야 한다:

<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>

sort 속성에 허용되는 값들은 unsorted, natural 그리고 java.util.Comparator를 구현하는 클래스의 이름이다.

Sorted 콜렉션들은 java.util.TreeSet 또는 java.util.TreeMap처럼 행동한다.

만일 당신이 데이터베이스 그 자체가 콜렉션 요소들을 순서지움(ordering)하기 원할 경우 set, bag, map 매핑들의 속성을 사용하라. 이 해결책은 JDK 1.4 이상의 버전에서만 이용 가능하다(그것은 LinkedHashSet 또는 LinkedHashMap을 사용하여 구현된다). 이것은 메모리 내에사가 아닌, SQL 질의 내에서 순서지움(ordering)을 수행한다.

<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>

order-by 속성의 값은 HQL 순서지움(ordering)이 아니라 SQL 순서지움(ordering)임을 노트하라!

연관들은 콜렉션 filter()를 사용하여 실행 시에 어떤 임의의 criteria(기준)을 사용하여 정렬(sort)될 수도 있다.

sortedUsers = s.createFilter( group.getUsers(), "order by this.name" ).list();

6.3.2. 양방향 연관들

양방향 연관은 연관의 양 "끝(end)들"로부터 네비게이션을 허용한다. 두 가지 종류의 양방향 연관들이 지원된다:

one-to-many
한쪽 끝에 set 또는 bag 값을 갖고, 다른 쪽 긑에 단일 값을 가진 연관
many-to-many
양 끝에서 set 또는 bag 값을 가진 연관

당신은 동일한 두 개의 many-to-many 연관들을 데이터베이스 테이블로 간단하게 매핑함으로써 그리고 한 쪽 끝을 inverse(당신의 선택은 하나이지만, 그것은 인덱싱된 콜렉션일 수 없다)로 선언함으로써 하나의 many-to-many 양방향 연관을 지정할 수도 있다.

다음은 양방향 many-to-many 연관에 관한 예제이다; 각각의 카테고리는 많은 아이템들을 가질 수 있고 각각의 아이템은 많은 카테고리들 속에 있을 수 있다:

<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="CATEGORY_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>

연관의 inverse end에 대해서만 행해진 변경들은  영속화 되지 않는다. 이것은 Hibernate가 모든 양방향 연관에 대해 메모리 내에 두 개의 표상들을 갖는다는 점을 의미한다: A로부터 B로의 하나의 링크와 B로부터 A로의 하나의 링크. 만일 당신이 자바 객체 모형에 대해 그리고 자바에서 many-to-many 관계를 생성시키는 방법에 대해 생각하면 이것은 이해하기가 더 쉽다:

category.getItems().add(item);          // category는 이제 관계에 대해 "안다"
item.getCategories().add(category);     // item은 이제 관계에 대한 "안다"

session.persist(item);                   // 관계는 저장되지 않을 것이다! 
session.persist(category);               // 관계가 저장될 것이다.

non-inverse 측은 메모리 내 표상을 데이터베이스로 저장하는데 사용된다.

당신은 동일한 테이블 컬럼(들)에 대한 one-to-many 연관을 many-to-one 연관으로서 매핑하고 many-값을 가진 끝(end)을 inverse="true"로 선언함으로써 양방향 연관을 정의할 수도 있다.

<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="eg.Child">
    <id name="id" column="id"/>
    ....
    <many-to-one name="parent" 
        class="Parent" 
        column="parent_id"
        not-null="true"/>
</class>

연관의 한쪽 끝을 inverse="true"로 매핑하는 것은 cascade들을 가진 오퍼레이션에 영향을 주지 않고, orthogonal 개념들이다!

6.3.3. Ternary associations(세겹 연관들)

세 겹의 연관을 매핑하는 세 가지 가능한 접근법들이 존재한다. 하나의 접근법은 그것의 인덱스로서 연관관계를 가진 Map을 사용하는 것이다:

<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>
<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>

두 번째 접근법은 그 연관을 엔티티 클래스로서 단순하게 리모델링 하는 것이다. 이것은 우리가 가장 공통적으로 사용하는 접근법이다.

마지막 대안은 우리가 나중에 논의하게 될 composite 요소들을 사용하는 것이다.

6.3.4. <idbag> 사용하기

만일 당신이 composite 키가 나쁜 것이고 그 엔티티들이 합성 식별자들(대용 키들, surrogate keys)을 가져야 한다는 우리의 견해를 전적으로 수용할 경우, 당신은 우리가 지금까지 보았던 값들을 가진 콜렉션들과 many to many 연관들이 composite 키들을 가진 테이블들로 모두 매핑된다는 약간 이상한 점을 발견할 수도 있다! 이제 이 점은 꽤 논의의 여지가 있다; 순수한 연관 테이블은 (비록 composite 값들을 가진 콜렉션일 수 있을지라도) 대용 키로부터 많은 이점을 취하지 않는 것처럼 보인다. 그럼에도 불구하고 Hibernate는 당신이 many to many 연관들과 값들을 가진 콜렉션들을 대용 키를 가진 테이블로 매핑시키는 것을 당신에게 허용해주는 특징을 제공한다.

<idbag> 요소는 bag 의미를 가진 List (또는 Collection)을 매핑하도록 당신에게 허용해준다.

<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="eg.Person" outer-join="true"/>
</idbag>

당신이 볼 수 있듯이, <idbag>은 마치 엔티티 클래스인양 synthetic id generator(합성 id 생성자)를 갖는다! 다른 대용 키는 각각의 콜렉션 행에 할당된다. 하지만 Hibernate는 특정 행의 대용 키 값을 발견하는 메커니즘을 제공하지 않는다.

<idbag>의 업데이트 퍼포먼스는 정규 <bag> 보다 훨씬 좋음을 노트하라! Hibernate는 마치 list, map, 또는 set인양, 개별 행들을 효율적으로 위치지울 수 있고 그것들을 개별적으로 업데이트 하거나 삭제시킬 수 있다.

현재 구현에서, native identifier 생성 방도는 <idbag> 콜렉션 식별자들에 대해 지원되지 않는다.

6.4. 콜렉션 예제들

앞의 절들은 꽤 혼동스럽다. 따라서 예제를 살펴보자. 다음 클래스:

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; }

    ....
    ....
}

Child 인스턴스들을 가진 하나의 콜렉션을 갖고 있다. 만일 각각의 자식이 최소한 한 개의 부모를 가질 경우, 대부분의 고유한 매핑은 one-to-many 연관이다:

<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>

이것은 다음 테이블 정의들로 매핑된다: :

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

만일 부모가 필수적이라면, 양방향 one-to-many 연관관계를 사용하라:

<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>

 NOT NULL 컨스트레인트를 주목하라:

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

대안적으로, 만일 당신이 이 연관관계가 단방향이어야 함을 절대적으로 역설할 경우, 당신은 <key> 매핑 상에 NOT NULL 컨스트레인트를 선언할 수 있다:

<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>

반면에, 만일 자식이 여러 부모들을 가질 수 있을 경우, many-to-many 연관이 적절하다:

<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>

테이블 정의들:

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

부모/자식 관계 매핑을 연습하는 더 많은 예제들과 전체 리허설은 21 장, 예제: Parent/Child를 보라.

비록 더 많은 신종 연관 매핑들이 가능할지라도, 우리는 다음 장에서 모든 가능성들을 분류할 것이다.

7장. 연관 매핑들

7.1. 개요

연관 매핑들은 올바른 것을 얻기가 흔히 가장 어려운 것이다. 이 절에서 우리는 단방향 매핑들에서 시작하고 양방향 매핑들을 검토함으로써 하나씩 표준적인 경우들을 상세히 논의할 것이다. 우리는 모든 예제들에서 PersonAddress를 사용할 것이다.

우리는 그것들을 중재하는 join 테이블로 매핑할 것인지 여부, 그리고 multiplicity(다중성)에 따라 연관들을 분류할 것이다.

null 허용 가능한 foreign 키들은 전통적인 데이터 모델링에서 좋은 실례로 간주되지 않아서, 모든 우리의 예제들은 not null foreign 키들을 사용한다. 이것은 Hibernate에서 필수가 아니고, 매핑들은 당신이 null 허용 가능 컨스트레인트들을 드롭시킬 경우에도 모두 동작할 것이다.

7.2. 단방향 연관들

7.2.1. many to one

단방향 many-to-one 연관은 가장 공통적인 종류의 단방향 연관이다.

<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>
create table Person ( personId bigint not null primary key, addressId bigint not null )
create table Address ( addressId bigint not null primary key )
        

7.2.2. one to one

foreign 키에 대한 단방향 one-to-one 연관은 대개 아주 동일하이다. 유일한 차이점은 컬럼이 유일(unique) 컨스트레인트라는 점이다. 

<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>
create table Person ( personId bigint not null primary key, addressId bigint not null unique )
create table Address ( addressId bigint not null primary key )
        

프라이머리 키에 대한 단방향 one-to-one 연관은 대개 특별한 id generator를 사용한다. (이 예제에서 연관의 방향이 역전되었음을 주목하라.)

<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>
create table Person ( personId bigint not null primary key )
create table Address ( personId bigint not null primary key )
        

7.2.3. one to many

foreign 에 대한 단방향 one-to-many 연관은 매우 통상적인 경우이고, 실제로 권장되지 않는다.

<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>
create table Person ( personId bigint not null primary key )
create table Address ( addressId bigint not null primary key, personId bigint not null )
        

우리는 이런 종류의 연관에 대해 join 테이블을 사용하는 것이 더 좋다고 생각한다.

7.3. join 테이블들에 대한 단방향 연관들

7.3.1. one to many

join 테이블에 대한 단방향 one-to-many 연관이 훨씬 더 선호된다. unique="true"를 지정함으로써 우리는 many-to-many에서 one-to-many로 multiplicity를 변경시켰음을 주목하라.

<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>
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 )
        

7.3.2. many to one

join 테이블에 대한 단방향 many-to-one 연관은 그 연관이 선택적일 때 매우 공통적이다.

<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>
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 )
        

7.3.3. one to one

join 테이블에 대한 단방향 one-to-one 연관은 극히 통상적이지 않지만 가능하다.

<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>
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 )
        

7.3.4. many to many

마지막으로, 우리는 단방향 many-to-many 연관을  갖는다.

<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>
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 )
        

7.4. 양방향 연관들

7.4.1. one to many / many to one

양방향 many-to-one 연관은 가장 공통된 종류의 연관이다.(이것은 표준 부모/자식 관계이다. )

<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>
create table Person ( personId bigint not null primary key, addressId bigint not null )
create table Address ( addressId bigint not null primary key )
        

7.4.2. one to one

foreign에 대한 양방향 one-to-one 연관은 꽤 공통적이다.

<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>
create table Person ( personId bigint not null primary key, addressId bigint not null unique )
create table Address ( addressId bigint not null primary key )
        

프라이머리 키에 대한 양방향 one-to-one 연관은 특별한 id generator를 사용한다.

<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>
create table Person ( personId bigint not null primary key )
create table Address ( personId bigint not null primary key )
        

7.5. join 테이블들에 대한 양방향 연관들

7.5.1. one to many / many to one

join 테이블에 대한 양방향 one-to-many 연관. Note that the inverse="true"는 연관의 어느 쪽 끝이든 콜렉션 측으로 또는 join 측으로 갈 수 있다. 

<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>
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 )
        

7.5.2. one to one

join 테이블에 대한 양방향 one-to-one 연관은 극히 통상적이지 않지만, 가능하다.

<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="address"
            column="personId" 
            not-null="true"
            unique="true"/>
    </join>
</class>
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 )
        

7.5.3. many to many

마지막으로, 우리는 양방향 many-to-many 연관을 갖는다.

<class name="Person">
    <id name="id" column="personId">
        <generator class="native"/>
    </id>
    <set name="addresses">
        <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">
        <key column="addressId"/>
        <many-to-many column="personId"
            class="Person"/>
    </set>
</class>
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 )
        

 

8장. Component 매핑

Hibernate에서 component 의 개념은 다른 용도로 몇몇 다른 컨텍스트들 내에서 재사용된다.

8.1. 종속 객체들

컴포넌트는 엔티티 참조가 아닌, value 타입으로서 영속화 되는 포함된 객체이다. "컴포넌트" 용어는 (아키텍처 수준의 컴포넌트들이 아닌) composition(구성, 조립,합성)에 대한 객체-지향적인 개념을 언급한다. 예를 들어 당신은 다음과 같이 개인을 모형화 시킬 수도 있다:

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;
    }
    ......
    ......
}
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;
    }
}

이제 NamePerson의 컴포넌트로서 영속화 될 수도 있다. Name 이 그것의 영속 프로퍼티들에 대한 getter 메소드와 setter 메소드를 정의하지만, 어떤 인터페이스들이나 identifier 프로퍼티들을 선언하는 것을 필요로 하지 않음을 주목하라. 

우리의 Hibernate 매핑은 다음과 같을 것이다:

<class name="eg.Person" table="person">
    <id name="Key" column="pid" type="string">
        <generator class="uuid.hex"/>
    </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>

person 테이블은 pid, birthday, initial, first, last 컬럼들을 가질 것이다.

모든 value 타입들처럼, 컴포넌트들은 공유된 참조들을 지원하지 않는다. 달리 말해, 두 명의 개인들은 동일한 이름을 가질 수 있지만, 두 개의 person 객체들은 오직 값 만이 "동일한", 두 개의 독립적인 name 객체들을 포함할 것이다. 컴포넌트의 null 값 의미는 특별한 용도를 위한 것이다. 포함된 객체를 다시 로드시킬 때, Hibernate는 모든 컴포넌트 컬럼들이 null일 경우에 전체 컴포넌트가 null이라고 가정할 것이다. 이것은 대부분의 용도로는 맞을 것이다.

컴포넌트의 프로퍼티들은 임의의 Hibernate 타입일 수 있다(콜렉션들, many-to-one 연관들, 다른 컴포넌트들, 기타). 내포된 컴포넌트들은 신종의 사용례로 간주되지 않을 것이다. Hibernate는 매우 잘 정제된 객체 모형을 지원하도록 고안되어있다.

<component> 요소는 컴포넌트 클래스의 프로퍼티는 포함되는 엔티티에 대한 참조로서 매핑시키는 <parent> 서브요소를 허용한다. 

<class name="eg.Person" table="person">
    <id name="Key" column="pid" type="string">
        <generator class="uuid.hex"/>
    </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>

8.2. 종속 객체들을 가진 콜렉션들

컴포넌트들을 가진 콜렉션들이 지원된다(예를 들면 Name 타입을 가진 배열). <element> 태그를 <composite-element> 태그로 바꾸어서 당신의 컴포넌트 콜렉션을 선언하라.

<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>

노트: 만일 당신이 composite 요소를 가진 Set를 정의할 경우, equals()hashCode()를 정확하게 구현하는 것이 매우 중요하다.

Composite 요소들은 컴포넌트들을 포함하지만 콜렉션들을 포함하지 않는다. 만일 당신의 composite 요소 자체가 컴포넌트들을 포함할 경우, <nested-composite-element> 태그를 사용하라. 이것은 꽤 신종의 경우-자체로 컴포넌트들을 갖고 있는 컴포넌트들을 가진 콜렉션-이다. 이 방도로 당신은 one-to-many 연관이 더 적절한지를 당신 스스로에게 질문하게 될 것이다. composite 요소를 다시 모델링하려고 시도하라 - 그러나 자바 모형들이 동일할지라도, 관계형 모형과 영속화 의미들은 여전히 약간 다르다.

당신이 <set>를 사용할 경우, composite 요소 매핑은 null 가능한 프로퍼티들을 지원하지 않음을 노트하길 바란다. Hibernate는 객체들을 삭제할 때 레코드를 식별하기 위해 각각의 컬럼들 값을 사용해야 하며, (composite 요소 테이블 내에 별도의 프라이머리 키 컬럼이 존재하지 않는다), 그것은 null 값들을 갖는 것이 불가능하다.  당신은 composite-요소 내에 오직 not-null 프로퍼티들을 해야 하거나 <list>, <map>, <bag> 또는 <idbag>을 선택해야 한다.

composite 요소의 특별하나 경우는 내포된 <many-to-one> 요소를 가진 composite 요소이다. 이같은 매핑은 many-to-many 연관 테이블의 특별한 컬럼들을 composite 요소 클래스로 매핑시키는 것을 당신에게 허용해준다. 다음은 Order로부터 Item으로의 many-to-many 연관이다. 여기서 purchaseDate, price, quantity 는 연관의 프로퍼티들이다:

<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 속성은 옵션이다 -->
        </composite-element>
    </set>
</class>

물론, 양방향 연관 네비게이션의 경우, 다른 측 상에 있는 purchase에 대한 참조가 참조가 존재할 수 없다. 컴포넌트들이 value 타입들이고 공유된 참조들을 허용하지 않음을 기억하라. 하나의 PurchaseOrder를 가진 set 내에 있을 수 있지만, 그것은 동시에 Item에 의해 참조될 수 없다.

심지어 세겹의(또는 네 겹의, 기타) 연관들이 가능하다:

<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>

composite 요소들은 다른 엔티티들에 대한 연관들과 동일한 구문을 사용하여 질의들 내에 나타날 수도 있다.

8.3. Map 인덱스들로서 컴포넌트들

<composite-map-key> 요소는 당신이 컴포넌트 클래스를 Map의 키로서 매핑시키도록 한다. 당신은 컴포넌트 클래스 상에서 hashCode()equals()를 정확하게 오버라이드 시키도록 하라.

8.4. composite 식별자들로서 컴포넌트들

당신은 컴포넌트를 엔티티 클래스의 식별자로서 사용할 수도 있다. 당신의 컴포넌트 클래스는 어떤 사양들을 충족해야 한다:

  • 그것은 java.io.Serializable을 구현해야 한다.
  • 그것은 composite 키 등가(equality)에 대한 데이터베이스 개념과 일치되게 equals()hashCode()를 다시 구현해야 한다.

노트: Hibernate3에서, 두 번째 사양은 Hibernate의 절대적으로 엄격한 사양이 아니다. 그러나 아무튼 그것을 행하라.

당신은 compsite 키들을 생성시키는데 IdentifierGenerator를 사용할 수 없다. 대신에 어플리케이션은 그것 자신의 식별자들을 할당해야 한다. 

통상의 <id> 선언 위치에 (내포된 <key-property> 요소들을 가진) <composite-id> 태그를 사용하라. 예를 들어, OrderLine 클래스는 Order의 (composite) 프라이머리 키에 의존하는 프라이머리 키를 갖는다.

<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>

이제 OrderLine 테이블을 참조하는 임의의 foreign 키들이 또한 compsite이다. 당신은 다른 클래스들에 대한 당신의 매핑 속에 이것을 선언해야 한다. OrderLine 에 대한 연관은 다음과 같이 매핑될 것이다:

<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>

(<column> 태그가 모든 곳에서 column 속성에 대한 대안임을 노트하라.)

OrderLine에 대한 many-to-many 연관은 또한 composite foreign 키를 사용한다: 

<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>

Order 에서 OrderLine들의 콜렉션이 사용될 것이다: 

<set name="orderLines" inverse="true">
    <key>
        <column name="orderId"/>
        <column name="customerId"/>
    </key>
    <one-to-many class="OrderLine"/>
</set>

(<one-to-many> 요소는 통상적으로 컬럼들을 선언하지 않는다.)

만일 OrderLine 자체가 하나의 콜렉션을 소유할 경우, 그것은 또한 하나의 composite foreign 키를 갖는다.

<class name="OrderLine">
    ....
    ....
    <list name="deliveryAttempts">
        <key>   <!-- 콜렉션은 composite 키 타입을 상속받는다 -->
            <column name="lineId"/>
            <column name="orderId"/>
            <column name="customerId"/>
        </key>
        <list-index column="attemptId" base="1"/>
        <composite-element class="DeliveryAttempt">
            ...
        </composite-element>
    </set>
</class>

8.5. 동적인 컴포넌트들

당신은 Map 타입의 프로퍼티를 매핑시킬 수도 있다:

<dynamic-component name="userAttributes">
    <property name="foo" column="FOO"/>
    <property name="bar" column="BAR"/>
    <many-to-one name="baz" class="Baz" column="BAZ_ID"/>
</dynamic-component>

<dynamic-component> 매핑의 의미는 <component>와 동일하다. 이런 종류의 매핑의 장점은 배치 시에 매핑 문서를 편집함으로써 그 bean의 실제 프로퍼티들을 결정하는 가용성이다. 매핑 문서에 대한 런타임 처리는 또한 DOM 파서를 사용하여 가능하다.  더 좋게는 당신이 Configuration  객체를 통해 Hibernate의 구성-시 메타모형에 액세스할 수 있다(그리고 그것을 변경시킬 수 있다)

 

9장. 상속 매핑

9.1. 세 개의 방도들

Hibernate는 세 개의 기본적인 상속 매핑 방도들을 지원한다:

    • table per class hierarchy
    • table per subclass
    • table per concrete class

게다가 Hibernate는 네 번째의 약간 다른 종류의 다형성을 지원한다:

implicit polymorphism(함축적인 다형성)

 

동일한 상속 계층구조의 다른 가지들에 대해 다른 매핑 방도들을 사용하는 것이 가능하고, 전체 계층 구조를 가로질러 다형성을 성취하는데 함축적인 다형성을 사용하라. 하지만 Hibernate는 동일한 루트 <class> 요소 하에서 <subclass>, 그리고 <joined-subclass> 그리고 <union-subclass> 매핑들을 혼합하는 것을 지원하지 않는다. 동일한 <class> 요소 하에서 <subclass> 요소와 <join> 요소를 결합시킴으로써 table per hierarchy 방도와 table per subclass 방도를 함께 혼합시키는 것이 가능하다(아래를 보라).

9.1.1. Table per class hierarchy

우리가 CreditCardPayment, CashPayment, ChequePayment 구현자들을 가진 인터페이스 Payment를 갖고 있다고 가정하자. table per hierarchy 매핑은 다음과 같을 것이다: 

<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>

정확히 하나의 테이블이 필요하다. 이 매핑 방도에는 다음의 하나의 큰 제약이 존재한다: CCTYPE과 같이 서브 클래스들에 의해 선언된 컬럼들은 NOT NULL 컨스트레인트들을 가질 수 없다.

9.1.2. Table per class subclass

table per subclass 매핑은 다음과 같을 것이다:

<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>

네 개의 테이블들이 필요하다. 세 개의 서브클래스 테이블들은 슈퍼클래스 테이블에 대한 프라이머리 키 연관들을 갖는다(따라서 그 관계형 모형은 실제로 one-to-one 연관이다).

9.1.3. discriminator를 사용하는 table per subclass

 table-per-subclass에 대한 Hibernate의 구현은 discriminator(판별자) 컬럼을 필요로 하지 않음을 노트하라.  다른 객체/관계형 매핑기들은 슈퍼클래스 테이블 속에 타입 discriminator 컬럼을 필요로 하는 table-per-subclass에 대한 다른 구현을 사용한다. Hibernate에 채택된 접근법은 구현하기가 훨씬 더 어렵지만 관계형 관점에서는 아마 틀림없이 보다 더 정확하다. 만일 당신이 table per subclass 방도를 대해 discriminator 컬럼을 사용하고 싶다면, 당신은 다음과 같이 <subclass><join>의 사용을 결합시킬 수도 있다:

<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">
        <join table="CASH_PAYMENT">
            ...
        </join>
    </subclass>
    <subclass name="ChequePayment" discriminator-value="CHEQUE">
        <join table="CHEQUE_PAYMENT" fetch="select">
            ...
        </join>
    </subclass>
</class>

선택적인 fetch="select" 선언은 슈퍼클래스를 질의할 때 outer join을 사용하여 ChequePayment 서브클래스 데이터를 페치시키지 않도록 Hibernate에게 알려준다.

9.1.4. table per class hierarchy와 table per subclass를 혼합하기

당신은 다음 접근법을 사용하여 table per hierarchy 방도와 table per subclass 방도를 혼합시킬 수 있다:

<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>

이들 매핑 방도들 중 어떤 것에 대해, 루트 Payment 클래스에 대한 다형성 연관은 <many-to-one>을 사용하여 매핑된다.

<many-to-one name="payment" column="PAYMENT_ID" class="Payment"/>

9.1.5. Table per concrete class

우리가 table per concrete class 방도 매핑에 대해 취할 수 있는 두 가지 방법들이 존재한다. 첫 번째는 <union-subclass>를 사용하는 것이다.

<class name="Payment">
    <id name="id" type="long" column="PAYMENT_ID">
        <generator class="native"/>
    </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>

세 개의 테이블들이 수반된다. 각각의 테이블은 상속된 프로퍼티들을 포함하여 그 클래스의 모든 프로퍼티들에 대한 컬럼들을 정의한다.

이 접근법의 제약은 만일 하나의 프로퍼티가 슈퍼클래스 상으로 매핑될 경우, 그 컬럼 이름은 모든 서브클래스 테이블들 상에서 같아야 한다는 점이다.(우리는 장래의 Hibernate 배포본에서 이 제약을 풀 수도 있다. )

9.1.6. Table per concrete class, using implicit polymorphism

대체적인 접근법은 함축적인 다형성을 사용하는 것이다:

<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>

아무데서도 우리가 명시적으로 Payment 인터페이스를 언급하지 않음을 주목하라. 또한 Payment의 프로퍼티들이 서브클래스들 각각에서 매핑된다는 점을 주목하라. 만일 당신이 중복을 피하고자 원한다면, XML 엔티티들을 사용하는 것을 고려하라(예를 들어 매핑에서 DOCTYPE 선언과 &allproperties; 에서 [ <!ENTITY allproperties SYSTEM "allproperties.xml"> ]).

이 접근법의 단점은 다형성 질의들을 수행할 때 Hibernate가 생성된 SQl UNION들을 생성시키는 않는다는 점이다.

이 매핑 방도의 경우, Payment에 대한 다형성 연관은 대개 <any>를 사용하여 매핑된다.

<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>

9.1.7. 함축적인 다형성을 다른 상속 매핑들과 혼합하기

이 매핑에 대해 주목하는 하나 이상의 것이 존재한다. 서브클래스들이 그것들 자신의 <class> 요소 내에 각각 매핑되므로(그리고 Payment 가 단지 인터페이스이므로), 서브클래스들 각각은 쉽게 또 다른 상속 계층구조의 부분일 수 있다! (그리고 당신은 Payment 인터페이스에 대해 여전히 다형성 질의들을 사용할 수 있다.)

<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>

다시 한번, 우리는 Payment를 명시적으로 언급하지 않는다. 만일 우리가 Payment 인터페이스에 대해 질의를 행할 경우-예를 들면. from Payment- , Hibernate는 CreditCardPayment (와 그것의 서브클래스들, 왜냐하면 그것들이 또한 Payment를 구현하므로), CashPayment 그리고 ChequePayment 인스턴스들을 자동적으로 반환할 것이지만 NonelectronicTransaction의 인스턴스들을 반환하지 않는다.

9.2. 제약들

table per concrete-class 매핑 방도에 대한 "함축적인 다형성" 접근법에는 어떤 제약들이 존재한다. <union-subclass> 매핑들에 대해서는 다소 덜 제약적인 제약들이 존재한다:

다음 표는 Hibernate에서 table per concrete-class 매핑들에 대한 제약들, 그리고 함축적인 다형성에 대한 제약들을 보여준다.

표 9.1. 상속 매핑들의 특징들

상속 방도 다형성
many-to-one
다형성
one-to-one
다형성
one-to-many
다형성
many-to-many
다형성
load()/get()
다형성
queries
다형성
joins
Outer join 페칭
table per class-hierarchy <many-to-one> <one-to-one> <one-to-many> <many-to-many> s.get(Payment.class, id) from Payment p from Order o join o.payment p 지원됨
table per subclass <many-to-one> <one-to-one> <one-to-many> <many-to-many> s.get(Payment.class, id) from Payment p from Order o join o.payment p 지원됨
table per concrete-class (union-subclass) <many-to-one> <one-to-one> <one-to-many> (inverse="true" 에 대해서만) <many-to-many> s.get(Payment.class, id) from Payment p from Order o join o.payment p 지원됨
table per concrete class (implicit polymorphism) <any> 지원되지 않음 지원되지 않음 <many-to-any> s.createCriteria(Payment.class).add( Restrictions.idEq(id) ).uniqueResult() from Payment p 지원되지 않음 지원되지 않음

제 10. 객체들로 작업하기

Hibernate는 기본 데이터베이스 관리 시스템의 상세로부터 개발자들을 은폐시켜줄 뿐만 아니라, 또한 객체들의 상태 관리를 제공하는 전체 객체/관계형 매핑 솔루션이다. 이것은 공통적인 JDBC/SQL 영속 계층들 내에서의 SQL statements에 대한 관리와는 반대로, 자바 어플리케이션들에서 영속에 관한 매우 고유한 객체-지향적 전망이다.

달리 말해, Hibernate 어플리케이션 개발자들은 항상 그들의 객체들의 상태에 대해 생각할 것이고, SQL 문장들의 실행에 대한 생각은 필수적이지 않다. 이 부분은 Hibernate에 의해 처리되고 어플리케이션 개발자가 시스템의 퍼포먼스를 튜닝할 때에만 관련된다.

10.1. Hibernate 객체 상태들

Hibernate는 다음 객체 상태들을 정의하고 지원한다:
  • Transient - 만일 객체가 오퍼레이터를 사용하여 방금 초기화 되었다면 객체는 transient이고, 그것은 Hibernate Session과 연관되어 있지 않다. 그것은 데이터베이스 내에서 영속 표상을 갖지 않고 식별자 값이 할당되지 않았다. 만일 어플리케이션이 더이상 참조를 갖지 않을 경우 transient 인스턴스들이 쓰레기 수집기에 의해 파괴돌 것이다. 객체를 영속화 시키는데(그리고 Hibernate로 하여금 이 전이(transition)에 대해 실행될 필요가 있는 SQL 문장들을 처리하도록 하는데) Hibernate Session을 사용하라.
  • Persistent - 영속 인스턴스는 데이터베이스 내에 표상을 갖고 식별자 값을 갖는다. 그것은 방금 저장되었지만, 정의상 그것은 Session의 범위 내에 있다. Hibernate는 영속 상태에서 객체에 대해 행해진 임의의 변경들을 검출해낼 것이고 단위 작업이 완료될 때 데이터베이스와 그 상태를 동기화 시킬 것이다. 개발자들은 객체가 transient가 되어야 할 때 UPDATE 문장들이나 DELETE 문장들을 수작업으로 실행하지 않는다.
  • Detached - detached 인스턴스는 영속화 되었지만, 그것의 Session이 닫혀진 객체이다. 물론 그 객체에 대한 참조는 여전히 유효하고 detached 인스턴스는 이 상태에서도 변경될 수도 있다. detached 인스턴스는 나중에 그것(과 모두 변경들)을 다시 영속화 시켜서새로운 Session에 다시첨부될 수 있다. 이 특징은 사용자가 생각할 시간을 필요로 하는 장 기간 실행되는 작업 단위에 대한 프로그래밍 모형을 가능하게 해준다. 우리는 그것들을 어플리케이션 트랜잭션들, 사용자의 관점의 작업 단위로 부른다.

이제 우리는 상태들과 상태 전이(transition)들(그리고 전이를 트리거 시키는 Hibernate 메소드들)을 상세하게 논의할 것이다.

10.2. 객체들을 영속화 시키기

영속 클래스의 새로이 생성된 인스턴스들은 Hibernate에 의해 transient 로 간주된다.  우리는 그것을 세션과 연관지어서 transient 인스턴스를 영속화 시킬 수 있다: 

DomesticCat fritz = new DomesticCat();
fritz.setColor(Color.GINGER);
fritz.setSex('M');
fritz.setName("Fritz");
Long generatedId = (Long) sess.save(fritz);

Cat 가 생성된 식별자를 가질 경우, save()가 호출될 때 그 식별자가 생성되고 cat에 할당된다. 만일 Catassigned 식별자나 composite key를 가질 경우, save()를 호출하기 전에 그 식별자는 cat 인스턴스에 할당될 것이다. 당신은 또한  EJB3 초기 드래프트에서 정의된 의미로 save() 대신 persist()를 사용할 수도 있다.

다른 방법으로, 당신은 save()의 오버로드된 버전을 사용하여 식별자를 할당할 수 있다.

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) );

만일 당신이 영속화 시키는 객체가 객체들(예를 들면. 앞의 예제에 있는 kittens 콜렉션)을 연관시켰다면, 이들 객체들은 당신이 foreign 키 컬럼에 대해 NOT NULL 컨스트레인트를 갖지 않는 한, 당신이 좋아하는 임의의 순서로 영속화 되었을 수도 있다. foreign 키 컨스트레인트들을 위배하는 위험성이 결코 존재하지 않는다. 하지만 당신이 잘못된 순서로 객체들을 save()할 경우 당신은 NOT NULL 컨스트레인트를 위배할 수도 있다.

당신이 연관된 객체들을 자동적으로 저장시키는데 Hibernate의 transitive persistence(과도적인 영속) 특징을 사용하는 것을 매우 좋아할 것이므로 대개 당신은 이 상세를 내버려둔다. 그때 NOT NULL 컨스트레인트 위배들이 발생되지 않을지라도 - Hibernate는 모든 것을 처리할 것이다.  Transitive persistence(과도적인 영속)은 이 장에서 나중에 논의된다. 

10.3. 객체를 로드시키기

Sessionload() 메소드들은 만일 당신이 그것(영속 인스턴스)의 식별자들을 이미 알고 있을 경우에 당신에게 영속 인스턴스를 검색하는 방법을 제공한다.  load()는 클래스 객체를 취하고 그 클래스의 새로이 초기화 된 인스턴스 속으로 그 상태를 영속 상태로 로드시킬 것이다.

Cat fritz = (Cat) sess.load(Cat.class, generatedId);
// 당신은 primitive 식별자들을 포장할 필요가 있다
long pkId = 1234;
DomesticCat pk = (DomesticCat) sess.load( Cat.class, new Long(pkId) );

다른 방법으로 당신은 주어진 인스턴스 속으로 상태를 로드시킬 수 있다:

Cat cat = new DomesticCat();
// pk의 상태를 cat 속으로 로드시킨다
sess.load( cat, new Long(pkId) );
Set kittens = cat.getKittens();

만일 일치하는 데이터베이스 행이 존재하지 않을 경우에 load()가 unrecoverable 예외상황을 던질 것임을 노트하라. 만일 클래스가 프락시를 갖도록 매핑된 경우, load()는 초기화 되지 않은 프락시를 반환하고 당신이 그 프락시의 메소드를 호출하기 전까지는 실제로 데이터베이스에 접속하지 않는다. 당신이 데이터베이스로부터 객체에 대한 연관을 실제로 로드시키지 않고서 객체에 대한 연관을 생성시키고자 원할 경우에 이 특징이 매우 유용하다. 만일 batch-size 가 클래스 매핑에 정의되는 경우 그것은 또한 다중 인스턴스들이 배치로서 로드되는 것을 허용해준다.

만일 당신이 일치하는 행이 존재하는지를 확신할 수 없을 경우, 당신은  get() 메소드를 사용해야 한다. 그것(get() 메소드)은 데이터베이스에 즉시 접속하고 만일 일치하는 행이 없을 경우 null을 반환한다.

Cat cat = (Cat) sess.get(Cat.class, id);
if (cat==null) {
    cat = new Cat();
    sess.save(cat, id);
}
return cat;

당신은 LockMode를 사용하는 SQL SELECT ... FOR UPDATE를 사용하여 객체를 로드시킬 수도 있다. 추가 정보는 API 문서를 보라.

Cat cat = (Cat) sess.get(Cat.class, id, LockMode.UPGRADE);

어떤 연관된 인스턴스들이나 포함된 콜렉션들은 당신이 그 연관에 대한 케스케이드 스타일로서 lock  또는 all을 지정하도록 결정하지 않는 한 FOR UPDATE를 select 하지 않음을 노트하라.

refresh() 메소드를 사용하여 아무때나 객체와 모든 그것의 콜렉션들을 다시 로드시키는 것이 가능하다. 데이터베이스 트리거들이 그 객체의 프로퍼티들 중 어떤 것을 초기화 시키는데 사용될 때 이것이 유용하다.

sess.save(cat);
sess.flush(); // SQL INSERT를 강제시킨다
sess.refresh(cat); // (트리거가 실행된 후에) 상태를 다시 읽어들인다

중요한 질문이 대개 이 지점에서 나타난다: Hibernate는 데이터베이로부터 얼마나 많이 로드시키고 그것은 얼마나 많은 SQL SELECT들을 사용할 것인가? 이것은 페칭 방도에 의존하고 19.1 절, “페칭 방도들”에 설명되어 있다.

10.4. 질의하기

만일 당신이 당신이 찾고 있는 객체들의 식별자들을 모를 경우, 당신은 질의를 필요로 한다. Hibernate는 사용이 쉽지만 강력한 객체 지향 질의 언어(HQL)를 지원한다. 프로그램 상의 질의 생성을 위해, Hibernate는 정교한 Criteria 및 Example 질의 특징(QBC와 QBE)를 지원한다. 당신은 또한 Hibernate로부터 객체들 속으로 결과 셋 변환을 위한 선택적인 지원으로, 당신의 데이터베이스의 native SQL 속에 당신의 질의를 표현할 수도 있다.

10.4.1. 질의들을 실행하기

HQL 질의와 native SQL 질의는 org.hibernate.Query의 인스턴스로 표현된다. 이 인터페이스는 파라미터 바인딩, 결과셋 핸들링, 그리고 실제 질의의 실행을 위한 메소드들을 제공한다. 당신은 현재의 Session을 사용하여 항상 Query를 얻는다:

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();

질의는 대개 list()를 호출하여 실행되고, 질의의 결과는 메모리 내에서 콜렉션 속으로 전체적으로 로드될 것이다. 질의에 의해 검색된 엔티티 인스턴스들은 영속 상태에 있다. 당신의 질의가 하나의 객체를 오직 반환할 것임을 당신이 알고 있을 경우에 uniqueResult() 메소드는 단축을 제공한다.

10.4.1.1. 결과들을 반복하기

종종, 당신은 iterate() 메소드를 사용하여 질의를 실행하여 더 나은 퍼포먼스를 성취하는 것이 가능할 수 있다. 이것은 오직 대개 질의에 의해 반환되는 실제 엔티티 인스턴스들이 이미 세션 내에 있거나 second-level 캐시 내에 있을 것임을 당신이 예상하는 경우일 것이다. 만일 그것들이 이미 캐시되지 않았다면, iterate()list() 보다 더 느릴 것이고 간단한 질의에 대해 많은 데이터베이스 접속들을, 대개 오직 식별자들을 반환하는 초기 select에 대해 1번의 접속과 실제 인스턴스들을 초기화 시키는 추가적인 select들에 대해 n 번의 접속을 필요로 할 수 있다.

// id들을 페치시킨다
Iterator iter = sess.createQuery("from eg.Qux q order by q.likeliness").iterate();
while ( iter.hasNext() ) {
    Qux qux = (Qux) iter.next();  // 객체들을 페치시킨다 
    // 질의 속에 우리가 표현할 수 없는 어떤 것
    if ( qux.calculateComplicatedAlgorithm() ) {
        // 현재 인스턴스를 삭제시킨다 
        iter.remove();
        // 나머지를 처리할 필요가 없다
        break;
    }
}

10.4.1.2. 튜플들을 반환하는 질의들

Hibernate 질의들은 때때로 객체들의 튜플들을 반환하고, 그 경우에 각각의 튜플은 배열로서 반환된다:

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  = tuple[0];
    Cat mother  = tuple[1];
    ....
}

10.4.1.3. 스칼라 결과들

질의들은 select  절 내에 클래스의 프로퍼티를 지정할 수 있다. 그것들은 심지어 SQL 집계 함수들을 호출할 수도 있다. 프로퍼티들이나 aggregate들은 (영속 상태에 있는 엔티티들이 아닌) "스칼라" 결과들로 간주된다. 

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 = results.next();
    Color type = (Color) row[0];
    Date oldest = (Date) row[1];
    Integer count = (Integer) row[2];
    .....
}

10.4.1.4. 바인드 프라미터들

Query 상의 메소드들은 명명된 파라미터들 또는 JDBC-스타일의 ? 파라미터들에 바인딩 값들을 제공한다. JDBC와는 대조적으로, Hibernate 숫자 파라미터들은 0에서 시작된다. 명명된 파라미터들은 질의 문자열 속에서 :name 형식의 식별자들이다. 명명된 파라미터들의 장점들은 다음과 같다:

  • 명명된 파라미터들은 그것들이 질의 문자열 내에 발생하는 순서에 관계없다
  • 그것들은 동일한 질의 내에서 여러 번 발생할 수 있다
  • 그것은 자기-설명적이다
//명명된 파라미터 (선호됨)
Query q = sess.createQuery("from DomesticCat cat where cat.name = :name");
q.setString("name", "Fritz");
Iterator cats = q.iterate();
//위치 파라미터 
Query q = sess.createQuery("from DomesticCat cat where cat.name = ?");
q.setString(0, "Izi");
Iterator cats = q.iterate();
//명명된 파라미터 리스트
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();

10.4.1.5. 쪽매김

만일 당신이 당신의 결과 셋에 경계(당신이 검색하고자 원하는 최대 개수 와/또는 당신이 검색하고자 원하는 첫 번째 행)를 지정할 필요가 있다면 당신은 Query 인터페이스의 메소드들을 사용해야 한다:

Query q = sess.createQuery("from DomesticCat cat");
q.setFirstResult(20);
q.setMaxResults(10);
List cats = q.list();

Hibernate는 이 limit 질의를 당신의 DBMS의 native SQL로 번역하는 방법을 알고 있다.

10.4.1.6. 스크롤 가능한 iteration

당신의 JDBC 드라이버가  스크롤 가능한 ResultSet들을 지원할 경우, Query 인터페이스는 ScrollableResults 객체를 얻는데 사용될 수 있고, 그것은 질의 결과들에 대한 유연한 네비게이션을 허용해준다.

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()

열려진 데이터베이스 커넥션(과 커서)가 이 기능에 필요함을 노트하고, 만일 당신이 쪽매김 기능을 작동시킬 필요가 있다면 setMaxResult()/setFirstResult()를 사용하라.

10.4.1.7. 명명된 질의들을 구체화 시키기

당신은 또한 매핑 문서 속에 명명된 질의들을 정의할 수 있다.(만일 당신의 질의가 마크업으로서 해석될 수 있는 문자들을 포함할 경우에 CDATA 섹션을 사용하는 것을 기억하라)

<query name="eg.DomesticCat.by.name.and.minimum.weight"><![CDATA[
    from eg.DomesticCat as cat
        where cat.name = ?
        and cat.weight > ?
] ]></query>

파라미터 바인딩과 실행은 프로그램 상으로 행해진다:

Query q = sess.getNamedQuery("eg.DomesticCat.by.name.and.minimum.weight");
q.setString(0, name);
q.setInt(1, minWeight);
List cats = q.list();

실제 프로그램 코드는 사용되는 질의 언어에 독리비적이고, 당신은 또한 메타데이터로 native SQL 질의들을 정의할 수도 있거나 그것들을 매핑 파일들 속에 위치지움으로써 기존 질의들을 Hibernate로 이전시킬 수도 있음을 노트하라.

10.4.2. 콜렉션들을 필터링 하기

콜렉션 필터는 영속 콜렉션 또는 배열에 적용될 수 있는 특별한 질의 타입이다. 질의 문자열은 현재의 콜렉션 요소를 의미하는 this를 참조할 수 있다.

Collection blackKittens = session.createFilter(
    pk.getKittens(), 
    "where this.color = ?")
    .setParameter( Color.BLACK, Hibernate.custom(ColorUserType.class) )
    .list()
);

반환되는 콜렉션은 하나의 bag으로 간주되고, 그것은 주어진 콜렉션에 대한 사본이다. 원래의 콜렉션은 변경되지 않는다(이것은 이름 "filter"의 의미와는 정반대이지만, 예상되는 행위와 일치된다).

필터들은 from 절을 필요로 하지 않음을 관찰하라(비록 그것들이 필요할 경우에 한개의 from 절을 가질 수 있을지라도). 필터들은 콜렉션 요소들 자체들을 반환하는 것으로 제약되지 않는다.

Collection blackKittenMates = session.createFilter(
    pk.getKittens(), 
    "select this.mate where this.color = eg.Color.BLACK.intValue")
    .list();

심지어 공백의 필터 질의도 예를 들어 거대한 콜렉션 내에 잇는 요소들의 부분집합들을 로드시키는데 유용하다:

Collection tenKittens = session.createFilter(
    mother.getKittens(), "")
    .setFirstResult(0).setMaxResults(10)
    .list();

10.4.3. Criteria 질의들

HQL은 극히 강력하지만 몇몇 개발자들은 질의 문자열들을 빌드하는 것 보다, 객체 지향 API를 사용하여 동적으로 질의들을 빌드시키는 것을 선호한다. Hibernate는 이들 경우들에 대해 직관적인 Criteria query API를 제공한다:

Criteria crit = session.createCriteria(Cat.class);
crit.add( Expression.eq( "color", eg.Color.BLACK ) );
crit.setMaxResults(10);
List cats = crit.list();

Criteria 와 연관된 Example API 는 15장, Criteria 질의들에서 상세하게 논의된다.

10.4.4. native SQL에서 질의들

당신은 createSQLQuery() 를 사용하여 SQL로 질의를 표현할 수 있고, Hibernate로 하여금 객체들에 대한 결과 셋들로부터 매핑을 처리하도록 한다. 당신은 아무때나 session.connection()을 호출할 수 있고 직접 JDBC Connection을 사용할 수 있음을 노트하라. 만일 당신이 Hibernate API를 사용하고자 선택한 경우에 , 당신은 SQL alias들을 중괄호들 속에 포함시켜야 한다:

List cats = session.createSQLQuery(
    "SELECT {cat.*} FROM CAT {cat} WHERE ROWNUM<10",
    "cat",
    Cat.class
).list();
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",
    "cat",
    Cat.class
).list()

SQL 질의들은 Hibernate 질의들처럼 명명된 파라미터들과 위치 파라미터들을 포함할 수도 있다.  SQL 질의들에 대한 추가 정보는 16 장, Native SQL에서 찾을 수 있다.

10.5. 영속 객체들을 변경하기

트랜잭션 상의 영속 인스턴스들 (예를들면. Session에 의해 로드되고, 저장되고, 생성되거나 질의된 객체들)은 어플리케이션에 의해 처리될 수 있고 영속 상태에 대한 임의의 변경들은 Sessionflush될 때 영속화 될 것이다. (이 장의 뒷 부분에서 논의됨). 당신의 변경들을 영속화 시키기 위해 (다른 용도를 가진 update()와 같은) 특별한 메소드를 호출할 필요가 없다. 따라서 객체의 상태를 업데이트 시키는 대부분의 간단한 방법은 Session이 열려 있는 동안, 그것을 load()시키고 나서, 그것을 직접 처리하는 것이다: 

DomesticCat cat = (DomesticCat) sess.load( Cat.class, new Long(69) );
cat.setName("PK");
sess.flush();  // changes to cat are automatically detected and persisted

때때로 프로그래밍 모형은 불충분하다. 왜냐하면 그것은 동일한 세션 내에서 (객체를 로드시키는) SQL SELECT와 (그것의 업데이트된 사아태를 영속화 시키는) SQL UPDATE 양자를 필요로 할 것이기 때문이다. 그러므로 Hibernate는 detached 인스턴스들을 사용하는 대안적인 접근법을 제공한다. 

Hibernate는 UPDATE 문장 또는 DELETE 문장의 직접적인 실행을 위한 그것 자신의 API를 제공하지 않음을 노트하라. Hibernate는 상태 관리 서비스이고, 당신은 그것을 사용할 문장들을 생각하지 말아야 한다. JDBC는 SQL 문장들을 실행시키는 완전한 API이고, 당신은 session.connection()을 호출함으로써 아무때나 JDBC Connection을 얻을 수 있다.  게다가 대규모 오퍼레이션의 개념은 온라인 트랜잭션 처리-지향적인 어플리케이션들을 위한 객체/관계형 매핑과 충돌한다. 하지만 Hibernate의 장래 버전들은 특별한 대규모의 오퍼레이션 함수들을을 제공할 수도 있다. 몇몇 가능한 배치 오퍼레이션 트릭들에 대해서는 13장, 배치 프로세싱을 보라. 

10.6. detached 객체들을 변경시키기

많은 어플리케이션들은 하나의 트랜잭션 내에서 객체를 검색하고, 처리를 위한 UI 계층으로 그것을 전송하고, 새로운 트랜잭션 내에서 변경들을 저장할 필요가 있다. 높은-동시성 환경에서 이런 종류의 접근법을 사용하는 어플리케이션들은 대개 작업의 "긴" 단위를 확실히 격리시키기 위해 버전화 된 데이터를 사용한다.

Hibernate는 Session.update() 메소드 또는 Session.merge() 메소드를 사용하여 detached 객체들의 재첨부를 제공함으로써 이 모형을 지원한다:

// 첫 번째 세션에서 
Cat cat = (Cat) firstSession.load(Cat.class, catId);
Cat potentialMate = new Cat();
firstSession.save(potentialMate);

// 어플리케이션의 더 높은 계층에서 
cat.setMate(potentialMate);

// 나중에 새로운 세션에서
secondSession.update(cat);  // cat을 업데이트 한다
secondSession.update(mate); // mate를 업데이트 한다

만일 catId 식별자를 가진 CatsecondSession에 의해 이미 로드되었을 경우에 어플리케이션이 그것을 다시 재첨부하려고 시도할 때, 예외상황이 던져졌을 것이다.

만일 그 세션이 동일한 식별자를 가진 영속 인스턴스를 이미 포함하지 않음을 당신이 확신하고 있다면 update()를 사용하고, 만일 당신이 세션의 상태를 고려하지 않은채로 아무때나 당신의 변경을 병합시키고자 원할 경우에 merge()를 사용하라. 달리 말해, update()는 당신의 detached 인스턴스들에 대한 재첨부가 실행되는 첫 번째 오퍼레이션임을 확실히 함으로써, 대개 갓 만들어진 세션에서 당신이 호출하게 될 첫 번째 메소드이다.

어플리케이션은 그것이 detached 인스턴스들의 상태가 또한 업데이트 되는 것을 원할 경우에  주어진 detached 인스턴스로부터 도달 가능한 detached 인스턴스들을 개별적으로 update() 시킬 것이다. 이것은 물론 transitive persistence(과도적인 영속)을 사용하여 자동화 될 수 있고, see 10.11절, “Transitive persistence”를 보라.

lock() 메소드는 또한 새로운 세션에 대해 객체를 다시 연관시키는것을 어플리케이션에게 허용해준다. 하지만 detached 인스턴스는 변경되지 않아야 한다!

//단지 다시 연관지운다:
sess.lock(fritz, LockMode.NONE);
//버전 체크를 행하고 나서 다시 연관 짓는다: 
sess.lock(izi, LockMode.READ);
//SELECT ... FOR UPDATE를 사용하여 버전 체크를 행하고 나서 다시 연관 짓는다:
sess.lock(pk, LockMode.UPGRADE);

lock() 이 여러가지 LockMode들에 사용될 수 있음을 노트하고, 상세한 것은 API 문서와 트랜잭션 처리에 관한 장을 보라. 재첨부는 lock()에 대한 유일한 쓰임새는 아니다. 

긴 작업 단위에 대한 다른 모형들은 11.3절, “Optimistic 동시성 제어”에서 논의된다.

10.7. 자동적인 상태 검출

Hibernate 사용자들은 새로운 식별자를 생성시킴으로써 transient 인스턴스를 저장하는 또는 그것의 현재 식별자와 연관된 detached 인스턴스들을 업데이트/재첨부 시키는 일반적인 용도의 메소드를 요청했다. saveOrUpdate() 메소드는 이 기능을 구현한다.

// 첫 번째 세션에서 
Cat cat = (Cat) firstSession.load(Cat.class, catID);

// 어플리케이션의 더 높은 티어에서 
Cat mate = new Cat();
cat.setMate(mate);

// 나중에 새로운 세션에서 
secondSession.saveOrUpdate(cat);   // 기존 상태를 업데이트 한다  (cat은 non-null id를 갖는다)
secondSession.saveOrUpdate(mate);  // 새로운 인스턴스를 지정한다 (mate는 null id를 갖는다)

saveOrUpdate()의 사용 예제와 의미는 초심자들에게는 혼동스러워 보인다. 먼저, 하나의 세션으로부터의 인스턴스를 또 다른 새로운 세션 내에 사용하려고 시도하지 않는 한, 당신은 update(), saveOrUpdate(), 또는 merge()를 사용할 필요는 없을 것이다. 몇몇 전체 어플리케이션들은 이들 메소드들 중 어느 것도 결코 사용하지 않을 것이다. 

대개 update() 또는 saveOrUpdate() 는 다음 시나리오에서 사용된다:

  • 어플리케이션은 첫 번째 세션 내에 객체를 로드시킨다
  • 그 객체는 UI 티어로 전달된다 
  • 몇몇 변경들이 그 객체에 행해진다
  • 그 객체는 비지니스 로직 티어로 전달된다
  • 어플리케이션은 두 번째 세션에서 update()를 호출함으로써 이들 변경들을 영속화 시킨다

saveOrUpdate() 는 다음을 행한다:

  • 만일 객체가 이 세션 내에서 이미 영속화 되어 있을 경우, 아무것도 행하지 않는다
  • 만일 그 세션과 연관된 또 다른 객체가 동일한 식별자를 가질 경우, 예외상황을 던진다 
  • 만일 그 객체가 식별자 프로퍼티를 갖지 않을 경우, 그것을 save() 시킨다
  • 만일 객체의 식별자가 새로이 초기화 된 객체에 할당된 값을 가질 경우, 그것을 save() 시킨다
  • 만일 객체가 (<version> 또는 <timestamp>에 의해 ) 버전화 되고, version 프로퍼티 값이 새로이 초기화 된 객체에 할당된 것과 동일한 값일 경우, 그것을 save() 시킨다
  • 그 밖의 경우 그 객체를 update() 시킨다

그리고 merge() 는 매우 다르다:

  • 만일 세션과 현재 연관된 동일한 식별자를 가진 영속 인스턴스가 존재할 경우, 주어진 객체의 상태를 영속 인스턴스 상으로 복사한다
  • 만일 세션과 현재 연관된 영속 인스턴스가 존재하지 않을 경우, 데이터베이스로부터 그것을 로드시키려고 시도하거나 새로운 영속 인스턴스를 생성시키려고 시도한다
  • 영속 인스턴스가 반환된다
  • 주어진 인스턴스는 세션과 연관되지 않고, 그것은 detached 상태에 머무른다.

10.8. 영속 객체들을 삭제하기

Session.delete()는 데이터베이스로부터 객체의 상태를 제거할 것이다. 물론 당신의 어플리케이션은 여전히 detached 객체에 대한 참조를 보관할 것이다. 영속 인스턴스를 transient로 만드는 것으로서 delete()를 생각하는 것이 최상이다.

sess.delete(cat);

당신은 foreign 키 컨스트레인트 위반들의 위험성 없이 당신이 좋아하는 어떤 순서로 객체들을 삭제할 수도 있다. 잘못된 순서로 객체들을 삭제함으로써 컨스트레인트를 위배할 가능성이 여전히 있다. 예를 들어, 당신이 부모를 삭제하지만 그 자식들을 삭제하는 것을 잊은 경우.

10.9. 두 개의 다른 데이터저장소들 사이에 객체들을 복제하기

영속 인스턴스들의 그래프를 취하고 식별자 값들을 다시 생성시키지 않고서 그것들을 다른 저장소 속에 영속화 시키는 것이 가능한 것은 종종 유용하다.

// 하나의 데이터베이스로부터 cat을 검색한다 
Session session1 = factory1.openSession();
Transaction tx1 = session1.beginTransaction();
Cat cat = session1.get(Cat.class, catId);
tx1.commit();
session1.close();

// 두 번째 데이터베이스와 일치시킨다
Session session2 = factory2.openSession();
Transaction tx2 = session2.beginTransaction();
session2.replicate(cat, ReplicationMode.LATEST_VERSION);
tx2.commit();
session2.close();

ReplicationModereplicate()가 데이터베이스 내에 있는 기존의 행들과의 충돌을 어떻게 처리할 것인지를 결정한다. 

  • ReplicationMode.IGNORE - 동일한 식별자를 가진 기존 데이터베이스 행이 존재할 경우에 그 객체를 무시한다
  • ReplicationMode.OVERWRITE - 동일한 식별자를 가진 어떤 기존의 데이터베이스 행을 덮어 쓴다
  • ReplicationMode.EXCEPTION - 만일 동일한 식별자를 가진 기존 데이터베이스 행이 존재할 경우에 예외상황을 던진다
  • ReplicationMode.LATEST_VERSION - 행의 버전 번호가 객체의 버전 번호 보다 이전의 것이면 덮어쓰고, 그 밖의 경우에 그 객체를 무시한다

이 특징의 쓰임새들은 다른 데이터베이스 인스턴스들 속으로 입력된 데이터 일치시키기, 제품 업그레이드 동안에 시스템 구성 정보 업데이트 하기, non-ACID 트랜잭션들 동안에 행해진 변경들을 롤백시키기 등을 포함한다.

10.10. Session을 flush 시키기

시간에 따라 Session 은 JDBC 커넥션의 상태와 메모리 내에 보관된 객체들의 상태를 동기화 시키는데 필요한 SQL 문장들을 실행시킬 것이다. 이 프로세스 flush 는 다음 시점들에서 디폴트로 발생한다

  • 몇몇 질의가 실행되기 전에
  • org.hibernate.Transaction.commit() 에서
  • Session.flush() 에서

SQL 문장들은 다음 순서로 실행 명령이 내려진다

  1. 대응하는 객체들이 Session.save()를 사용하여 저장되었던 것과 같은 순서로, 모든 엔티티가 insert 된다
  2. 모든 엔티티가 업데이트 된다
  3. 모든 콜렉션이 삭제된다
  4. 모든 콜렉션 요소가 삭제되고, 업데이트 되고, 그리고 insert 된다
  5. 모든 콜렉션이 insert 된다
  6. 대응하는 객체들이 Session.delete()를 사용하여 삭제되었던 것과 같은 순서로, 모든 엔티티가 삭제된다

(예외는 객체들이 저장될 때 native ID 생성을 사용하는 객체들이 insert 되는 것이다.)

당신이 명시적으로 flush() 시킬 때를 제외하면,  Session 이 JDBC 호출들을 실행할 그것들이 실행되는 순서만을 절대적으로 보장하지는 않는다. 하지만 Hibernate는 Query.list(..)가 실효성이 없는 데이터를 결코 반환하지 않을 것이거나; 그것들이 잘못된 데이터도 반환하지 않을 것임을 보장한다.

flush가 너무 자주 발생하지 않도록 디폴트 행위를 변경하는 것이 가능하다. FlushMode 클래스는 세 개의 다른 모드들을 정의한다: 커밋 시에(그리고 Hibernate Transaction API가 사용될 때에만) 유일한 flush 모드, 설명된 루틴을 사용하는 자동적인 flush 모드, 또는 flush()가 명시적으로 호출되지 않는 한 결과 flush 시키지 않는 모드. 마지막 모드는 오래 동안 실행되는 작업 단위에 대해 유용하고, 여기서 Session은 열려진채로 유지되고 오랜 시간 동안 연결이 해제된 채로 유지된다. (11.3.2절, “긴 세션과 자동적인 버전화”를 보라).

sess = sf.openSession();
Transaction tx = sess.beginTransaction();
sess.setFlushMode(FlushMode.COMMIT); // 질의들이 실효성 없는 상태를 반환하는 것을 허용한다

Cat izi = (Cat) sess.load(Cat.class, id);
izi.setName(iznizi);

// 실효성 없는 데이터를 반환할 수도 있다 
sess.find("from Cat as cat left outer join cat.kittens kitten");

// izi에 대한 변경은 flush 되지 않는다!
...
tx.commit(); // flush가 발생한다

flush 동안에, 예외상황이 발생할 수도 있다(예를 들면. 만일 DML 오퍼레이션이 컨스트레인트를 위반할 경우). 예외상황 처리는 Hibernatem의 트랜잭션 특징에 관한 어떤 이해를 수반하며, 우리는 11장, 트랜잭션들과 동시성에서 논의한다.

10.11. Transitive persistence

특히 당신이 연관된 객체들의 그래프를 다룰 경우에, 개별 객체들을 저장하고, 삭제하거나, 재첨부시키는 것이 꽤 귀찮다. 공통된 경우는 부모/자식 관계이다. 다음 예제를 검토하자: 

만일 부모/자식 관계 속에 있는 자식들이 value 타입일 경우(예를 들면. 주소들 또는 문자열들을 가진 콜렉션), 그것들의 생명주기는 부모에 의존할 것이고 더 이상의 액션은 상태 변경들에 대해 편리한 "케스케이딩"에 필요하지 않을 것이다. 만일 부모가 저장될 때, value-타입의 자식 객체들도 마찬가지로 저장되고, 부모가 삭제될 때, 자식이 삭제될 것이다. 이것은 심지어 콜렉션으로부터 하나의 자식을 제거하는 것과 같은 오퍼레이션들에 대해서도 동작한다; Hibernate는 이것을 검출하고, value-타입의 객체들이 참조를 공유할 수 없으므로, 데이터베이스로부터 그 자식을 삭제시킨다.

이제 value 타입이 아닌 엔티티들인 부모와 자식 객체들을 가진 동일한 시나리오를 검토하자(예를 들면. 카테고리들과 아이템들, 또는 부모 고양이나 자식 고양이). 엔티티들은 그것들 자신의 생명주기를 갖고, 공유된 참조들을 지원하고(따라서 콜렉션으로부터 엔티티를 제거하는 것은 그것이 삭제될 수 있음을 의미하지 않는다), 그리고 디폴트로 하나의 엔티티로부터 어떤 다른 연관된 엔티티들로의 상태의 케스케이딩이 존재하지 않는다. Hibernate는 디폴트로 도달가능성에 의한 영속성(persistence by reachability)을 구현하지 않는다. 

 - persist(), merge(), saveOrUpdate(), delete(), lock(), refresh(), evict(), replicate()를 포함하는- Hibernate 세션에 대한 각각의 기본 오퍼레이션에 대해 대응하는 케스케이딩 스타일이 존재한다. 케스케이드 스타일들 각각은 create, merge, save-update, delete, lock, refresh, evict, replicate로 명명된다.  만일 당신이 오퍼레이션이 하나의 연관에 따라 케스케이딩되는 것을 원할 경우, 당신은 매핑 문서 내에 그것을 지시해야 한다. 예를 들면:

<one-to-one name="person" cascade="create"/>

케스케이딩 스타일들은 결합될 수도 있다:

<one-to-one name="person" cascade="create,delete,lock"/>

당신은 모든 오퍼레이션들이 그 연관에 따라 케스케이드되어야 함을 지정하는데 cascade="all"을 사용할 수도 있다. 디폴트 cascade="none" 은 오퍼레이션들이 케스케이드 되지 않을 것임을 지정한다.

특정한 케스케이드 스타일, delete-orphan은 오직 one-to-many 연관들에만 적용되고, delete() 오퍼레이션이 그 연관으로부터 제거되는 임의의 자식에게 적용되어야 함을 나타낸다.

권장사항들:

  • <many-to-one> 또는 <many-to-many> 연관에 대해 케스케이드를 가능하게 하는 것은 의미가 없다. 케스케이드는 <one-to-one> 연관과 <one-to-many> 연관에 대해 자주 유용하다.
  • 만일 자식 객체들의 수명이 그 부모 객체의 수명에 의해 한정될 경우, cascade="all,delete-orphan"을 지정함으로써 그것을 생명 주기 객체로 만들어라.
  • 그 밖의 경우, 당신은 케스케이드를 전혀 필요로 하지 않는다. 그러나 만일 당신이 동일한 트랜잭션 내에서 부모와 자식에 대해 자주 함께 작업하게 될 것이라 생각되고, 당신 스스로 어떤 타이핑을 절약하고자 원할 경우, cascade="create,merge,save-update"를 사용하는 것을 고려하라. 

cascade="all"을 가진 연관을 매핑시키는 것(단일 값 연관이든 콜렉션이든)은 부모의 저장/업데이트/삭제가 자식 또는 자식들의 저장/업데이트/삭제로 귀결되는 부모/자식 스타일의 관계로 그 연관을 마크한다.

게다가, 영속 부모로부터 자식에 대한 단순한 참조는 자식의 저장/업데이트로 귀결될 것이다. 하지만 이 메타포는 불완전하다. 그것의 부모에 의해 참조되지 않는 자식은 cascade="delete-orphan"로 매핑된 <one-to-many> 연관의 경우를 제외하면, 자동적으로 삭제되지 않는다. 부모/자식 관계에 대한 케스케이딩 오퍼레이션의 정확한 의미는 다음과 같다:

  • 만일 부모가 persist()에 전달될 경우, 모든 자식들이 persist()에 전달된다.
  • 만일 부모가 merge()에 전달될 경우 모든 자식들이 merge()에 전달된다
  • 만일 부모가 save(), update() 또는 saveOrUpdate()에 전달될 경우 모든 자식들이 saveOrUpdate()에 전달된다
  • 만일 transient 또는 detached 자식이 영속 부모에 의해 참조될 경우, 그것은 saveOrUpdate()에 전달된다
  • 만일 부모가 삭제될 경우, 모든 자식들이 delete()에 전달된다
  • 만일 자식이 영속 부모에 의해 참조취소 될 경우, cascade="delete-orphan"이 아닌 한, 특별한 어떤 것도 발생하지 않는다 - 필요할 경우 어플리케이션은 자식을 명시적으로 삭제해야 한다 -, "orphaned(고아)"인 경우 자식이 삭제된다.

10.12. 메타데이터 사용하기

Hibernate는 모든 엔티티와 value 타입들을 가진 매우 풍부한 메타-레벨 모형을 필요로 한다. 시간에 따라, 이 모형은 어플리케이션 그 자체에 매우 유용하다. 예를 들어, 어플리케이션은 어느 객체들이 복사되어야 하는지(예를 들면 가변적인 value 타입들) 그리고 어느 것이 복사되지 말아야 하는지(예를 들면, 불변의 value 타입들과 가능한 연관된 엔티티들)를 인지하는 "스마트" deep-copy 알고리즘을 구현하는데 Hibernate의 메타데이터를 사용할 수도 있다.

Hibernate는 ClassMetadata 인터페이스와 CollectionMetadata 인터페이스 그리고  Type 계층구조를 통해 메타데이터를 노출시킨다. 메타데이터 인터페이스의 인스턴스들은 SessionFactory로부터 얻어질 수도 있다.

Cat fritz = ......;
ClassMetadata catMeta = sessionfactory.getClassMetadata(Cat.class);

Object[] propertyValues = catMeta.getPropertyValues(fritz);
String[] propertyNames = catMeta.getPropertyNames();
Type[] propertyTypes = catMeta.getPropertyTypes();

// 콜렉션들이나 연관들이 아닌 모든 프로퍼티들을 가진 하나의 Map을 얻는다
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] );
    }
}

 11 장. 트랜잭션들과 동시성

Hibernate와 동시성 제어에 대한 가장 중요한 점은 그것이 이해하기가 매우 쉽다는 점이다. Hibernate는 어떤 추가적인 잠금 행위 없이 JDBC 커넥션들과 JTA 리소스들을 직접 사용한다. 우리는 당신의 데이터베이스 관리 시스템의 JDBC, ANSI, 그리고 트랜잭션 격리 명세에 약간의 시간을 할애하는 것을 매우 권장한다. Hibernate는 오직 자동적인 버전화를 추가하지만 메모리 내에서 객체들을 잠그지 않거나 당신의 데이터베이스 트랜잭션의 격리 레벨을 변경시키지 않는다. 기본적으로, 당신이 당신의 데이터베이스 리소스들에 직접 JDBC(또는 JTA/CMT)를 사용하는 것처럼 Hibernate를 사용하라. 

하지만, 자동적인 버전화에 덧붙여, Hibernate는 또한 SELECT FOR UPDATE 구문을 사용하는, 행들에 대한 pessimistic 잠금을 위한 (마이너) API를 제공한다. 이 API는 이 장의 뒷 부분에서 논의된다.

우리는 Configuration, SessionFactory, Session 알갱이를 가진 Hibernate에서의 동시성 제어 뿐만 아니라 데이터베이스 트랜잭션과 긴 어플리케이션 트랜잭션에 대한 논의를 시작한다.

11.1. 세션 영역과 트랜잭션 영역

SessionFactory 는 모든 어플리케이션 쓰레드들에 의해 공유되도록 고안된 생성에 비용이 드는, 쓰레드안전(threadsafe) 객체이다. 그것은 대개 어플리케이션 시작 시에 Configuration 인스턴스로부터 한번 생성된다.

Session 은 단일 비지니스 프로세스, 하나의 작업 단위를 위해 한번만 사용되고 나서 폐기될 비용이 들지 않는, 쓰레드 안전하지 않은 객체이다. Session은 그것이 필요하지 않으면 JDBC Connection (또는 a Datasource)를 얻지 않을 것이어서, 당신이 특별한 요청을 제공할 필요가 있을 것이라고 확신하지 않을 경우에 당신은 Session을 안전하게 열고 닫을 수 있다. (이것은 당신이 요청 인터셉션을 사용하여 다음 패턴들 중 어떤 것을 구현하자 마자 중요하게 된다.)

이 그림을 완성하기 위해 당신은 또한 데이터베이스 트랜재션들에 대해 생각해야 한다. 데이터베이스 트랜잭션은 데이터베이스에서 잠금 투쟁을 줄이기 위해 가능한 짧아야 한다. 긴 데이터베이스 트랜잭션들은 당신의 어플리케이션이 고도의 동시성 로드를 높이는 것을 방지할 것이다. 

작업 단위의 영역은 무엇인가? 하나의 Hibernate Session은 몇몇 데이터베이스 트랜잭션들에 걸칠 수 있는가 또는 이것은 영역들의 one-to-one 관계인가?  당신은 언제 Session을 열고 닫는가 그리고 당신은 데이터베이스 트랜잭션 경계들을 어떻게 한정하는가?

11.1.1. 작업 단위

첫번째로, session-per-operation anti-패턴을 사용하지 말라. 즉, 단일 쓰레드 내에서 모든 간단한 데이터베이스 호출에 대해 Session을 열고 닫지 말라! 물론 동일한 것은 데이터베이스 트랜잭션들에 대해서도 참이다. 어플리케이션 내의 데이터베이스 호출들은 계획된 순서를사용하여 행해지며, 그것들은 자동적인 작업 단위 속으로 그룹지워진다. (이것은 또한 모든 하나의 SQL 문장이 어플리케이션 내에서 무용지물이 된 후에 자동-커밋됨을 의미하고, 이 모드는 SQL 콘솔 작업을 돕도록 고안되었음을 노트하라. Hibernate는 즉시 자동-커밋 모드를 사용 불가능하게 하거나, 어플리케이션 서버가 그렇게 하도록 기대한다.)

다중 사용자 클라이언트/서버 어플리케이션에서 가장 공통된 패턴은 session-per-request이다. 이 모형에서, 클라이언트로부터의 요청은 (Hibernate 영속 계층이 실행되는) 서버로 전송되고, 새로운 Hibernate Session이 열려지고, 모든 데이터베이스 오퍼레이션들이 이 작업 단위 내에서 실행된다. 일단 그 작업이 완료되면(그리고 클라이언트에 대한 응답이 준비되었다면), 세션은 flush되고 닫혀진다. 당신은 또한 당신이 Session을 열고 닫을 때 그것을 시작하고 커밋시켜서 클라이언트 요청에 서비스하는데 한 개의 데이터베이스 트랜잭션을 사용하게 될 것이다. 두 가지 사이의 관계는 일대일 대응이고 이 모형은 많은 어플리케이션들에서 완전히 적합하다.

도전점은 구현에 놓여있다: Session과 트랜잭션이 정확하게 시작되고 끝나야 할 뿐만 아니라, 그것들은 또한 데이터 액세스 오퍼레이션들에 대해 액세스 가능해야 한다. 작업의 단위에 대한 경계 구분은 요청이 서버에 도착하고 응답이 전송되기 전에 실행되는 인터셉터(예를 들면 ServletFilter)를 사용하여 이상적으로 구현된다. 우리는 ThreadLocal 변수를 사용하여 Session을 요청에 서비스하는 쓰레드에 바인드 시키는 것을 권장한다. 이것은 이 쓰레드 내에서 실행되는 모든 모드 내에서 (static 변수에 접근하는 것처럼) 쉽게 접근을 허용해준다. 당신이 선택하는 데이터베이스 트랜잭션 경계 구분 메커니즘에 따라, 당신은 또한 ThreadLocal 변수 내에 트랜잭션 컨텍스트를 유지할 수도 있다. 이것을 위한 구현 패턴들은 뷰 내의 ThreadLocal Session 및 Open Session(ThreadLocal SessionOpen Session in View)로 알려져 있다. 당신은 이것을 구현하기 위해 이 문서의 앞에서 보여졌던 HibernateUtil helper 클래스를 쉽게 확장할 수 있다. 물론 당신은 인터셉터를 구현하고 그것을 당신의 환경에 설정하는 방법을 찾아야 한다. 팁들과 예제들은 Hibernate 웹 사이트를 보라.

11.1.2. 어플리케이션 트랜잭션들

session-per-request 패턴은 당신이 작업 단위를 설계하는데 사용할 수 있는 유일한 유용한 개념이 아니다. 많은 비지니스 프로세스들은 사용자와 데이터베이스 액세스들을 중재하는 전체 일련의 상호작용들을 필요로 한다. 웹과 엔터프라이즈 어플리케이션에서 데이터베이스 트랜잭션이 사용자 상호작용에 걸치는 것은 수용되지 않는다. 다음 예제를 검토하자:

  • 대화의 첫 번째 화면이 열리고, 사용자에 의해 전송된 데이터는 특정 Session과 데이터베이스 트랜잭션 속에 로드되었다. 사용자는 객체들을 변경시키는 것이 자유롭다.
  • 사용자는 5분 후에 "저장"을 클릭하고 그의 변경들이 영속화 되기를 기대한다; 그는 또한 그가 이 정보를 편집하는 유일한 개인이고 변경 충돌이 발생하지 않기를 기대한다.

우리는 사용자의 관점에서, 이것을 작업 단위, 장기간 실행되는 어플리케이션 트랜잭션이라고 명명한다. 당신의 어플리케이션에서 당신이 이것을 어떻게 구현할 수 있는 많은 방법들이 존재한다.

첫 번째 있는 그대로의 구현은 사용자가 생각하는동안 동시성 변경을 방지하기 위해, 그리고 격리와 atomicity(원자 단위성)을 보장하기 위해 데이터베이스에 의해 억제되는 잠금으로 Session과 데이터베이스 트랜잭션을 유지할 수도 있다. 이것은 물론 anti-패턴이다. 왜냐하면 잠금 투쟁은 어플리케이션이 동시 사용자들의 수를 높이는 것을 허용하지 않을 것이기 때문이다.

명료하게, 우리는 어플리케이션 트랜잭션을 구현하는데 몇몇 데이터베이스 트랜잭션들을 사용해야 한다. 이 경우에, 비지니스 프로세스들의 격리를 유지하는 것은 어플리케이션 티어의 부분적인 책임이 된다. 단일 어플리케이션 트랜잭션은 대개 여러 개의 데이터베이스 트랜잭션들에 걸친다. 그것은 이들 데이터베이스 트랜잭션들 중 하나(마지막 트랜잭션) 만이 업데이트된 데이터를 저장하고, 모든 다른 트랜잭션들은 단순히 데이터를 읽는다(예를 들면, 몇몇 요청/응답 주기에 걸치는 마법사 스타일의 대화 상자에서). 특히 당신이 Hibernate의 특징들을 사용할 경우에 , 소리나는 것보다 이것은 구현이 더 쉽다:

  • 자동적인 버전화 - Hibernate는 당신을 위해 자동적인 optimistic 동시성 제어를 행할 수 있고, 그것은 사용자가 생각하는 시간 동안 동시적인 변경이 발생했는지를 자동적으로 검출할 수 있다.
  • Detached 객체들 - 만일 당신이 이미 논의된 session-per-request 패턴을 사용하고자 결정한 경우, 모든 로드된 인스턴스들은 사용자가 생각하는 시간 동안 detached 상태에 있을 것이고, 그 패턴은 session-per-request-with-detached-objects(detached-객체들을 가진 요청 당 세션)으로 명명된다. 자동적인 버전화는 동시성 변경들을 격리시키는데 사용된다.
  • Long Session - Hibernate Session은 데이터베이스 트랜잭션이 커밋된 후에 기본 JDBC 커넥션이 연결 해제될 수도 있고, 새로운 클라이언트 요청이 발생할 때 다시 연결될 수 있다. 이 패턴은 session-per-application-transaction(어플리케이션 트랜잭션 당 세션)으로 알려져 있고 재첨부를 불필요하게 만든다. 자동적인 버전화는 동시성 변경들을 격리시키는데 사용된다.

session-per-request-with-detached-objectssession-per-application-transaction 양자는 장점들과 단점들을 갖는데, 우리는 이 장의 뒷 부분에서 optimistic 동시성 제어 단락에서 그것들을 논의한다.

11.1.3. 객체 identity 고려하기

어플리케이션은 두 개의 다른 Session들 내에 있는 동일한 영속 상태에 동시에 접근할 수도 있다. 하지만 영속 클래스의 인스턴스는 두 개의 Session 인스턴스들 사이에 결코 공유되지 않는다. 그러므로 identity에 대한 두 개의 다른 개념들이 존재한다:

데이터베이스 Identity
foo.getId().equals( bar.getId() )
JVM Identity
foo==bar

그때 (예를 들어 의 영역에서) 특정 Session에 첨부된 객체들의 경우 두 개의 개념들은 동등한 것이고, 데이터베이스 identity에 대한 JVM identity는 Hibernate에 의해 보장된다. 하지만, 어플리케이션이 두 개의 다른 세션들 내에 있는 "동일한" (영속 identity) 비지니스 객체에 동시에 접근하는 동안, 두 개의 인스턴스들은 실제로 "다르다"(JVM identity). 충돌들은 flush/커밋 시에 (자동적인 버전화)를 사용하여, optimistic 접근법을 사용하여 해결된다.

이 접근법은 Hibernate와 데이터베이스가 동시성에 대해 걱장하지 않도록 해준다; 그것은 또한 최상의 scalability를 제공한다. 왜냐하면 단일 쓰레드-작업 단위 내에서 identity의 보장은 단지 비용이 드는 잠금이나 다른 동기화 수단들을 필요로 하지 않기 때문이다. 어플리케이션은 그것이 Session 당 단일 쓰레드를 강제하는 한, 어떤 비지니스 객체에 대해 결코 동기화 시킬 필요가 없다. Session 내에서 어플리케이션은 객체들을 비교하는데 ==를 안전하게 사용할 수가 있다.

하지만, Session 외부에서 ==를 사용하는 어플리케이션은 예기치 않은 결과들을 볼 수도 있다. 이것은 어떤 예기치 않은 장소들에서, 예를 들어 당신이 두 개의 detached 인스턴스들을 동일한 Set 내에 집어넣을 경우에 발생할 수도 있다. 둘 다 동일한 데이터베이스 identity를 가질 수 있지만(예를 들어 그것들은 동일한 행을 표현한다), JVM identity는 정의상 인스턴스들이 detached 상태에 있음을 보장하지 않는다. 개발자는 영속 클래스들내에 있는 equals() 메소드와 hashCode() 메소드를 오버라이드 시켜야 하고 객체 equality에 대한 그 자신의 개념을 구현해야 한다. 하나의 경고가 존재한다: equality를 구현하는데 데이터베이스 identifier를 결코 사용하지 말고, 비지니스 키, 유일한, 대개 불변의 속성들의 조합을 사용하라. 데이터베이스 identifier는 만일 transient 객체가 영속화되는 경우에 변경될 것이다. 만일 transient 인스턴스가(대개 detached 인스턴스들과 함께) Set 내에 보관되는 경우에 hashcode 변경은 Set의 계약을 파기시킨다. 비지니스 키들에 대한 속성들은 데이터베이스 프라이머리 키들 만큼 안정적이어서는 안되고, 당신은 오직 객체들이 동일한 Set 내에 있는 한에서 안정성을 보장해야만 한다. 이 쟁점에 관한 논의에 대한 더 많은 것을 Hibernate 웹 사이트를 보라. 또한 이것이 Hibernate 쟁점이 아니지만, 단지 자바 객체 identity와 equality가 구현되어야 하는 방법임을 노트하라. 

11.1.4. 공통된 쟁점들

안티-패턴들 session-per-user-session 또는 session-per-application 을 결코 사용하지 말라(물론 이 규칙에 대한 드문 예외상황들이 존재한다). 다음 쟁점들 중 몇몇이 또한 권장되는 패턴들로 나타남을 노트하고, 설계 결정을 내리기 전에 내포된 의미들을 확실히 이해하라:

  • Session 은 쓰레드-안전하지 않다. HTTP 요청들, 세션 빈즈, 또는 Swing worker들처럼 동시에 작업하는 것으로 가정되는 것들은 Session  인스턴스가 공유될 경우에 경쟁 조건들을 발생시킬 것이다. 만일 당신이 당신의 HttpSession 내에 Hibernate Session을 유지시키는 경우(나중에 논의됨), 당신은 당신의 Http 세션에 대한 접근을 동기화 시키는 것을 고려해야 한다. 그 밖의 경우, 충분히 빠르게 reload를 클릭하는 사용자는 두 개의 동시적으로 실행되는 쓰레드들에서 동일한 Session을 사용할 수도 있다.
  • Hibernate에 의해 던져진 예외상황은 당신이 당신의 데이터베이스 트랜잭션을 롤백 시키고 즉시 Session을 닫아야 함을 의미한다(나중에 상세히 논의됨). 만일 당신의 Session이 어플리케이션에 바인드 되어 있는 경우, 당신은 어플리케이션을 중지시켜야 한다. 데이터베이스 트랜잭션 롤백은 당신의 비지니스 객체들을 그것들이 트랜잭션의 시작 시에 머물렀던 상태로 집어넣지 않는다. 이것은 데이터베이스 상태와 비지니스 객체들이 동기화를 벗어남을 의미한다. 대개 이것은 문제가 아니다. 왜냐하면 예외상황들은 회복가능한 것이 아니고 당신이 어떻게든 롤백 후에 시작해야 하기 때문이다.
  • Session 은 (Hibernate에 의해 dirty 상태로 관찰되었거나 체크된) 영속 상태에 있는 모든 객체를 캐시 시킨다. 이것은 당신이 오랜 시간 동안  그것을 열린 채로 유지하거나 단순히 너무 많은 데이터를 로드시킬 경우에, 당신이 OutOfMemoryException을 얻기 전까지, 그것이 끝없이 설장한다는 점을 의미한다. 이것에 대한 하나의 해결책은 Session  캐시를 관리하기 위해 clear()evict()를 호출하는 것이지만, 당신이 대용량 데이터 오퍼레이션들을 필요로 하는 경우에 당신은 대개 내장 프로시저를 고려해야 할 것이다. 몇몇 해결책들이 13 장, 배치 처리에 보여져 있다. 사용자 세션 동안에 Session을 열려진 채로 유지하는 것은 또한 실효성이 떨어진 데이터에 대한 높은 확률을 의미한다.

11.2. 데이터베이스 트랜잭션 경계 설정

데이터베이스 (또는 시스템) 트랜잭션 경계들이 항상 필수적이다. 데이터베이스와의 통신은 데이터베이스 트랜잭션의 외부에서 발생할 수 없다(이것은 자동-커밋 모드로 사용되는 많은 개발자들에게는 혼동스러워 보인다). 항상 심지어 읽기 전용 오퍼레이션들에 대해서도 명료한 트랜잭션 경계들을 사용하라. 당신의 격리 레벨과 데이터베이스 가용성들에 따라, 이것은 필요하지 않을 수 있지만, 만일 당신이 항상 트랜잭션들을 명시적으로 경계 설정할 경우에는 하강하는 결점들이 존재하지 않는다.  

Hibernate 어플리케이션은 관리되지 않는  환경(예를 들면. 스탠드얼론, 간단히 웹 어플리케이션들 또는 Swing 어플리케이션들)과 관리되는 J2EE 환경에서 실행될 수 있다. 관리되지 않는 환경에서, Hibernate는 대개 그것 자신의 데이터베이스 커넥션 풀에 대한 책임이 있다. 어플리케이션 개발자는 트랜잭션 경계들을 손수 설정해야 한다. 달리 말해, 데이터베이스 트랜잭션들 자체를 시작하고, 커미시키거나 롤백시켜야 한다. 관리되는 환경은  예를 들어 EJB 세션 빈즈의 배치 디스크립터 속에 선언적으로 정의된 트랜잭션 어셈블리를 가진, 컨테이너에 의해-관리되는 트랜잭션들을 제공한다. 그때 프로그램 상의 트랜잭션 경계 설정은 더 이상 필요하지 않다. 심지어 Session을 flush 시키는 것이 자동적으로 행해진다.

하지만, 당신의 영속 계층이 이식성을 유지하게끔 자주 희망된다. Hibernate는 당신의 배치 환경의 고유한 트랜잭션 시스템 속으로 변환되는 Transaction으로 명명되는 wrapper API 를 제공한다. 이 API는 실제로 옵션이지만 우리는 당신이 CMT session bean 속에 있지 않는 한 그것의 사용을 강력하게 권장한다.  

대개 Session 종료는 네 개의 구분되는 단계들을 수반한다:

  • 세션을 flush 시킨다 
  • 트랜잭션을 커밋 시킨다
  • 세션을 닫는다
  • 예외상황들을 처리한다

세션을 flush 시키는 것은 앞서 논의되었고, 우리는 이제 관리되는 환경과 관리되지 않는 환경 양자에서 트랜잭션 경계 설정과 예외상황을 더 자세히 살펴볼 것이다.

11.2.1. 관리되지 않는 환경

만일 Hibernate 영속 계층이 관리되지 않는(non-managed) 환경에서 실행될 경우, 데이터베이스 커넥션들은 대개 Hibernate의 풀링 메커니즘에 의해 처리된다. session/transaction 처리 관용구는 다음과 같이 보여진다:

//Non-managed environment idiom
Session sess = factory.openSession();
Transaction tx = null;
try {
    tx = sess.beginTransaction();

    // 어떤 작업을 행한다
    ...

    tx.commit();
}
catch (RuntimeException e) {
    if (tx != null) tx.rollback();
    throw e; // 또는 오류 메시지를 디스플레이 한다
}
finally {
    sess.close();
}

당신은 Session을 명시적으로 flush()시키지 말아야 한다 - commit()에 대한 호출은 동기화를 자동적으로 트리거 시킨다. 

close()에 대한 호출은 세션의 종료를 마크한다. close()의 주요 함축은 JDBC 커넥션이 그 세션에 의해 포기될 것이라는 점이다.

이 자바 코드는 이식성이 있고 관리되지 않는 환경과 JTA 환경 양자에서 실행된다.

당신은 통상의 어플리케이션에서 비지니스 코드 속에 이 관용구를 결코 보게 되지 않을 것이다; 치명적인(시스템) 예외상황들은 항상 "상단"에서 잡아 내어야 한다. 달리 말해, Hibernate를 실행하는 코드가 (영속 계층에서) 호출되고 RuntimeException을 처리하는 (그리고 대개 오직 제거하고 빠져나갈 수 있는) 코드는 다른 계층들 속에 있다. 이것은 당신 자신이 설계하는 도전점일 수 있고 당신은 J2EE/EJB 컨테이너 서비스들이 이용 가능할 때마다 J2EE/EJB 컨테이너 서비스들을 사용할 것이다. 예외상황 처리는 이 장의 뒷부분에서 논의된다.

당신은 (디폴트인) org.hibernate.transaction.JDBCTransactionFactory를 선택해야 함을 노트하라.

11.2.2. JTA 사용하기

만일 당신의 영속 계층이 어플리케이션 서버에서(예를 들어, EJB 세션 빈즈 이면에서) 실행될 경우, Hibernate에 의해 획득된 모든 데이터소스 커넥션은 자동적으로 전역 JTA 트랜잭션의 부분일 것이다. Hibernate는 이 통합을 위한 두 개의 방도들을 제공한다.

만일 당신이 bean-managed transactions (BMT)을 사용할 경우 Hibernate는 당신이 Transaction API를 사용할 경우에 BMT 트랜잭션을 시작하고 종료하도록 어플리케이션 서버에게 알려줄 것이다. 따라서 트랜잭션 관리 코드는 non-managed 환경과 동일하다.

// BMT idiom
Session sess = factory.openSession();
Transaction tx = null;
try {
    tx = sess.beginTransaction();

    // 어떤 작업을 행한다
    ...

    tx.commit();
}
catch (RuntimeException e) {
    if (tx != null) tx.rollback();
    throw e; // 또는 오류 메시지를 디스플레이 한다 
}
finally {
    sess.close();
}

CMT의 경우, 트랜잭션 관할[경계 설정]은 프로그램 상이 아닌, session bean 배치 디스크립터들 속에서 행해진다. 당신이 hibernate.transaction.flush_before_completion, hibernate.transaction.auto_close_session 프로퍼티들을 true로 설정하지 않는 한, 당신은 여전히 당신 스스로 Session을 flush하고 닫아야 한다. 그런 다음 Hibernate는 당신을 위핸 Session을 자동적으로 flush 시키고 닫을 것이다. 유일하게 남은 것은 예외상황이 일어날 때 트랜잭션을 롤백 시키는 것이다. 다행히 CMT bean에서, 이것이 자동적으로 일어난다. 왜냐하면 session bean 메소드에 의해 던져진 처리되지 않은 RuntimeException이 전역 트랜잭션을 롤백시키도록 컨테이너에게 알려주기 때문이다. 이것은 당신이 CMT에서 Hibernate Transaction API를 사용할 필요가 전혀 없음을 의미한다.

당신이 BMT session bean에서 org.hibernate.transaction.JTATransactionFactory를 선택해야하고,당신이 Hibernate의 트랜잭션 팩토리를 구성할 때 CMT session bean에서 org.hibernate.transaction.CMTTransactionFactory를 선택해야 함을 노트하라. 또한 org.hibernate.transaction.manager_lookup_class를 설정하는 것을 염두에 두라.

만일 당신이 CMT 환경에서 작업하고 있고, 세션의 자동적인 flushing과 닫기를 사용할 경우, 당신은 또한 당신의 코드의 다른 부분에서 동일한 세션을 사용하고자 원할 수도 있다. 일반적으로 관리되지 않는 환경에서 당신은 세션을 소유하는데 ThreadLocal 변수를 사용할 것이지만, 한 개의 EJB 메소드는 다른 쓰레드(예를 들면 또 다른 세션 빈을 호출하는 세션 빈) 내에서 실행될 수도 있다. 만일 당신이 당신의 Session 인스턴스를 전달하는 것을 고민하고 싶지 않다면, SessionFactory는 JTA 트랜잭션 컨텍스트에 바인드되어 있는 한 개의 세션을 반환하는 getCurrentSession()메소드를 제공한다. 이것은 Hibernate를 어플리케이션 속으로 통합시키는 가장 손쉬운 방법이다! "current" 세션은 항상 (위의 프로퍼티 설정들에 관계없이) auto-flush와 auto-close를 이용 가능하게 한다. 우리의 session/transaction 관리 idiom은 다음과 같이 감소된다:

// CMT idiom
Session sess = factory.getCurrentSession();

// 어떤 작업을 행한다
...

달리 말해, 당신이 관리 환경에서 행해야 하는 모든 것은 SessionFactory.getCurrentSession()을 호출하고, 당신의 데이터 접근 작업을 행하고, 그리고 나머지는 컨테이너에게 남겨두는 것이다. 트랜잭션 경계들은 당신의 session bean의 배치 디스크립터들 속에서 선언적으로 설정된다. 그 세션의 생명주기는 Hibernate에 의해 완전하게 관리된다. 

auto_close_session의 사용에는 한 가지 단서가 존재한다. JTA 명세서의 제약성으로 인해, Hibernate가 scroll() 또는 iterate()에 의해 반환된 어떤 닫혀지지 않은 ScrollableResults 또는 Iterator 인스턴스들을 자동적으로 제거하는 것이 불가능하다. 당신은 finally 블록에서 ScrollableResults.close() 또는 Hibernate.close(Iterator)를 명시적으로 호출하여 기본 데이터베이스 커서를 해제시켜야 한다. (물론 대부분의 어플리케이션들은 CMT 코드에서 scroll() 또는 iterate()를 사용하는 것을 쉽게 피할 수 있다.)

11.2.3. 예외상황 처리

만일 Session이 (어떤 SQLException을 포함하는) 예외상황을 던질 경우, 당신은 데이터베이스 트랜잭션을 즉시 롤백시키고, Session.close()를 호출하고 Session 인스턴스를 폐기시켜야한다. Session의 어떤 메소드들은 그 세션을 일관된 상태로 남겨두지 않을 것이다. Hibernate에 의해 던져진 예외상황은 복구가능한 것으로 취급될 수 없다. 그 Session이  finally 블록 내에서 close()를 호출하여 닫혀지도록 확실히 하라. 

Hibernate 영속 계층에서 발생할 수 있는 대부분의 오류들을 포장하는 HibernateException은 체크되지 않은 예외상황이다(그것은 Hibernate의 이전 버전에는 없었다). 우리의 의견으로, 우리는 낮은 계층에서 복구불가능한 예외상황을 캐치하도록 어플리케이션 개발자를 강제하지 않을 것이다. 대부분의 시스템들에서, 체크되지 않은 치명적인 예외상황들은 (예를 들어 더 높은 계층에서) 메소드 호출 스택의 첫 번째 프레임들 중 하나 속에서 처리되고, 한 개의 오류 메시지가 어플리케이션 사용자에게 표시된다(또는 어떤 다른 적절한 액션이 취해진다). Hibernate는 또한 HibernateException이 아닌, (예를 들면 버전 체크에서 실효성이 없는 데이터를 검출할 때) 다른 체크되지 않은 예외상황들을 던질 수도 있음을 노트하라. 다시 이것들은 복구가능하지 않고 적절한 액션이 취해져야 한다.

Hibernate는 데이터베이스와 상호작용하는 동안에 던져진 SQLException들을 하나의 JDBCException 속에 포장한다. 사실, Hibernate는 그 예외상황을 JDBCException의 보다 의미있는 서브클래스로 변환하려고 시도할 것이다. 기본 SQLException은 항상 JDBCException.getCause()를 통해 이용 가능하다. Hibernate는 SessionFactory에 첨부된 SQLExceptionConverter를 사용하여 SQLException을 적당한 JDBCException 서브클래스로 변환시킨다. 디폴트로 SQLExceptionConverter는 구성된 dialect에 의해 정의된다; 하지만 또한 맞춤 구현 속에 플러그인 시키는 것이 가능하다(상세한 것은 SQLExceptionConverterFactory 클래스에 관한 javadocs를 보라). 표준 JDBCException 서브타입은 다음과 같다:

  • JDBCConnectionException - 기본 JDBC 통신에 대한 오류를 나타낸다.
  • SQLGrammarException - 생겨난 SQL에 대한 문법 또는 구문 문제점을 나타낸다.
  • ConstraintViolationException - 무결성 제약 위반에 관한 어떤 형식을 나타낸다.
  • LockAcquisitionException - 요청된 오퍼레이션을 실행하는데 필수적인 잠금 레벨을 획득하는 오류를 나타낸다.
  • GenericJDBCException - 다른 카테고리들 중 어떤 것으로 분류되지 않았던 일반적인 예외상황.

11.3. Optimistic 동시성 제어

고도의 동시성과 고도의 가용성을 일치시키는 유일한 접근법은 버전화를 가진 optimistic동시성 제어이다. 버전 체킹은 업데이트 충돌을 검출하기 위해(그리고 업데이트 손실을 방지하기 위해) 버전 번호들 또는 timestamp들을 사용한다. Hibernate는 optimistic동시성을 사용하는 어플리케이션 코드를 작성하는데 세 가지 가능한 접근법들을 제공한다. 우리가 보여주는 쓰임새들은 긴 어플리케이션 트랜잭션들의 상황 속에 있지만 버전 체킹 또한 단일 데이터베이스 트랜잭션들에서 업데이트 손실을 방지하는 이점을 갖고 있다.

11.3.1. 어플리케이션 버전 체킹

Hibernate의 많은 도움이 없는 구현에서, 데이터베이스에 대한 각각의 상호작용은 새로운 Session  내에서 일어나고, 개발자는 그것들을 처리하기 전에 데이터베이스로부터 모든 영속 인스턴스들을 다시 로드시키는 책임이 있다. 이 접근법은 어플리케이션 트랜잭션을 확실히 격리시키기 위해 그것 자신의 버전 체킹을 수행하는 것을 어플리케이션에게 강제시킨다. 이 접근법은 최소한 데이터베이스 접근의 관점에서 효율성이 가장 적다. 그것은 엔티티 EJB들과 가장 유사한 접근법이다.

// foo는 이전 Session에 의해 로드된 인스턴스이다 
session = factory.openSession();
Transaction t = session.beginTransaction();
int oldVersion = foo.getVersion();
session.load( foo, foo.getKey() ); // 현재 상태를 로드시킨다
if ( oldVersion!=foo.getVersion ) throw new StaleObjectStateException();
foo.setProperty("bar");
t.commit();
session.close();

version 프로퍼티는 <version>을 사용하여 매핑되고, Hibernate는 만일 엔티티가 dirty일 경우 flush 동안에 그것을 자동적으로 증가시킬 것이다.

물론, 당신이 낮은 데이터 동시성 환경에서 작업하고 있고 버전 체킹을 필요로 하지 않을 경우에, 당신은 이 접근법을 사용할 수 도 있고 단지 버전 체크를 생략할 수도 있다. 그 경우에, last commit wins 는 당신의 긴 어플리케이션 트랜잭션들에 대한 디폴트 방도가 될 것이다. 이것이 어플리케이션의 사용자들을 혼동시킬 수 있음을 염두에 두라. 왜냐하면 사용자들은 오류 메시지들 또는 충돌 변경들을 병합시킬 기회 없이 업데이트들 손실을 겪을 수도 있기 때문이다.

명료하게 수작업 버전 체킹은 매우 사소한 환경들에서도 공포적이고 대부분의 어플리케이션들에 대해 실제적이지 않다. 흔히 단일 인스턴스 뿐만 아니라 변경된 객체들의 전체 그래프들이 체크되어야 한다. Hibernate는 설계 패러다임으로서 긴 Session 또는 detached 인스턴스들에 대해 자동적인 버전 체킹을 제공한다.

11.3.2. 긴 세션과 자동적인 버전화

하나의 Session 인스턴스와 그것의 영속 인스턴스들은 전체 어플리케이션 트랜잭션에 사용된다. Hibernate는 flush 할 때 인스턴스 버전들을 체크하고 만일 동시성 변경이 검출될 경우에 예외상황을 던진다. 이 예외상황을 잡아내고 처리하는 것을 개발자의 몫이다(공통된 옵션들은 변경들을 병합시키거나 또는 쓸모가 없지 않은 데이터로 비지니스 프로세스를 다시 시작하는 기회를 사용자에게 주는 것이다).

Session은 사용자 상호작용을 기다릴 때 어떤 기본 JDBC 커넥션으로부터 연결해제된다. 이 접근법은 데이터베이스 접근의 관점에서 보면 가장 효율적이다. 어플리케이션은 버전 체킹 또는 detached 인스턴스들을 재첨부하는 것에 그 자체 관계할 필요가 없거나 그것은 모든 데이터베이스 트랜잭션에서 인스턴스들을 다시 로드시킬 필요가 없다.

// foo는 Session에 의해 로드된 인스턴스이다 
session.reconnect(); // 새로운 JDBC 커넥션을 얻는다
Transaction t = session.beginTransaction();
foo.setProperty("bar");
t.commit(); // 변경을 flush 시키고 버전을 체킹하여 데이터베이스 트랜잭션을 종료시킨다 
session.disconnect(); // JDBC 커넥션을 반환한다

foo 객체는 그것이 로드된 Session이 어느 것이였는지를 여전히 알고 있다.  Session.reconnect()은 새로운 커넥션을 획득하고(또는 당신이 커넥션을 제공할 수 있다) 그리고 그 세션을 다시 시작시킨다.  Session.disconnect() 메소드는 JDBC 커넥션으로부터 세션을 연결해제하고 (당신이 커넥션을 제공하지 않는 한) 그 커넥션을 풀(pool)로 반환할 것이다. 재연결 후에, 당신이 업데이트하고 있는 데이터에 대한 버전 체킹을 강제시키기 위해, 당신은 또 다른 트랜잭션에 의해 업데이트 되었던 어떤 객체들에 대해 LockMode.READSession.lock()을 호출할 수도 있다. 당신은 당신이 업데이트하고 있는 어떤 데이터에 대한 잠금을 필요로 하지 않는다.

 만일 사용자가 생각하는시간 동안 Session이 저장되기에 너무 큰 경우에 이 패턴은 문제가 있다. 예를 들어 HttpSession은 가능한 작은 것으로 유지되어야 한다. 또한  Session은 (위임된) 첫 번째 레벨 캐시이고 모든 로드된 객체들을 포함하기 때문에, 우리는 아마 적은 요청/응답 주기들에 대해서만 이 방도를 사용할 수 있다. Session이 곧 실효성이 없는 데이터를 갖게 될 것이므로 이것이 진정으로 권장된다.

또한 당신이 연결해제된 Session을 영속 계층에 가깝게 유지해야함을 노트하라. 달리말해, Session을 보관하는데 EJB stateful session bean을 사용하고 HttpSession 내에 그것을 저장하기 위해서 그것을 웹 계층에 전송하지 말라(또는 그것을 별도의 티어에 직렬화 시키지도 말라).

11.3.3. Detached 객체들과 자동적인 버전화

영속 저장소와의 각각의 상호작용은 새로운 Session에서 일어난다. 하지만 동일한 영속 인스턴스들은 데이터베이스와의 각각의 상호작용에 재사용된다. 어플리케이션은 원래 로드되었던 detached 인스턴스들의 상태를 또 다른 Session 내에서 처리하고 나서 Session.update(), Session.saveOrUpdate()Session.merge()를 사용하여 그것들을 다시 첨부시킨다.

// foo는 이전 Session에 의해 로드된 인스턴스이다
foo.setProperty("bar");
session = factory.openSession();
Transaction t = session.beginTransaction();
session.saveOrUpdate(foo); // "foo"가 이미 로드되었다면 merge()를 사용하라 
t.commit();
session.close();

다시, Hibernate는 flush 동안에 인스턴스 버전들을 체크할 것이고 업데이트 충돌이 발생할 경우에 예외상황을 던질 것이다.

당신은 또한 update()대신에 lock()을 호출할 수도 있고 만일 그 객체가 변경되지 않았음을 당신이 확신하는 경우에 (버전 체킹을 수행하고 모든 캐시들을 무시하는) LockMode.READ를 사용할 수 있다.

11.3.4. 자동적인 버전화를 맞춤화 시키기

당신은 optimistic-lock 매핑 속성을 false로 설정함으로써 특정 프로퍼티들과 콜렉션들에 대한 Hibernate의 자동적인 버전 증가를 불가능하도록 할 수도 있다. 그때 Hibernate는 그 프로퍼티가 dirty 일 경우에 더 이상 버전을 증가시키지 않을 것이다.

리거시 데이터베이스 스키마들은 자주 static이고 변경될 수 없다. 또는 다른 어플리케이션들은 또한 동일한 데이터베이스에 접근하고 버전 번호들 또는 심지어 timestamp들을 처리하는 방법을 모를 수도 있다. 두 경우들에서, 버전화는 테이블 내의 특정 컬럼에 의지할 수 없다. version 또는 timestamp 프로퍼티 매핑 없이 행 내의 모든 필드들에 대한 상태를 비교하여 버전 체크를 강제시키기 위해서, <class>  매핑 속에 optimistic-lock="all"을 표시하라. 만일 Hibernate가 이전 상태와 새로운 상태를 비교할 수 있을 경우에, 예를 들면 당신이 하나의 긴 Session을 사용하고 session-per-request-with-detached-objects을 사용하지 않을 경우 이것은 개념적으로만 동작함을 노트하라.

때때로 행해졌던 변경들이 중첩되지 않는 한 동시적인 변경이 허용될 수 있다. 만일 <class>를 매핑할 때 당신이 optimistic-lock="dirty"을 설정하면, Hibernate는 flush 동안에 dirty 필드들을 비교만 할 것이다.

두 경우들에서, 전용 version/timestamp 컬럼의 경우 또는 full/dirty 필드 비교의 경우, Hibernate는 법전 체크를 실행하고 정보를 업데이트하는데 엔티티 당 (적절한 WHERE 절을 가진) 한 개의 UPDATE 문장을 사용한다. 만일 당신이 연관된 엔티티들에 대한 재첨부를 케스케이드 하는데 transitive 영속을 사용할 경우, Hibernate는 불필요하게 업데이트들을 실행할 수도 있다. 이것은 대개 문제가 아니지만, 심지어 변경들이 detached 인스턴스들에 대해 행해지지 않았을 때에도 데이터베이스 내에서 on update 트리거들이 실행될 수도 있다. 행을 업데이트하기 전에 변경들이 실제로 일어났음을 확인하기 위해 인스턴스를 SELECT 하는 것을 Hibernate에게 강제시키는, <class> 매핑 속에 select-before-update="true"를 설정함으로써 당신은 이 특징을 맞춤화 시킬 수 있다.

11.4. Pessimistic 잠금

사용자들은 잠금 방도에 대해 걱정하는데 많은 시간을 할애하하려고 생각하지 않는다. 대개 JDBC 커넥션들에 대한 격리 레벨을 지정하는 것으로 충분하고 그런 다음 단순히 데이터베이스로 하여금 모든 작업을 행하도록 한다. 하지만 진일보한 사용자들은 때때로 배타적인 pessimistic 잠금들을 얻거나 또는 새로운 트랜잭션의 시작 시에 잠금들을 다시 얻고자 원할 수도 있다.

Hibernate는 결코 메모리 내에 있는 객체들이 아닌 데이터베이스의 잠금 메커니즘을 항상 사용할 것이다!

LockMode 클래스는 Hibernate에 의해 획득될 수 있는 다른 잠금 레벨들을 정의한다. 잠금은 다음 메커니즘들에 의해 얻어진다:

  • LockMode.WRITE 는 Hibernate가 한 행을 업데이트 하거나 insert 할 때 자동적으로 획득된다.
  • LockMode.UPGRADESELECT ... FOR UPDATE 구문을 지원하는 데이터베이스 상에서 SELECT ... FOR UPDATE를 사용하여 명시적인 사용자 요청 상에서 얻어질 수 있다.
  • LockMode.UPGRADE_NOWAIT 는 오라클에서 SELECT ... FOR UPDATE NOWAIT를 사용하여 명시적인 사용자 요청 상에서 얻어질 수도 있다.
  • LockMode.READ 는 Hibernate가 반복 가능한 읽기(Repeatable Read) 또는 Serialization 격리 레벨에서 데이터를 읽어들일 때 자동적으로 얻어질 수도 있다. 명시적인 사용자 요청에 의해 다시 얻어질 수도 있다. 
  • LockMode.NONE 은 잠금이 없음을 나타낸다. 모든 객체들은 Transaction의 끝에서 이 잠금 모드로 전환된다. update() 또는 saveOrUpdate()에 대한 호출을 통해 세션과 연관된 객체들은 또한 이 잠금 모드로 시작된다.

"명시적인 사용자 요청"은 다음 방법들 중 하나로 표현된다: 

  • LockMode를 지정한, Session.load()에 대한 호출.
  • Session.lock()에 대한 호출.
  • Query.setLockMode()에 대한 호출.

일 Session.load()UPGRADE 또는 UPGRADE_NOWAIT 모드로 호출되고 ,요청된 객체가 아직 이 세션에 의해 로드되지 않았다면, 그 객체는 SELECT ... FOR UPDATE를 사용하여 로드된다. 만일 요청된 것이 아닌 다소 제한적인 잠금으로 이미 로드되어 있는 객체에 대해 load()가 호출될 경우, Hibernate는 그 객체에 대해 lock()을 호출한다.

만일 지정된 잠금 모드가 READ, UPGRADE 또는 UPGRADE_NOWAIT 일 경우에 Session.lock() 은 버전 번호 체크를 수행한다.( UPGRADE 또는 UPGRADE_NOWAIT 인 경우에, SELECT ... FOR UPDATE 가 사용된다.)

만일 데이터베이스가 요청된 잠금 모드를 지원하지 않을 경우, (예외상황을 던지는 대신에) Hibernate는 적절한 대체 모드를 사용할 것이다. 이것은 어플리케이션이 이식 가능할 것임을 확실히 해준다. 

12 장. 인터셉터들과 이벤트들

어플리케이션이 Hibernate 내부에서 발생하는 어떤 이벤트들에 대해 반응하는 것이 자주 유용하다. 이것은 어떤 종류의 일반적인 기능, 그리고 Hibernate의 확장 기능의 구현을 허용해준다. 

12.1. 인터셉터들

Interceptor 인터페이스는 영속 객체가 저장되고, 업데이트되고, 삭제되거나 로드되기 전에 영속 객체의 프로퍼티들을 조사하고/하거나 처리하는 것을 어플리케이션에 허용해줌으로써 세션으로부터 어플리케이션으로의 콜백들을 제공한다. 이것에 대한 한 가지 가능한 사용은 감사 정보를 추적하는 것이다. 예를 들어, 다음 InterceptorAuditable이 생성될 때 createTimestamp를 자동적으로 설정하고고 Auditable이 업데이트될 때 lastUpdateTimestamp 프로퍼티를 업데이트 한다.

package org.hibernate.test;

import java.io.Serializable;
import java.util.Date;
import java.util.Iterator;

import org.hibernate.Interceptor;
import org.hibernate.type.Type;

public class AuditInterceptor implements Interceptor, Serializable {

    private int updates;
    private int creates;

    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) {
        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 postFlush(Iterator entities) {
        System.out.println("Creations: " + creates + ", Updates: " + updates);
    }

    public void preFlush(Iterator entities) {
        updates=0;
        creates=0;
    }

    ...

}

인터셉터는 세션이 생성될 때 지정될 것이다.

Session session = sf.openSession( new AuditInterceptor() );

당신은 또한 Configuration을 사용하여 인터셉터를 전역 레벨 상에 설정할 수도 있다:

new Configuration().setInterceptor( new AuditInterceptor() );

12.2. 이벤트 시스템

당신의 영속 계층에서 특별한 이벤트들에 대해 반응해야 한다면, 당신은 또한 Hibernate3 이벤트 아키텍처를 사용할 수도 있다. 이벤트 시스템은 부가물로 사용될 수 있거나 인터셉터들에 대한 대체물로 사용될 수 있다.

본질적으로 Session 인터페이스의 모든 메소드들은 이벤트와 서로 관련되어 있다.  당신은 LoadEventFlushEvent, 등을 갖는다 (정의된 이벤트 타입들의 전체 리스트에 대해서는 XML 구성 파일 DTD 또는 org.hibernate.event 패키지를 참조하라). 하나의 요청이 이들 메소드들 중 하나에 의해 만들어질 때, Hibernate Session은  적절한 이벤트를 생성시키고 그것을 그 타입에 대해 구성된 이벤트 리스너에게 전달한다. 박싱없이, 이들 리스너들은 그들 메소드들이 항상 귀결되는 동일한 프로세싱을 구현한다. 하지만 당신이 리스너 인터페이스들 중 하나에 대한 맞춤화 구현하는 것은 자유롭고(예를 들어 LoadEventLoadEventListener 인터페이스의 등록된 구현에 의해 처리된다), 그 경우에 그들 구현은 Session에 의해 만들어진 임의의 load() 요청들을 처리할 책임이 있을 것이다.

리스너들은 효과적으로 싱글톤(singleton)들로 고려되어야 할 것이다; 이것은 그것들이 요청들 사이에서 공유되고, 따라서 임의의 상태를 인스턴스 변수들로서 저장하지 말아야 함을 의미한다. 하지만 이벤트 객체들 그 자체들은 그것들이 각각의 요청에 대해 유일하므로 처리에 필요한 많은 컨텍스트를 보관한다. 맞춤형 이벤트 리스너들은 또한 어떤 필요한 처리 변수들의 스토리지로서 이벤트의 컨텍스트를 사용할 수도 있다. 컨텍스트는 간단한 맵이지만, 디폴트 리스너들은 컨텍스트 맵을 전혀 사용하지 않아서, 내부적으로 필요한 컨텍스트 변수들을 덮어쓰는 것을 걱정하지 않는다.

맞춤형 리스너는 그것이 편의적인 기저 클래스들(또는 리스너들이 이 용도로 final이 아닌 것으로 선언되므로 Hibernate out-of-the-box에 의해 사용된 디폴트 이벤트 리스너들) 중 하나를 처리하고자 그리고/또는 확장하고자 원하는 이벤트들에 대해 적절한 인터페이스를 구현해야 한다. 맞춤형 리스너들은 Configuration 객체를 통해 프로그램 상으로 등록될 수 있거나, Hibernate 구성 XML 속에 지정될 수 있다 (프로퍼티들을 통한 선언적인 구성은 지원되지 않는다). 다음은 맞춤형 load 이벤트 리스너에 대한 예제이다:

public class MyLoadListener extends DefaultLoadEventListener {
    // this is the single method defined by the LoadEventListener interface
    public Object onLoad(LoadEvent event, LoadEventListener.LoadType loadType)
            throws HibernateException {
        if ( !MySecurity.isAuthorized( event.getEntityClassName(), event.getEntityId() ) ) {
            throw MySecurityException("Unauthorized access");
        }
        return super.onLoad(event, loadType);
    }
}

당신은 또한 Hibernate에게 디폴트 리스너 대신에 해당 리스너를 사용하도록 알려주는 구성 엔트리를 필요로 한다:

<hibernate-configuration>
    <session-factory>
        ...
        <listener type="load" class="MyLoadListener"/>
    </session-factory>
</hibernate-configuration>

대신에 당신은 그것을 프로그램 상으로 등록할 수도 있다:

Configuration cfg = new Configuration();
cfg.getSessionEventListenerConfig().setLoadEventListener( new MyLoadListener() );

선언적으로 등록된 리스너들은 인스턴스들을 공유할 수 없다. 만일 동일한 클래스 이름이 여러 <listener/> 요소들에서 사용될 경우, 각각의 참조는 그 클래스에 대한 별도의 인스턴스로 귀결될 것이다. 만일 당신이 리스너 타입들 사이에서 리스너 인스턴스들을 공유할 가용성을 필요로 할 경우 당신은 프로그램 상의 등록 접근법을 사용해야 한다. 

왜 인터페이스를 구현하고 컨피그레이션 동안 특정 타입을 지정하는가? 물론 리스너 구현은 여러 개의 이벤트 리스너 인터페이스들을 구현할 수 있다. 등록 동안에 타입을 추가적으로 정의하는 것은 컨피그레이션 동안에 맞춤형 리스너들의 사용 여부를 전환시키는 것을 더 쉽게 해준다.

12.3. Hibernate 선언적인 보안

대개 Hibernate 어플리케이션들에서 선언적인 보안은 session facade 계층에서 관리된다. 이제, Hibernate3는 어떤 액션들이 JACC를 통해 퍼미션을 주어지고, JAAS를 통해 인가되는 것을 허용해준다. 이것은 모든 아키텍처의 상단에 빌드된 옵션 기능이다.

먼저, 당신은 JAAS authorization 사용을 이용 가능하도록 하기 위해 적절한 이벤트 리스터들을 구성해야 한다.

<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"/>

다음으로, 여전히 hibernate.cfg.xml 내에서 퍼미션들을 role들에 바인드 시킨다 :

<grant role="admin" entity-name="User" actions="insert,update,read"/>
<grant role="su" entity-name="User" actions="*"/>

역할(role) 이름들은 당신의 JACC 프로바이더에 의해 이해된 role들이다.

13 장. Batch processing

Hibernate를 사용하여 100 000 개의 행들을 삽입시키는 naive 접근법은 다음과 같다:

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();

이것은 50 000번째 행 가까운 곳에서 OutOfMemoryException 상으로 떨어질 것이다. 그것은 Hibernate가 session-level 캐시 속에 모든 새로이 삽입된 Customer 인스턴스들을 캐시시키기 때문이다.

이 장에서 우리는 이 문제를 피하는 방법을 당신에게 보여줄 것이다. 하지만 먼저 당신이 배치 처리를 행할 경우, 당신이 적당한 퍼포먼스를 성취하려고 할 경우에 당신이 JDBC 배치 사용을 가능하게 하는 것은 절대적으로 필요하다. JDBC 배치 사이즈를 적당한 숫자(10-50)로 설정하라.

hibernate.jdbc.batch_size 20

당신은 또한 second-level 캐시를 가진 상호작용이 완전하게 불가능한 프로세스 내에서 이런 종류의 작업을 행하고 싶어할 수도 있다:

hibernate.cache.use_second_level_cache false

13.1. Batch inserts

새로운 객체들을 영속화  시킬 때, 당신은 first-level 캐시의 사이즈를 제어하기 위해 세션을 정기적으로 flush()시키고 나서 clear() 시켜야 한다. 

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, JDBC 배치 사이즈와 같다
        // insert들의 batch를 flush 시키고 메모리를 해제시킨다: 
        session.flush();
        session.clear();
    }
}
   
tx.commit();
session.close();

13.2. Batch updates

데이터 검색과 업데이트의 경우 동일한 아이디어들이 적용된다. 게다가 당신은 많은 데이터 행들을 반환하는 질의들에 대해 서버-측 커서들의 장점을 취하는데 scroll()을 사용할 필요가 있다.

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 ) {
        // update들의 batch를 flush 시키고 메모리를 해제시킨다: 
        session.flush();
        session.clear();
    }
}
   
tx.commit();
session.close();

13.3. 대량 update/delete

이미 논의했듯이, 자동적이고 투명한 객체/관계형 매핑은 객체 상태의 관리에 관계된다. 이것은 객체 상태가 메모리 내에서 이용 가능함을 의미하므로, 데이터베이스 내에서 직접 데이터를 업데이트하거나 삭제하는 것(SQL을 사용하는 UPDATEDELETE)는 메모리 내 상태에 영향을 주지 않을 것이다. 하지만 Hibernate는  Hibernate Query Language를 통해 수행되는 대량 SQL-스타일의 UPDATEDELETE 문장 실행을 위한 메소드들을 제공한다.(14장,HQL: Hibernate Query Language).

UPDATEDELETE 문장들의 유사-구문은 다음과 같다: ( UPDATE | DELETE ) FROM? ClassName (WHERE WHERE_CONDITIONS)?. 노트할 몇 가지 :

  • from-절에서, FROM 키워드는 옵션이다
  • from-절 내에 명명된 한 개의 클래스가 오직 존재할 수 있고,alias를 가질 수 없다.
  • join들은 (함축적이든 명시적이든) 대량 HQL 질의 속에 지정될 수 없다. 서브-질의들은 where-절 속에서 사용될 수 있다.
  • where-절 또한 옵션이다.

하나의 예제로서, 한 개의 HQL UPDATE를 실행하기 위해, Query.executeUpdate() 메소드를 사용하라:

Session session = sessionFactory.openSession();
        Transaction tx = session.beginTransaction();

        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();

한 개의 HQL DELETE를 실행하기 위해, 동일한 Query.executeUpdate() 메소드를 사용하라(그 메소드는 JDBC의 PreparedStatement.executeUpdate()에 친숙한 사람들을 위해 명명된다):

Session session = sessionFactory.openSession();
        Transaction tx = session.beginTransaction();

        String hqlDelete = "delete Customer where name = :oldName";
        int deletedEntities = s.createQuery( hqlDelete )
                            .setString( "oldName", oldName )
                            .executeUpdate();
        tx.commit();
        session.close();

Query.executeUpdate() 메소드에 의해 반환되는 int 값은 그 오퍼레이션에 의해 영향받은 엔티티들의 개수를 나타낸다. 이것이 데이터베이스 내에서 영향받은 행들의 개수와 상관이 있는지 없는지 여부를 살펴보자. HQL 대량 오퍼레이션은 예를 들어 joined-subclass의 경우에 실행 중인 여러 개의 실제 SQL 문장들로 귀결될 수 있다. 반환되는 숫자는 그 문장에 의해 영향받은 실제 엔티티들의 개수를 나타낸다. joined-subclass 예제로 되돌아가면, 서브 클래스들 중 하나에 대한 삭제는 단지 그 서브클래스가 매핑되어 있는 테이블에 대한 삭제 뿐만 아니라 또한 "루트" 테이블과 상속 계층에서 더 내려온 잠정적으로 조인된-서브클래스 테이블들에 대한 삭제들로 귀결될 수 있다.

장래의 배포본들에서 전달될 대량 HQL 오퍼레이션들에 대한 몇 가지 제한들이 현재 존재함을 노트하라; 상세한 것은 JIRA 로드맵을 참조하라.

 14 장. HQL: Hibernate Query Language

Hibernatesms (매우 의도적으로) SQL과 매우 유사한 극히 강력한 질의 언어를 구비하고 있다. 그러나 그 구문에 의해 우롱당하지 말라; HQL은 상속, 다형성 그리고 연관과 같은 개념들을 이해하는, 전체적으로 객체 지향적이다.

14.1. 대소문자 구분

질의들은 Java 클래스들과 프로퍼티들의 이름들을 제외하면 대소문자를 구분하지 않는다. 따라서 SeLeCTsELEct과 같고 SELECT과도 같지만 org.hibernate.eg.FOOorg.hibernate.eg.Foo와 같지 않고 foo.barSetfoo.BARSET과 같지 않다.

이 매뉴얼은 소문자 HQL 키워드를 사용한다. 몇몇 사용자들은 보다 나은 가독성을 위해 대문자 키워드들을 가진 질의들을 찾지만, 우리는 자바 코드 속에 삽입할 때  이 컨벤션이 추하다는 점을 발견한다.

14.2. from 절

가장 간단한 가능한 Hibernate 질의는 다음 형식이다:

from eg.Cat

이것은 eg.Cat 클래스의 모든 인스턴스들을 간단하게 반환한다. 우리는 대개 클래스 이름을 수식할 필요가 없다. 왜냐하면, auto-import 가 디폴트이기 때문이다. 따라서 우리는 대개 항상 단지 다음과 같이 작성한다:

from Cat

대개 당신은 한 개의 alias를 할당할 필요가 있을 것이다. 왜냐하면 당신은 질의의 다른 부분들에서 Cat을 참조하고자 원할 것이기 때문이다.

from Cat as cat

이 질의는 alias catCat 인스턴스들에 할당하여서, 우리는 나중에 질의 속에서 그 alias를 사용할 수 있을 것이다. 키워드 as 는 옵션이다; 우리는 또한 다음과 같이 작성할 수 있다:

from Cat cat

여러 개의 클래스들은 cartesian product(카티젼 곱) 또는 "cross" join 으로 귀결되어 나타날 수도 있다.

from Formula, Parameter
from Formula as form, Parameter as param

로컬 변수들에 대한 Java 네이밍 표준들과 일치되게, 첫 소문자를 사용하여 질의 alias들을 명명하는 것은 좋은 습관으로 간주된다(예를 들면 domesticCat).

14.3. 연관들과 join들

우리는 또한 join을 사용하여 , alias들을 연관된 엔티티들 또는 값들을 가진 콜렉션의 요소들에도  할당할 수도 있다.

from Cat as cat 
    inner join cat.mate as mate
    left outer join cat.kittens as kitten
from Cat as cat left join cat.mate.kittens as kittens
from Formula form full join form.parameter param

지원되는 join 타입들은 ANSI SQL로부터 빌려왔다

  • inner join
  • left outer join
  • right outer join
  • full join (대개 유용하지 않음)

inner join, left outer join , right outer join 구조체들이  약칭될 수 있다.

from Cat as cat 
    join cat.mate as mate
    left join cat.kittens as kitten

게다가, "fetch" join은 값들을 가진 콜렉션들이나 연관관계들이 하나의 select를 사용하여, 그것들의 부모 객체들과 함께 초기화 되는 것을 허용해준다. 이것은 콜렉션의 경우에 특히 유용하다. 그것은 연관관계들과 콜렉션들에 대한 매핑 파일의 outer join과 lazy 선언들을 효율적으로 오버라이드 시킨다. 추가 정보는 19.1절, “페칭 방도들”를 보라.

from Cat as cat 
    inner join fetch cat.mate
    left join fetch cat.kittens

fetch join은 대개 alias를 할당할 필요가 없다. 왜냐하면, 연관된 객체들이  where 절(또는 어떤 다른 절) 속에 사용되지 않을 것이기 때문이다. 또한 연관된 객체들은  질의 결과들 속에 직접 반환되지 않는다. 대신에 그것들은 부모 객체를 통해 접근될 수  있다. 

현재의 구현에서는 오직 한 개의 콜렉션 role 만이 질의 속에 join 페치될 수 있음을 노트하라(하나 이상의 role은 대개 한 개의 cartesian product로 귀결될 것이다). 또한 fetch 구조체는 scroll() 또는 iterate()를 사용하여 호출된 질의들 속에서 사용될 수 없음을 노트하라. 마지막으로 full join fetchright join fetch는 무의미함을 노트하라. 

만일 당신이 (바이트코드 방편으로) property-레벨 lazy 페칭을 사용할 경우, Hibernate로 하여금 fetch all properties를 사용하여 (첫 번째 질의 속에서) lazy 프로퍼티들을 즉시 페치하도록 강제시키는 것이 가능하다. 

from Document fetch all properties order by name
from Document doc fetch all properties where lower(doc.name) like '%cats%'

14.4. select 절

select 절은 질의 결과 셋 속에서 어느 객체들과 프로퍼티들을 반환할 것인지를 골라낸다. 다음을 검토하자:

select mate 
from Cat as cat 
    inner join cat.mate as mate

질의는 다른 Cat들의 mate들을 select 할 것이다.  실제로 당신은 이 질의들을 다음과 같이 보다 축약형으로 표현할수도 있다:

select cat.mate from Cat cat

질의들은 컴포넌트 타입의 프로퍼티들을 포함하여 임의의 값 타입의 프로퍼티들을 반환할 수도 있다:

select cat.name from DomesticCat cat
where cat.name like 'fri%'
select cust.name.firstName from Customer as cust

Family 클래스가 적당한 생성자를 갖고 있음을 가정하면, 질의들은 여러 객체들 과/또는 프로퍼티들을 Object[] 타입의 배열로서

select mother, offspr, mate.name 
from DomesticCat as mother
    inner join mother.mate as mate
    left outer join mother.kittens as offspr

또는 List로서

select new list(mother, offspr, mate.name)
from DomesticCat as mother
    inner join mother.mate as mate
    left outer join mother.kittens as offspr

또는 실제 typesafe 자바 객체로서

select new Family(mother, mate, offspr)
from DomesticCat as mother
    join mother.mate as mate
    left join mother.kittens as offspr

반환할 수도 있다.

당신은 as를 사용하여 select되는 표현식들에 alias들을 할당할 수 있다: 

select max(bodyWeight) as max, min(bodyWeight) as min, count(*) as n
from Cat cat

다음은 select new map과 함께 사용될 때 가장 유용하다:

select new map( max(bodyWeight) as max, min(bodyWeight) as min, count(*) as n )
from Cat cat

이 질의는 select된 값들에 대한 alias로부터 한 개의 Map을 반환한다.

14.5. 집계 함수들

HQL 질의들은 프로퍼티들에 대한 집계(aggregate) 함수들의 결과들을 반환할수도 있다:

select avg(cat.weight), sum(cat.weight), max(cat.weight), count(cat)
from Cat cat

지원되는 집계 함수들은 다음과 같다 

  • avg(...), sum(...), min(...), max(...)
  • count(*)
  • count(...), count(distinct ...), count(all...)

당신은 select 절 속에 산술 연산자들, 연결 연산자, 그리고 인지된 SQL 함수들을 사용할 수 있다:

select cat.weight + sum(kitten.weight) 
from Cat cat 
    join cat.kittens kitten
group by cat.id, cat.weight
select firstName||' '||initial||' '||upper(lastName) from Person

distinct워드와 all 키워드가 사용될 수 있고 SQL과 같은 의미를 갖는다.

select distinct cat.name from Cat cat

select count(distinct cat.name), count(cat) from Cat cat

14.6. Polymorphic 질의들

다음과 같은 질의:

from Cat as cat

Cat의 인스턴스들 뿐만 아니라, 또한 DomesticCat과 같은 서브클래스들 또한 반환한다. Hibernate 질의들은 from 절 내에 임의의 자바 클래스나 인터페이스를 명명할 수 있다. 질의는 그 클래스를 확장하거나 그 인터페이스를 구현하는 모든 영속 클래스들의 인스턴스들을 반환할 것이다. 다음 질의는 모든 영속 객체들을 반환할 것이다:

from java.lang.Object o

인터페이스 Named는 여러 가지 영속 클래스들에 의해 구현될 수도 있다:

from Named n, Named m where n.name = m.name

이들 마지막 두 개의 질의들은 하나 이상의 SQL SELECT를 필요로 할 것임을 노트하라. 이것은 order by 절이 정확하게 전체 결과 셋을 순서지우지 않음을 의미한다.(그것은 또한 당신이 Query.scroll()을 사용하여 이들 질의들을 호출할 수 없음을 의미한다).

14.7. The where clause

 where 절은 반환된 인스턴스들의 목록을 제한시키는 것을 당신에게 허용해준다. 만일 alias가 존재하지 않을 경우, 당신은 name에 의해 프로퍼티들을 참조할 수도 있다:

from Cat where name='Fritz'

만일 한 개의 alias가 존재할 경우, 하나의 수식어가 붙은 프로퍼티 이름을 사용하라:

from Cat as cat where cat.name='Fritz'

는 'Fritz'로 명명된 Cat 의 인스턴스들을 반환한다.

select foo 
from Foo foo, Bar bar
where foo.startDate = bar.date

FoostartDate 프로퍼티와 동일한 date 프로퍼티를 가진 bar의 인스턴스가 존재하는 Foo의 모든 인스턴스를 반환할 것이다. 합성 경로 표현식들은  where 절을 매우 강력하게 만들어준다. 다음을 검토하자:

from Cat cat where cat.mate.name is not null

이 질의는 테이블 (inner) join을 가진 SQL 질의로 번역된다. 만일 당신이 다음과 같은 어떤 것을 작성했다면

from Foo foo  
where foo.bar.baz.customer.address.city is not null

당신은 SQL에서 네 개의 테이블 join들을 필요로 하는 하나의 질의로 끝낼 것이다.

 = 연산자는 프로퍼티들 뿐만 아니라 또한 인스턴스들을 비교하는데 사용될 수 있다: 

from Cat cat, Cat rival where cat.mate = rival.mate
select cat, mate 
from Cat cat, Cat mate
where cat.mate = mate

특별한 프로퍼티(소문자) id는  객체의 유일 식별자를 참조하는데 사용될 수 있다.(당신은 또한 그것의 프로퍼티 이름을 사용할 수도 있다.)

from Cat as cat where cat.id = 123

from Cat as cat where cat.mate.id = 69

두 번째 질의가 효율적이다. 테이블 join이 필요 없다! 

composite identifier(합성 식별자)들의 프로퍼티들이 또한 사용될 수 있다. PersoncountrymedicareNumber로 구성된 composite identifier를 갖는다고 가정하자.

from bank.Person person
where person.id.country = 'AU' 
    and person.id.medicareNumber = 123456
from bank.Account account
where account.owner.id.country = 'AU' 
    and account.owner.id.medicareNumber = 123456

다시 한번, 두 번째 질의는 테이블 join을 필요로 하지 않는다.

마찬가지로, 특별한 프로퍼티 class는 다형성 영속성(polymorphic persistence)의 경우에 인스턴스의 판별자(discriminator) 값에 액세스한다. where 절 속에 삽입된 Java 클래스 이름은 그것의 판별자(discriminator) 값으로 번역될 것이다.

from Cat cat where cat.class = DomesticCat

당신은 또한 컴포넌트들 또는 composite 사용자 정의 타입들 (그리고 컴포넌트들의 컴포넌트들, 기타)의 프로퍼티들을 지정할 수도 있다. (컴포넌트의 프로퍼티와은 반대로) 컴포넌트 타입의 프로퍼티로 끝나는 경로-표현식을 사용하려고 결코 시도하지 말라. 예를 들어, 만일 store.owner가 컴포넌트 address 를 가진 엔티티일 경우

store.owner.address.city    // 옳다
store.owner.address         // 오류!

"임의의" 타입은 다음 방법으로 join을 표현하는 것을 우리에게 허용해주는, 특별한 프로퍼티들 idclass를 갖는다(여기서 AuditLog.item<any>로 매핑된 프로퍼티이다).

from AuditLog log, Payment payment 
where log.item.class = 'Payment' and log.item.id = payment.id

log.item.classpayment.class 는 위의 질의 내에서 완전히 다른 데이터베이스 컬럼들의 값들을 참조할 것임을 노트하라. 

14.8. 표현식들

where 절 속에 허용되는 표현식들은 당신이 SQL로 작성할 수 있는 대부분의 종류의 것들을 포함한다:

  • 산술 연산자들 +, -, *, /
  • 바이너리 비교 연산자들 =, >=, <=, <>, !=, like
  • 논리 연산들 and, or, not
  • 그룹핑을 나타내는 괄호들( )
  • in, not in, between, is null, is not null, is empty, is not empty, member of 그리고 not member of
  • "간단한" 경우, case ... when ... then ... else ... end, 그리고 "검색된" 경우, case when ... then ... else ... end
  • 문자열 연결 ...||... 또는 concat(...,...)
  • current_date(), current_time(), current_timestamp()
  • second(...), minute(...), hour(...), day(...), month(...), year(...),
  • EJB-QL 3.0에 의해 정의된 임의의 함수 또는 오퍼레이터: substring(), trim(), lower(), upper(), length(), locate(), abs(), sqrt(), bit_length()
  • coalesce() 그리고 nullif(), 기본 데이터베이스에 의해 지원될 경우 
  • cast(... as ...), 여기서 두번 째 아규먼트는 Hibernate 타입의 이름이고, ANSI cast()extract()가 기본 데이터베이스에 의해 지원될 경우에는 extract(... from ...)
  • sign(), trunc(), rtrim(), sin()과 같이 임의의 데이터베이스-지원 SQL 스칼라 함수
  • JDBC IN 파라미터들 ?
  • 명명된 파라미터들 :name, :start_date, :x1
  • SQL 리터럴들 'foo', 69, '1970-01-01 10:00:01.0'
  • Java public static final 상수들. 예를 들면.Color.TABBY

inbetween 은 다음과 같이 사용될 수 있다:

from DomesticCat cat where cat.name between 'A' and 'B'
from DomesticCat cat where cat.name in ( 'Foo', 'Bar', 'Baz' )

그리고 부정형들은 다음과 같이 작성될 수 있다 

from DomesticCat cat where cat.name not between 'A' and 'B'
from DomesticCat cat where cat.name not in ( 'Foo', 'Bar', 'Baz' )

마찬가지로, is null 과  is not null 은 null 값들을 테스트하는데 사용될 수 있다.

Boolean들은 Hibernate 구성에서 HQL 질의 치환들을 선언하여 표현식들 내에 쉽게 사용될 수 있다:

<property name="hibernate.query.substitutions">true 1, false 0</property>

이것은 키워드 truefalse 키워드들을 이 HQL로부터 번역된 SQL에서 리터럴 10로 대체될 것이다:

from Cat cat where cat.alive = true

당신은 특별한 프로퍼티 size로서 또는 특별한 size() 함수로서 콜렉션의 사이즈를 테스트할 수 있다.

from Cat cat where cat.kittens.size > 0
from Cat cat where size(cat.kittens) > 0

인덱싱된 콜렉션들에 대해, 당신은 minIndexmaxIndex를 사용하여 최대 인덱스과 최소 인덱스를 참조할 수 있다. 유사하게 당신은 minelement 함수와 maxelement 함수를 사용하여 기본 타입을 가진 콜렉션의 최소 요소 및 최대 요소를 참조할 수 있다.

from Calendar cal where maxelement(cal.holidays) > current date
from Order order where maxindex(order.items) > 100
from Order order where minelement(order.items) > 10000

SQL 함수들 any, some, all, exists, in 은 콜렉션의 요소 또는 인덱스 세트(elements 함수와 indices 함수), 또는 서브질의의 결과를 전달했을 때 지원된다(아래를 보라).

select mother from Cat as mother, Cat as kit
where kit in elements(foo.kittens)
select p from NameList list, Person p
where p.name = some elements(list.names)
from Cat cat where exists elements(cat.kittens)
from Player p where 3 > all elements(p.scores)
from Show show where 'fizard' in indices(show.acts)

이들 구조체들-size, elements, indices, minindex, maxindex, minelement, maxelement-은 Hibernate3에서 where 절 내에서만 사용될 것임을 노트하라.

인덱싱 된 콜렉션들의 요소들(배열들, 리스트들, map들)은 인덱스에 의해 참조될 수 있다(where 절 안에서만):

from Order order where order.items[0].id = 1234
select person from Person person, Calendar calendar
where calendar.holidays['national day'] = person.birthDay
    and person.nationality.calendar = calendar
select item from Item item, Order order
where order.items[ order.deliveredItemIndices[0] ] = item and order.id = 11
select item from Item item, Order order
where order.items[ maxindex(order.items) ] = item and order.id = 11

[] 내부의 표현식은 산술 표현실일 수 있다.

select item from Item item, Order order
where order.items[ size(order.items) - 1 ] = item

HQL은 또한  one-to-many 연관 또는 값들을 가진 콜렉션의 요소들에 대해 미리 만들어진 index()함수를 제공한다.

select item, index(item) from Order order 
    join order.items item
where index(item) < 5

기본 데이터베이스에 의해 제공되는 Scalar SQL 함수들이 사용될 수도 있다

from DomesticCat cat where upper(cat.name) like 'FRI%'

당신이 아직 이 모든 것을 납득하지 못한다면, 다음 질의가 SQL 내에서 가독성이 얼마나 많고 적은지를 생각해보라:

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)

힌트 : 다음과 같은 어떤 것

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
    )

14.9. order by 절

질의에 의해 반환된 리스트는 반환된 클래스 또는 컴포넌트들의 프로퍼티에 의해 순서(ordering)지워질 수 있다:

from DomesticCat cat
order by cat.name asc, cat.weight desc, cat.birthdate

asc 옵션 또는 desc 옵션은 각각 오름차순 또는 내림차순 정렬을 나타낸다. 

14.10. group by 절

aggregate 값들을 반환하는 질의는 반환된 클래스나 컴포넌트들의 프로퍼티에 의해 그룹지워질 수 있다:

select cat.color, sum(cat.weight), count(cat) 
from Cat cat
group by cat.color
select foo.id, avg(name), max(name) 
from Foo foo join foo.names name
group by foo.id

또한 having 절이 허용된다.

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)

SQL 함수들과 aggregate 함수들은 기본 데이터베이스에 의해 지원될 경우(예를 들어 MySQL은 지원되지 않는다) having 절과 order by 절 속에 허용된다.

select cat
from Cat cat
    join cat.kittens kitten
group by cat
having avg(kitten.weight) > 100
order by count(kitten) asc, sum(kitten.weight) desc

group by 절도 order by 절 어느 것도 산술 표현식들을 포함할 수 없다는 점을 노트하라.

14.11. 서브질의들

subselect들을 지원하는 데이터베이스들의 경우, Hibernate는 질의들 내에 서브질의들을 지원한다. 서브질의는 괄호에 의해 감싸져야 한다(자주 SQL 집계함수 호출에 의해). 심지어 서로 관련된 서브질의들(outer 질의 내에서 alias를 참조하는 서브질의들)이 허용된다. 

from Cat as fatcat 
where fatcat.weight > ( 
    select avg(cat.weight) from DomesticCat cat 
)
from DomesticCat as cat 
where cat.name = some ( 
    select name.nickName from Name as name 
)
from Cat as cat 
where not exists ( 
    from Cat as mate where mate.mate = cat 
)
from DomesticCat as cat 
where cat.name not in ( 
    select name.nickName from Name as name 
)

select 리스트 내에 있는 하나 이상의 표현식을 가진 서브질의들의 경우에 당신은 tuple 생성자를 사용할 수 있다:

from Cat as cat 
where not ( cat.name, cat.color ) in ( 
    select cat.name, cat.color from DomesticCat cat 
)

(Oracle 또는 HSQL이 아닌) 몇몇 데이터베이스들 상에서 당신은 다른 컨텍스트들 내에서, 예를 들면 component들이나 composite 사용자 타입들을 질의할 때 tuple 생성자들을 사용할 수 있음을 노트하라: 

from Person where name = ('Gavin', 'A', 'King')

이것을 더 풀어쓰면 다음과 동일하다:

from Person where name.first = 'Gavin' and name.initial = 'A' and name.last = 'King')

당신이 이런 종류의 것을 행하는 것을 원하지 않을 수 있는 두 가지 좋은 이유들이 존재한다: 첫 번째로 데이터베이스 플랫폼들 사이에 완전하게 이식성이 없다; 두 번째로 그 질의는 이제 매핑 문서 속에 있는 프로퍼티들의 순서에 의존한다.

14.12. HQL 예제들

Hibernate 질의들은 매우 강력하고 복잡할 수 있다. 사실, 질의 언어의 힘은 Hibernate의 주요 판매 포인트들 중 하나이다. 다음은 내가 최근의 프로젝트에서 사용했던 질의들과 매우 유사한 몇몇 예제 질의들이다. 당신이 작성하게 될 대부분의 질의들은 이것들보다 훨씬 간단하다는 점을 노트하라!

다음 질의는 결과들을 전체 합계값에 따라 순서지워서 특정 고객에 대한 모든 지불되지 않은 주문들의 주문 id, 항목들의 개수, 그리고 주문의 전체 합계값 그리고 주어진 최소 전체 합계를 반환한다. 가격 결정에 있어, 그것은 현재의 카타록을 사용한다. 귀결되는 SQL 질의는 ORDER, ORDER_LINE, PRODUCT, CATALOG, PRICE 테이블들에 대한 네 개의 inner 조인들과 한 개의(상관지워지지 않은) subselect를 갖고 있다.

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

괴물 같은 것! 실제로 실 생활에서, 나는 서브질의들을 매우 좋아하지 않아서, 나의 질의는 실제로 다음과 같았다:

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

다음 질의는 현재 사용자에 의해 가장 최근의 상태 변경이 행해졌던 AWAITING_APPROVAL 상태에 있는 모든 지불들을 제외한, 각각의 상태에 있는 지불들의 개수를 카운트 한다. 그것은 PAYMENT, PAYMENT_STATUS, PAYMENT_STATUS_CHANGE 테이블들에 대한 두 개의 inner 조인들과 하나의 상관관계 지워진 subselect를 가진 SQL 질의로 변환된다.

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

만일 내가 statusChanges 콜렉션을 set가 아닌 list로 매핑했다면, 그 질의는 작성하기가 훨씬 더 간단했을 것이다.

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

다음 질의는 현재의 사용자가 속해 있는 조직의 모든 계정들과 지불되지 않은 지불들을 반환하는데 MS SQL Server isNull() 함수를 사용한다. 그것은 ACCOUNT, PAYMENT, PAYMENT_STATUS, ACCOUNT_TYPE, ORGANIZATION, ORG_USER 테이블들에 대한 세 개의 inner 조인들, 하나의 outer 조인, 그리고 하나의 subselect를 가진 SQL 질의로 번역된다.

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

몇몇 데이터베이스들의 경우, 우리는 (상관관계 지워진) subselect를 없앨 필요가 있을 것이다.

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

14.13. 대량 UPDATE & DELETE 문장들

HQL은 이제 HQL에서 UPDATE 및 DELETE 문장들을 지원한다. 상세한 것은 13.3절, “대량 update/delete”를 보라.

14.14. 팁들 & 트릭들

당신은 실제로 질의 결과들을 반환하지 않고서 그것들(질의 결과들)의 개수를 카운트할 수  있다:

( (Integer) session.iterate("select count(*) from ....").next() ).intValue()

콜렉션의 크기에 따라 결과를 순서(ordering)지우려면, 다음 질의를 사용하라:

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)

만일 당신의 데이터베이스가 subselect들을 지원할 경우, 당신은 당신의 질의의 where 절 내에 selection 사이즈에 대한 조건을 위치지울 수 있다:

from User usr where size(usr.messages) >= 1

만일 당신의 데이터베이스가 subselect를 지원하지 않을 경우, 다음 질의를 사용하라:

select usr.id, usr.name
from User usr.name
    join usr.messages msg
group by usr.id, usr.name
having count(msg) >= 1

inner 조인 때문에 이 해결책이 0개의 메시지를 가진 User 를 반환할 수 없으므로,  다음 형식이 또한 유용하다:

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

하나의 JavaBean의 프로퍼티들은 명명된 질의 파라미터들에 바인드될 수 있다:

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();

콜렉션들은 필터를 가진 Query 인터페이스를 사용하여 쪼매김하는 것이 가능하다:

Query q = s.createFilter( collection, "" ); // the trivial filter
q.setMaxResults(PAGE_SIZE);
q.setFirstResult(PAGE_SIZE * pageNumber);
List page = q.list();

콜렉션 요소들은 질의 필터를 사용하여 순서(ordering)지워지거나 그룹지워질 수 도 있다:

Collection orderedCollection = s.filter( collection, "order by this.amount" );
Collection counts = s.filter( collection, "select this.type, count(this) group by this.type" );

당신은 콜렉션을 초기화 하지 않고서 그것(콜렉션)의 크기를 찾을 수 있다: 

( (Integer) session.iterate("select count(*) from ....").next() ).intValue();

 15 장. Criteria 질의들

Hibernate는 직관적인, 확장 가능한 criteria query API를 특징 짓는다.

15.1. Criteria 인스턴스 생성하기

org.hibernate.Criteria 인터페이스는 특정 영속 클래스에 대한 질의를 표현한다.  SessionCriteria 인스턴스들에 대한 팩토리이다. 

Criteria crit = sess.createCriteria(Cat.class);
crit.setMaxResults(50);
List cats = crit.list();

15.2. 결과 셋 제한하기

 

개별적인 질의 기준은  org.hibernate.expression.Criterion 인터페이스의 인스턴스이다.  org.hibernate.expression.Expression 클래스는 어떤 미리 만들어진 Criterion 타입들을 얻는 팩토리 메소드들을 정의한다.
List cats = sess.createCriteria(Cat.class)
    .add( Restrictions.like("name", "Fritz%") )
    .add( Restrictions.between("weight", minWeight, maxWeight) )
    .list();

제한들은 논리적으로 그룹지워질 수도 있다.

List cats = sess.createCriteria(Cat.class)
    .add( Restrictions.like("name", "Fritz%") )
    .add( Restrictions.or(
        Restrictions.eq( "age", new Integer(0) ),
        Restrictions.isNull("age")
    ) )
    .list();
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();

미리 만들어진 criterion 타입들(Restrictions 서브클래스들)의 영역이 꽤 존재하지만, 특히 유용한 것은 당신으로 하여금 SQL을 직접 지정하도록 해준다.

List cats = sess.createCriteria(Cat.class)
    .add( Restrictions.sql("lower({alias}.name) like lower(?)", "Fritz%", Hibernate.STRING) )
    .list();

질의된 엔티티의 행 alias에 의해 대체된 {alias} placeholder.

criterion을 얻는 대안적인 접근법은 Property 인스턴스로부터 그것을 얻는 것이다. 당신은 Property.forName()을 호출하여 Property를 생성시킬 수 있다.

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();

15.3. 결과들을 순서지우기(ordering)

당신은 org.hibernate.criterion.Order를 사용하여 결과들을 순서(ordering)지울 수 있다.

List cats = sess.createCriteria(Cat.class)
    .add( Restrictions.like("name", "F%")
    .addOrder( Order.asc("name") )
    .addOrder( Order.desc("age") )
    .setMaxResults(50)
    .list();
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();

15.4. 연관들

당신은 createCriteria()를 사용하여 연관들을 네비게이트함으로써 관계된 엔티티들에 대한 컨스트레인트들을 쉽게 지정할 수 있다.

List cats = sess.createCriteria(Cat.class)
    .add( Restrictions.like("name", "F%")
    .createCriteria("kittens")
        .add( Restrictions.like("name", "F%")
    .list();

두 번째 createCriteria()Criteria의 새로운 인스턴스를 반환하며, 그것은 kittens 콜렉션의 요소들을 참조한다는 점을 노트하라.

다음 대체 형식은 어떤 환경들에서 유용하다.

List cats = sess.createCriteria(Cat.class)
    .createAlias("kittens", "kt")
    .createAlias("mate", "mt")
    .add( Restrictions.eqProperty("kt.name", "mt.name") )
    .list();

(createAlias()Criteria의 새로운 인스턴스를 생성시키지 않는다. )

앞의 두 개의 질의들에 의해 반환된 Cat 인스턴스들에 의해 보관된  kittens 콜렉션들은 criteria에 의해 사전 필터링되지 않는다는 점을 노트하라! 만일 당신이 criteria(기준)과 일치하는 고양이 새끼들을 단지 검색하고자 원할 경우, 당신은 returnMaps()를 사용해야 한다.

List cats = sess.createCriteria(Cat.class)
    .createCriteria("kittens", "kt")
        .add( Restrictions.eq("name", "F%") )
    .returnMaps()
    .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");
}

15.5. 동적인 연관 페칭

당신은 setFetchMode()를 사용하여 실행 시에 연관 페칭 의미를 지정할 수 있다.

List cats = sess.createCriteria(Cat.class)
    .add( Restrictions.like("name", "Fritz%") )
    .setFetchMode("mate", FetchMode.EAGER)
    .setFetchMode("kittens", FetchMode.EAGER)
    .list();

이 질의는 outer 조인으로  mate와  kittens 모두를 페치할 것이다. 추가 정보는 19.1절, “페칭 방도들”을 보라.

15.6. 예제 질의들

org.hibernate.expression.Example 클래스는 주어진 인스턴스로부터 질의 기준(criterion)을 구조화 시키는 것을 당신에게 허용해준다. 

Cat cat = new Cat();
cat.setSex('F');
cat.setColor(Color.BLACK);
List results = session.createCriteria(Cat.class)
    .add( Example.create(cat) )
    .list();

버전 프로퍼티들, 식별자들, 연관관계들이 무시된다. 디폴트로 null 값 프로퍼티들이 제외된다.

당신은 Example 이 적용되는 방법을 조정할 수 있다.

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();

당신은 연관된 객체들에 대한 criteria(기준)을 위치지우는데 examples를 사용할 수 있다.

List results = session.createCriteria(Cat.class)
    .add( Example.create(cat) )
    .createCriteria("mate")
        .add( Example.create( cat.getMate() ) )
    .list();

15.7. Projections, aggregation 그리고 grouping

org.hibernate.criterion.Projections 클래스는 Projection 인스턴스들에 대한 팩토리이다. 우리는 setProjection()을 호출하여 질의에 projection(투사,투영)을 적용시킨다.

List results = session.createCriteria(Cat.class)
    .setProjection( Projections.rowCount() )
    .add( Restrictions.eq("color", Color.BLACK) )
    .list();
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();

criteria 질의 내에 필요한 명시적인 "group by"가 존재하지 않는다.어떤 projection 타입들은 grouping projection들이 되도록 정의되고, 그것은 또한 SQL group by 절 속에 나타난다.

투사된(projected) 값이 제한(restriction)들 또는 ordering들 내에서 참조될 수 있도록, alias는 선택적으로 projection에 할당될 수 있다. 다음은 이것을 행하는 두 개의 다른 방법들이다:

List results = session.createCriteria(Cat.class)
    .setProjection( Projections.alias( Projections.groupProperty("color"), "colr" ) )
    .addOrder( Order.asc("colr") )
    .list();
List results = session.createCriteria(Cat.class)
    .setProjection( Projections.groupProperty("color").as("colr") )
    .addOrder( Order.asc("colr") )
    .list();

alias() 메소드와 as() 메소드는 또 다른 alias된 Projection의 인스턴스 내에 projection 인스턴스를 간단하게 포장한다. 지금길로서, 당신이 projection을 projection 리스트에 추가할 때 당신은 alias를 할당할 수 있다:

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();
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();

당신은 또한 projection들을 표현하는데 Property.forName()을 사용할 수 있다:

List results = session.createCriteria(Cat.class)
    .setProjection( Property.forName("name") )
    .add( Property.forName("color").eq(Color.BLACK) )
    .list();
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();

15.8. Detached 질의들과 서브질의들

DetachedCriteria 클래스는 당신이 세션 영역의 외부에서 질의를 생성시키도록 하고, 그런 다음 나중에 어떤 임의의 Session을 사용하여 그것을 실행하도록 한다. 

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();

DetachedCriteria는 또한 서브질의를 표현하는데 사용된다. 서브질의들을 포함하는 Criterion 인스턴스들은 Subqueries 또는 Property를 통해 얻어질 수 있다.

DetachedCriteria avgWeight = DetachedCriteria.forClass(Cat.class)
	.setProjection( Property.forName("weight").avg() );
session.createCriteria(Cat.class)
	.add( Property.forName("weight).gt(avgWeight) )
	.list();
DetachedCriteria weights = DetachedCriteria.forClass(Cat.class)
	.setProjection( Property.forName("weight") );
session.createCriteria(Cat.class)
	.add( Subqueries.geAll("weight", weights) )
	.list();

심지어 상관관계 지워진 서브질의들이 가능하다:

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();

 16 장. Native SQL

당신은 또한 당신의 데이터베이스의 native SQL dialect로 질의들을 표현할 수도 있다. 당신이 오라클의 query hints 또는  CONNECT 키워드와 같은 데이터베이스 지정적인 특징들을 활용하고자 원할 경우에 이것이 유용하다. 그것은 또한 직접적인 SQL/JDBC 기반의 어플리케이션으로부터 Hibernate로의 보다 명료한 마이그레이션 경로를 제공한다.

Hibernate3은 또한 모든 create, update, delete, load 오퍼레이션들에 대해 (내장 프로시저들을 포함하여) 손으로 작성된 SQL을 지정하는 것을 당신에게 허용해준다.

16.1. native SQL Query 생성시키기

SQL 질의들은 SQLQuery 인터페이스를 통해 제어되고, 그것은 Session.createSQLQuery()를 호출하여 얻어진다.

List cats = sess.createSQLQuery("select {cat.*} from cats cat")
        .addEntity("cat", Cat.class);
        .setMaxResults(50);
        .list();

이 질의는 다음을 지정했다:

  • Hibernate가 컬럼 alias들을 삽입시키는 placeholder를 가진, SQL 질의 문자열
  • 그 질의에 의해 반환된 엔티티와 그것의 SQL 테이블 alias

addEntity() 메소드는 SQL 테이블 alias들을 엔티티 클래스들과 연관짓고, 질의 결과 셋의 형태를 결정한다.

addJoin() 메소드는 다른 엔티티들과 콜렉션들에 대한 연관들을 로드시키는데 사용될 수 있다. TODO: 예제들!

native SQL 질의는 간단한 스칼라 값 또는 스칼라들과 엔티티들의 조합을 반환할 수도 있다.

Double max = (Double) sess.createSQLQuery("select max(cat.weight) as maxWeight from cats cat")
        .addScalar("maxWeight", Hibernate.DOUBLE);
        .uniqueResult();

16.2. Alias 참조와 프로퍼티 참조

위에서 사용된 {cat.*} 표기는 "모든 프로퍼티"에 대한 축어이다. 다른 방법으로, 당신은 명시적으로 컬럼들을 리스트할 수 있지만, 심지어 그때 당신은 Hibernate로 하여금 각각의 프로퍼티에 대한 SQL 컬럼 alias들을 끼워넣도록 해야 한다. 컬럼 alias에 대한 placeholder들은 테이블 alias 수식어가 붙은 프로퍼티 이름이다. 다음 예제에서, 우리는 다른 테이블 (cat_log)로부터 매핑 메타데이터에 선언된 것으로 Cat들을 검색한다. 우리는 심지어 우리가 좋아할 경우 where 절 속에 프로퍼티 alias들을 사용할 수도 있음을 주목하라. {}-구문은 명명된 질의들에 필요하지 않다. 더많은 것은 16.3절, “Named SQL 질의들”를 보라.   

String sql = "select cat.originalId as {cat.id}, " +
    "cat.mateid as {cat.mate}, cat.sex as {cat.sex}, " +
    "cat.weight*10 as {cat.weight}, cat.name as {cat.name} " +
    "from cat_log cat where {cat.mate} = :catId"
    
List loggedCats = sess.createSQLQuery(sql)
    .addEntity("cat", Cat.class)
    .setLong("catId", catId)
    .list();

노트: 만일 당신이 각각의 프로퍼티를 명시적으로 리스트할 경우, 당신은 그 클래스와 그것의 서브클래스들의 모든 프로퍼티들을 포함해야 한다!

16.3. 명명된 SQL 질의들

명명된 SQL 질의들은 HQL 질의와 같은 방법으로 매핑 문서 속에 정의될 수 있고 정확하게 호출될 수도 있다. 이 경우에, 우리는 addEntity() 호출을 필요로 하지 않는다.

<sql-query name="mySqlQuery">
    <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 'Hiber%'
</sql-query>
List people = sess.getNamedQuery("mySqlQuery")
    .setMaxResults(50)
    .list();

명명된 SQL 질의는 스칼라 값을 반환할수도 있다. 당신은 <return-scalar> 요소를 사용하여 컬럼 alias와 Hibernate 타입을 지정해야 한다: 

<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>

<return-join> 요소와 <load-collection> 요소들은 각각 연관들을 조인시키는데 그리고 콜렉션들을 초기화 시키는 질의들을 정의하는데 사용된다. TODO!

16.3.1. 명시적으로 column/alias 이름들을 지정하는데 return-property 사용하기

Hibernate로 하여금 그것 자신의 alias들을 끼워넣도록 하기 위해 {}-구문을 사용하는 것과는 대조적으로, <return-property> 로 당신은 사용할 컬럼들이 무엇인지를 Hibernate에게 명시적으로 알려줄 수 있다.

<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>
<return-property> 는 또한 다중 컬럼들에 대해 동작한다. 이것은 다중-컬럼 프로퍼티들에 대한 fine grained 제어를 허용할 수 없는 {}-구문을 가진 제약을 해결해준다.
<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>

이 예제에서 우리는 끼워넣기를 위해 {}-구문과 함께 <return-property>를 사용했음을 주목하라. 사용자들이 컬럼과 프로퍼티들을 참조하고자 원하는 방법을 선택하는 것을 사용자들에게 허용해줌으로써. 

만일 당신의 매핑이 한 개의 판별자(discriminator )를 가질 경우 당신은 판별자 컬럼을 지정하는데 <return-discriminator>를 사용해야 한다.

16.3.2. 질의를 위한 내장 프로시저 사용하기

Hibernate 3은 내장 프로시저들을 통한 질의들에 대한 지원을 도입했다. 내장 프로시저들은 Hibernate와 작업하는 것이 가능하도록 첫 번째 출력-파라미터로서 한 개의 결과셋을 반환해야 한다. Oracle9 이상의 버전에서 그런 내장 프로시저에 대한 예제는 다음과 같다:

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;

Hibernate에서 이 질의를 사용하려면 당신은 하나의 명명된 질의(a named query)를 통해 그것을 매핑할 필요가 있다.

<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>

내장 프로시저들은 현재 스칼라들과 엔티티들 만을 반환함을 주목하라. <return-join><load-collection>은 지원되지 않는다.

16.3.2.1. 내장 프로시저들을 사용하는 규칙들/제약들

Hibernate에서 내장 프로시저들을 사용하기 위해서 프로시저들은 다음 몇몇 규칙들을 따라야 한다. 만일 그것들이 그들 규칙들을 따르지 않을 경우 그것들은 Hibernate와 함께 사용 불가능하다. 만일 당신이 여전히 이들 프로시저들을 사용하고자 원할 경우, 당신은 session.connection()을 통해 그것들을 실행시켜야 한다. 데이터베이스 벤더들이 다른 내장 프로시저 의미론/구문을 갖고 있기 때문에, 규칙들은 각각의 데이터베이스에 따라 차이가 난다.

Oracle의 경우 다음 규칙들이 적용된다:

  • 프로시저는 한 개의 결과 셋을 반환해야 한다. 이것은 Oracle 9 또는 10에서 한 개의 SYS_REFCURSOR를 반환함으로써 행해진다. Oracle에서 당신은 한 개의 REF CURSOR 타입을 정의할 필요가 있다. 
  • 권장되는 형식은 { ? = call procName(<parameters>) } 또는 { ? = call procName } 이다.(이것은 Hibernate 규칙 보다 더 많은 Oracle 규칙이다.)

Sybase 또는 MS SQL server의 경우 다음 규칙들이 적용된다:

  • 프로시저는 한 개의 결과 셋을 반환해야 한다. 이들 서버들은 여러 개의 결과셋들과 업데이트 카운트들을 반환할수 있다/할 것이다. Hibernate는 결과들을 반복순환할 것이고 그것의 반환 값으로서 하나의 결과 셋인 첫 번째 결과를 취할 것이다. 그 밖의 모든 것은 폐기될 것이다.
  • 만일 당신이 당신의 프로시저 내에 SET NOCOUNT ON을 이용 가능하게 할 수 있다면 그것은 아마 보다 효율적이게 될 것이지만 이것은 필요 조건이 아니다.

16.4. create, update, delete를 위한 맞춤형 SQL

Hibernate3는 create, update, delete 오퍼레이션들을 위한 맞춤형 문장들을 사용할 수 있다.  Hibernate에서 클래스와 콜렉션 영속자들은 구성 시에 생성된 문자열들의 집합(insertsql, deletesql, updatesql 등)을 이미 포함하고 있다. <sql-insert>, <sql-delete>, <sql-update> 매핑 태그들은 이들 문자열들을 오버라이드 시킨다:

<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>

SQL이 당신의 데이터베이스 내에서 직접 실행되어서, 당신이 좋아하는 임의의 dialect를 사용하는 것이 자유롭다. 만일 당신이 데이터베이스 지정적인 SQL을 사용하면 이것은 물론 당신의 매핑의 이식성을 감소시킬 것이다.

만일 callable 속성이 설정되면 내장 프로시저들이 지원된다:

<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>

위치 파라미터들은 Hibernate가 그것들을 기대하는 것과 동인한 순서가 되어야 하므로, 위치 파라미터들의 순서는 현재 절대적으로 중요하다.

당신은 org.hiberante.persister.entity 레벨로 디버그 로깅을 사용 가능하게 함으로써 예상된 순서를 볼 수 있다. 이 레벨을 이용 가능하게 하면 Hibernate는 엔티티들을 생성시키고, 업데이트하고, 삭제하는데 사용되는 정적인 SQL을 출력할 것이다. 예상된 순서를 보려면, Hibernate 생성된 정적인 sql을 오버라이드 시키게 매핑 파일들 속에 당신의 맞춤형 SQL을 포함시키지 않도록 염두에 두라.

내장 프로시저들은 Hibernate가 문장의 성공에 대해 몇몇 실행 시 체크들을 행할 때, 대부분의 경우들(읽기:아닌 경우들 보다 그것을 더 잘 행한다)에서 insert되고/업데이트되고/삭제된 행들의 개수를 반환하는데 필요하다. Hibernate는 항상 CUD 오퍼레이션들에 대한 숫자 출력 파라미터로서 첫 번째 문장 파라미터를 등록시킨다: 

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;

16.5. 로딩을 위한 맞춤형 SQL

당신은 또한 엔티티 로딩을 위한 당신 자신의 SQL (또는 HQL)을 선언할 수도 있다:

<sql-query name="person">
    <return alias="p" class="Person" lock-mode="upgrade"/>
    SELECT NAME AS {p.name}, ID AS {p.id} FROM PERSON WHERE ID=? FOR UPDATE
</sql-query>

이것은 앞서 논의했듯이 단지 명명된 질의 선언이다. 당신은 class 매핑 속에 이 명명된 질의를 참조할 수 있다:

<class name="Person">
    <id name="id">
        <generator class="increment"/>
    </id>
    <property name="name" not-null="true"/>
    <loader query-ref="person"/>
</class>

그리고 이것은 또한 내장 프로시저들에 동작한다.

TODO: 콜렉션 로더에 대한 다음 예제를 문서화 할 것.

<sql-query name="organizationEmployments">
    <load-collection alias="empcol" role="Organization.employments"/>
    SELECT {empcol.*}
    FROM EMPLOYMENT empcol
    WHERE EMPLOYER = :id
    ORDER BY STARTDATE ASC, EMPLOYEE ASC
</sql-query>

<sql-query name="organizationCurrentEmployments">
    <return alias="emp" class="Employment"/>
    <synchronize table="EMPLOYMENT"/>
    SELECT EMPLOYEE AS {emp.employee}, EMPLOYER AS {emp.employer},
        STARTDATE AS {emp.startDate}, ENDDATE AS {emp.endDate},
        REGIONCODE as {emp.regionCode}, ID AS {emp.id}
    FROM EMPLOYMENT
    WHERE EMPLOYER = :id AND ENDDATE IS NULL
    ORDER BY STARTDATE ASC
</sql-query>

17 장. 데이터 필터링하기

Hibernate3은 혁신적인 "가시성(visibility)" 규칙들로서 데이터를 처리하는 새로운 접근법을 제공한다. Hibernate 필터는 특정 Hibernate 세션에 대해 이용 가능하게 되거나 이용 불가능하게 될 수도 있는 전역, 명명된 파라미터화 된 필터이다.

17.1. Hibernate 필터들

Hibernate3은 필터 기준(criteria)을 미리 정의하고 그들 필터들을 클래스 레벨과 콜렉션 레벨 양자에서 첨부할 능력을 추가시킨다. 필터 기준(criteria)은 클래스 요소와 다양한 콜렉션 요소들에 대해 이용 가능한 기존의 "where" 속성과 매우 유사한 제한 절(restriction clause)을 정의하는 능력이다. 이것들을 제외하면 필터 조건들은 파라미터화 될 수 있다. 그때 어플리케이션은 주어진 필터들이 이용 가능한지 여부 그리고 그들 파라미터 값들이 무엇이어야 하는지를 실행 시에 결정할 수 있다. 필터들은 데이터베이스 뷰들 처럼 사용될 수 있지만, 어플리케이션 내부에 파라미터화 된다.

필터들을 사용하기 위해서, 그것들은 먼저 정의되고 나서 적절한 매핑 요소들에 첨가되어야 한다. 필터를 정의하기 위해, <hibernate-mapping/> 요소 내부에 <filter-def/> 요소를 사용하라:

<filter-def name="myFilter">
    <filter-param name="myFilterParam" type="string"/>
</filter-def>

그때 이 필터는 클래스에 첨가될 수 있다:

<class name="myClass" ...>
    ...
    <filter name="myFilter" condition=":myFilterParam = MY_FILTERED_COLUMN"/>
</class>

또는 콜렉션에 첨가될 수 있다:

<set ...>
    <filter name="myFilter" condition=":myFilterParam = MY_FILTERED_COLUMN"/>
</set>

또는 동시에 양자에(또는 각각의 쌍들에) 첨가될 수 있다.

Session 상의 메소드들은 다음과 같다: enableFilter(String filterName), getEnabledFilter(String filterName)disableFilter(String filterName). 디폴트로, 필터들은 주어진 세션에 대해 이용 가능하지 않다; 그것들은 Session.enabledFilter() 메소드의 사용을 통해 명시적으로 이용 가능하게 되어야 한다. Session.enabledFilter() 메소드는 Filter 인터페이스의 인스턴스를 반환한다. 위에 정의된 간단한 필터를 사용하면, 이것은 다음과 같을 것이다:

session.enableFilter("myFilter").setParameter("myFilterParam", "some-value");

org.hibernate.Filter 인터페이스 상의 메소드들은 Hibernate에 매우 공통된 method-chaining을 허용한다는 점을 노트하라. 

유효한 기록 날짜 패턴을 가진 시간 데이터를 사용하는 전체 예제 :

<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>

그때 당신이 현재 유효한 레코드들을 항상 얻는 것을 확실히 하기 위해, employee 데이터를 검색하기 전에 세션 상에 필터를 간단하게 이용 가능하게 하라:

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();

위의 HQL 에서, 심지어 비록 우리가 결과들에 대한 봉급 컨스트레인트를 명시적으로 언급만 했을지라도, 이용 가능한 필터 때문에 그 질의는 봉급이 백만달러 이상인 현재 채용중인 직원들만을 반환할 것이다.

노트: 만일 당신이 outer 조인에 대해 필터들을 사용할 경우 (HQL이든 로드 페칭이든) 조건 표현식의 방향을 주의하라. 이것을 left outer join으로 설정하는 것이 가장 안전하다; 일반적으로 파라미터는 오퍼레이터 뒤에 컬럼 이름(들)이 뒤따르는 첫번째에 위치지워라.

18장. XML 매핑

이것은 Hibernate3.0에서 실험적인 특징이고 매우 활동적으로 개발 중에 있음을 노트하라.

18.1. XML 데이터로 작업하기

Hibernate는 당신이 영속 POJO들로 작업하는 것과 동일한 방법으로 영속 XML 데이터에 작업하도록 해준다. 파싱된 XML 트리는 단지 객체 레벨에서 관계형 데이터를 나타내는 또 다른 방법으로 간주될 수 있다. 하나의 파싱된 XML 트리는 POJO들 대신, 객체 레벨에서 관계형 데이터를 표현하는 단지 또 다른 방법으로 간주될 수 있다.

 Hibernate는 XML 트리들을 처리하는 API로서 dom4j를 지원한다. 당신은 데이터베이스로부터 dom4j 트리들을 검색하고 당신이 그 트리를 데이터베이스로 자동적으로 동기화시키기 위해 어떤 변경을 행하도록 하는 질의들을 작성할 수 있다. 당신은 심지어 XML 문서를 취하고, dom4j를 사용하여 그것을 파싱하고, Hibernate의 다음 기본적인 오퍼레이션들 중 어떤 것으로 그것을 데이터베이스에 저장시킬 수 있다:   persist(), saveOrUpdate(), merge(), delete(), replicate() (merging(병합)은 아직 지원되지 않는다).

이 특징은 데이터 가져오기/내보내기,JMS 또는 SOAP 그리고 XSLT-기반의 레포팅을 통한 엔티티 데이터의 구체화를 포함하는 많은 어플리케이션들을 갖는다.

하나의 매피은 XML 문서의 클래스와 노드들의 프로퍼티들을 데이터베이스로 동시에 매핑시키는데 사용되거나, 만일 매핑할 클래스가 없을 경우, 그것은 단지 XML을 매핑시키는데 사용될 수도 있다.

이것은 Hibernate 3.0에서 실험적인 특징이고 매우 활성적으로 개발 중에 있음을 노트하라.

18.1.1. XML과 클래스 매핑을 함께 지정하기

다음은 POJO와 XML을 동시에 매핑하는 예제이다 :

<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>

18.1.2. XML 매핑만을 지정하기

다음은 POJO 클래스가 존재하는 예제이다:

<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>

이 매핑은 dom4j 트리로서 또는 프로퍼티 name/value 쌍들(java Map들)의 그래프로서 데이터에 접근하는 것을 당신에게 허용해준다. 프로퍼티 이름들은 HQL 질의들 내에서 참조될 수도 있는 순수하게 논리적인 구조체들이다.

18.2. XML 매핑 메타데이터

많은 Hibernate 매핑 요소들은  node 속성을 수용한다. 이것은 당신이 프로퍼티 또는 엔티티 데이터를 보관하는 XML 속성이나 요소의 이름을 지정하도록 한다. node 속성의 포맷은 다음 중 하나이어야 한다: 

  • "element-name" - 명명된 XML 요소로 매핑시킨다
  • "@attribute-name" - 명명된 XML 요소로 매핑시킨다
  • "." - 부모 요소로 매핑 시킨다
  • "element-name/@attribute-name" - 명명된 요소의 명명된 속성으로 매핑시킨다

콜렉션들과 단일 값 콜렉션들의 경우, 추가적인 embed-xml 속성이 존재한다. 만일 embed-xml="true" 일 경우, 연관된 엔티티(또는 value 타입을 가진 콜렉션)에 대한 디폴트 XML 트리는 그 연관을 소유하는 엔티티에 대한 XML 트리 속에 직접 삽입될 것이다. 그 밖의 경우 embed-xml="false" 일 경우, 참조된 identifier 값 만이 단일 포인트 연관들에 대해 나타날 것이고 콜렉션들은 단순히 전혀 나타나지 않을 것이다.

당신은 너무 많은 연관들에 대해 embed-xml="true"로 남겨두지 말도록 주의해야 한다. 왜냐하면 XML이 순환적으로 잘 처리하지 못하기 때문이다!

<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/@id"/>
    </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>

이 경우에, 우리는 account id들을 가진 콜렉션을 삽입시키기로 결정했지만, 실제 account 데이터에 대해서는 아니다. 다음 HQL 질의:

from Customer c left join fetch c.accounts where c.lastName like :lastName

는 다음과 같은 데이터셋들을 반환할 것이다:

<customer id="123456789">
    <account id="987632567" short-desc="Savings"/>
    <account id="985612323" short-desc="Credit Card"/>
    <name>
        <first-name>Gavin</first-name>
        <initial>A</initial>
        <last-name>King</last-name>
    </name>
    ...
</customer>

만일 당신이 <one-to-many> 매핑에 대해 embed-xml="true" 를 설정할 경우, 데이터는 다음과 같이 보일 수도 있다:

<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>

18.3. XML 데이터 처리하기

우리의 어플리케이션 내에서 XML 문서들을 다시 읽어들이고 업데이트 시키자. 우리는 dom4j 세션을 얻어서 이것을 행한다:

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++ ) {
    // 고객 데이터를 XML 문서에 추가한다 
    Element customer = (Element) results.get(i);
    doc.add(customer);
}

tx.commit();
session.close();
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);
    // XML과 데이터베이스에서 고객 이름을 변경시킨다
    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();

XML 기반의 데이터 가져오기/내보내기를 구현하는데 Hibernate의 replicate() 오퍼레이션과 이 특징을 결합시키는 것이 매우 유용하다.

 19 장. 퍼포먼스 개선하기

19.1. 페칭 방도들

페칭 방도는 어플리케이션이 연관을 네비게이트할 필요가 있을 때 Hibernate가 연관된 객체들을 검색하는데 사용하게 될 방도이다.페치 방도들은 O/R 매핑 메타데이터 내에서 선언될 수 있거나 하나의 특정 HQL 또는 Criteria 질의에 의해 오버라이드 될 수도 있다.

Hibernate3는 다음 페칭 방도들을 정의한다:

  • Join 페칭 - Hibernate는 OUTER JOIN을 사용하여 연관된 인스턴스 또는 동일한 SELECT 내에서 콜렉션을 검색한다.
  • Select 페칭 - 두 번째 SELECT는 연과된 엔티티 또는 콜렉션을 검색하는데 사용된다. 당신이 lazy="false"를 지정함으로써 명시적으로 lazy 페칭을 사용 불가능하게 하지 않는 한, 이 두 번째 select는 당신이 그 연관에 실제로 액세스할 때 오직 실행될 것이다.
  • Subselect 페칭 - 두 번째 SELECT는 이전 질의 또는 페치에서 검색된 모든 엔티티들에 대해 연관된 콜렉션들을 검색하는데 사용된다. 당신이 lazy="false"를 지정하여 명시적으로 lazy 페칭을 사용 불가능하게 하지 않는 한, 이 두 번째 select는 당신이 실제로 그 연관에 접근할 때 오직 실행될 것이다. 
  • Batch 페칭 - select 페칭을 위한 최적화 방도 - Hibernate는 프라이머리 키들이나 foreign 키들의 리스트를 지정함으로써 하나의 SELECT 내에서 엔티티 인스턴스들이나 콜렉션들에 대한 batch를 검색한다.

디폴트로, Hibernate3은 lazy select 페칭을 사용하고, 그것은 대부분의 어플리케이션들 내에 있는 대부분의 엔티티들과 콜렉션들에 대한 최상의 선택이다. 만일 당신이 hibernate.default_batch_fetch_size를 설정하면, Hibernate는 lazy 페칭에 대해 batch 페치 최적화를 사용할 것이다(이 최적화는 더 많은 과립상의 레벨(a more granular level)에서 이용 가능할 수 있다).

하지만 알아야 할 한가지 문제가 존재한다. 열려진 Hibernate 세션의 컨텍스트 외부에서 lazy 연관에 대한 접근은 예외상황으로 귀결될 것이다. 예를 들면:

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");  // 오류!

Session이 닫혔을 때 permissions 콜렉션이 초기화 되지 않았으므로, 그 콜렉션은 그것의 상태를 로드시킬 수가 없을 것이다.  Hibernate 는 detached 객체들에 대해 lazy 초기화를 지원하지 않는다.  정정은 콜렉션으로부터 읽어들이는 코드를 커밋 바로 앞으로 이동시키는 것이다. (이 문제를 해결하는 다른 보다 개선된 방법들이 존재하는데, 몇몇은 나중에 논의된다.)

고유하게 lazy가 아닌 콜렉션 또는 lazy가 아닌 join 페칭을 사용하는 것이 또한 가능하다. 하지만 lazy 초기화는 거의 모든 콜렉션들 특히 엔티티 참조들을 가진 콜렉션들에 대해 사용되게 고안되었다. 만일 당신이 당신의 객체 모형 내에 너무 많은 non-lazy 연관들을 정의할 경우, Hibernate는 모든 트랜잭션에서 전체 데이터베이스를 메모리 속으로 페치하는 것을 필요로 하게 될 것이다!

다른 한편으로, 우리는 특정 트랜잭션 내에서 select 페칭 대신에 (고유하게 non-lazy