performance.po

hibernate 开源框架的代码 jar包希望大家能喜欢

#: performance.xml:172
#, no-c-format
msgid ""
"Select fetching (the default) is extremely vulnerable to N+1 selects "
"problems, so we might want to enable join fetching in the mapping document:"
msgstr ""
"select 페칭(디폴트)은 N+1 selects 문제점들에 매우 취약해서, 우리는 매핑 문서"
"에서 join 페칭을 사용 가능하게 하기를 원할 수도 있다:"

#. Tag: programlisting
#: performance.xml:177
#, no-c-format
msgid ""
"<![CDATA[<set name=\"permissions\" \n"
"            fetch=\"join\">\n"
"    <key column=\"userId\"/>\n"
"    <one-to-many class=\"Permission\"/>\n"
"</set]]>"
msgstr ""

#. Tag: programlisting
#: performance.xml:179
#, no-c-format
msgid "<![CDATA[<many-to-one name=\"mother\" class=\"Cat\" fetch=\"join\"/>]]>"
msgstr ""

#. Tag: para
#: performance.xml:181
#, no-c-format
msgid ""
"The <literal>fetch</literal> strategy defined in the mapping document "
"affects:"
msgstr ""
"매핑 문서 내에 정의된 <literal>fetch</literal> 방도는 다음에 영향을 준다:"

#. Tag: para
#: performance.xml:187
#, no-c-format
msgid "retrieval via <literal>get()</literal> or <literal>load()</literal>"
msgstr "<literal>get()</literal> 또는 <literal>load()</literal>를 통한 검색"

#. Tag: para
#: performance.xml:192
#, no-c-format
msgid "retrieval that happens implicitly when an association is navigated"
msgstr "연관이 네비게이트될 때 함축적으로 발생하는 검색"

#. Tag: para
#: performance.xml:197
#, no-c-format
msgid "<literal>Criteria</literal> queries"
msgstr "<literal>Criteria</literal> 질의들"

#. Tag: para
#: performance.xml:202
#, no-c-format
msgid "HQL queries if <literal>subselect</literal> fetching is used"
msgstr "<literal>subselect</literal> 페칭이 사용될 경우에 HQL 질의들"

#. Tag: para
#: performance.xml:208
#, no-c-format
msgid ""
"No matter what fetching strategy you use, the defined non-lazy graph is "
"guaranteed to be loaded into memory. Note that this might result in several "
"immediate selects being used to execute a particular HQL query."
msgstr ""
"당신이 사용하는 페칭 방도가 무엇인가에 상관없이, 정의된 비-lazy 그래프가 메모"
"리 내로 로드되는 것이 보장된다. 이것은 하나의 특별한 HQL 질의를 실행시키는데 "
"사용되는 몇몇 즉시적인 select들로 귀결될 수 있음을 노트하라."

#. Tag: para
#: performance.xml:214
#, no-c-format
msgid ""
"Usually, we don't use the mapping document to customize fetching. Instead, "
"we keep the default behavior, and override it for a particular transaction, "
"using <literal>left join fetch</literal> in HQL. This tells Hibernate to "
"fetch the association eagerly in the first select, using an outer join. In "
"the <literal>Criteria</literal> query API, you would use "
"<literal>setFetchMode(FetchMode.JOIN)</literal>."
msgstr ""
"대개, 우리는 페칭을 맞춤화 시키는데 매핑 문서를 사용하지 않는다. 대신에, 우리"
"는 디폴트 특징을 유지하고, HQL에서 <literal>left join fetch</literal>를 사용"
"하여, 특정 트랜잭션에 대해 그것을 오버라이드 시킨다. 이것은 outer join을 사용"
"하여 첫 번째 select에서 초기에 그 연관을 eagerly 페치시킬 것을 Hibernate에게 "
"알려준다. <literal>Criteria</literal> query API에서, 우리는 "
"<literal>setFetchMode(FetchMode.JOIN)</literal>을 사용한다."

#. Tag: para
#: performance.xml:223
#, no-c-format
msgid ""
"If you ever feel like you wish you could change the fetching strategy used "
"by <literal>get()</literal> or <literal>load()</literal>, simply use a "
"<literal>Criteria</literal> query, for example:"
msgstr ""
"만일 당신이 <literal>get()</literal> 또는 <literal>load()</literal>에 의해 사"
"용된 페칭 방도를 변경시킬 수 있기를 당신이 원한다고 느낄 경우, 단순하게 "
"<literal>Criteria</literal> 질의를 사용하라. 예를 들면:"

#. Tag: programlisting
#: performance.xml:229
#, no-c-format
msgid ""
"<![CDATA[User user = (User) session.createCriteria(User.class)\n"
"                .setFetchMode(\"permissions\", FetchMode.JOIN)\n"
"                .add( Restrictions.idEq(userId) )\n"
"                .uniqueResult();]]>"
msgstr ""

#. Tag: para
#: performance.xml:231
#, no-c-format
msgid ""
"(This is Hibernate's equivalent of what some ORM solutions call a \"fetch "
"plan\".)"
msgstr ""
"(이것은 몇몇 ORM 솔루션들이 \"페치 계획\"이라고 부르는 것에 대한 Hibernate의 "
"등가물이다.)"

#. Tag: para
#: performance.xml:235
#, no-c-format
msgid ""
"A completely different way to avoid problems with N+1 selects is to use the "
"second-level cache."
msgstr ""
"N+1 개의 select들을 가진 문제점들을 피하는 완전히 다른 방법은 second-level 캐"
"시를 사용하는 것이다."

#. Tag: title
#: performance.xml:243
#, no-c-format
msgid "Single-ended association proxies"
msgstr "Single-ended 연관 프락시"

#. Tag: para
#: performance.xml:245
#, no-c-format
msgid ""
"Lazy fetching for collections is implemented using Hibernate's own "
"implementation of persistent collections. However, a different mechanism is "
"needed for lazy behavior in single-ended associations. The target entity of "
"the association must be proxied. Hibernate implements lazy initializing "
"proxies for persistent objects using runtime bytecode enhancement (via the "
"excellent CGLIB library)."
msgstr ""
"콜렉션들에 대한 Lazy 페칭은 영속 콜렉션들에 대한 Hibernate 자신의 구현을 사용"
"하여 구현된다. 하지만 다른 메커니즘은 single-ended 연관들에서 lazy 특징에 필"
"요하다. 연관의 대상 엔티티는 프락시 되어야 한다. Hibernate는 (훌륭한 CGLIB 라"
"이브러리를 통해) 런타임 바이트코드 증진을 사용하여 영속 객체들에 대한 lazy 초"
"기화 프락시들을 구현한다."

#. Tag: para
#: performance.xml:253
#, no-c-format
msgid ""
"By default, Hibernate3 generates proxies (at startup) for all persistent "
"classes and uses them to enable lazy fetching of <literal>many-to-one</"
"literal> and <literal>one-to-one</literal> associations."
msgstr ""
"디폴트로, Hibernate3는 모든 영속 클래스들에 대해 (시작 시에) 프락시들을 생성"
"시키고 <literal>many-to-one</literal> 연관과 <literal>one-to-one</literal> 연"
"관에 대해 lazy 페칭을 이용 가능하게 하는데 그것들을 사용한다."

#. Tag: para
#: performance.xml:259
#, no-c-format
msgid ""
"The mapping file may declare an interface to use as the proxy interface for "
"that class, with the <literal>proxy</literal> attribute. By default, "
"Hibernate uses a subclass of the class. <emphasis>Note that the proxied "
"class must implement a default constructor with at least package visibility. "
"We recommend this constructor for all persistent classes!</emphasis>"
msgstr ""
"매핑 파일은 그 클래스에 대한 프락시 인터페이스로서 사용할, <literal>proxy</"
"literal> 속성을 가진, 인터페이스를 선언할 수도 있다. 디폴트로 Hibernate는 그 "
"클래스의 서브클래스를 사용한다. <emphasis>프락시된 클래스는 최소한의 패키지 "
"가시성 (visibility)을 가진 디폴트 생성자를 구현해야 함을 노트하라. 우리는 모"
"든 영속 클래스들에 대해 이 생성자를 권장한다!</emphasis>"

#. Tag: para
#: performance.xml:266
#, no-c-format
msgid ""
"There are some gotchas to be aware of when extending this approach to "
"polymorphic classes, eg."
msgstr ""
"다형성 클래스들에 대해 이 접근법을 확장할 때 의식해야 하는 몇몇 난처함들이 존"
"재한다. 예를 들면."

#. Tag: programlisting
#: performance.xml:271
#, no-c-format
msgid ""
"<![CDATA[<class name=\"Cat\" proxy=\"Cat\">\n"
"    ......\n"
"    <subclass name=\"DomesticCat\">\n"
"        .....\n"
"    </subclass>\n"
"</class>]]>"
msgstr ""

#. Tag: para
#: performance.xml:273
#, no-c-format
msgid ""
"Firstly, instances of <literal>Cat</literal> will never be castable to "
"<literal>DomesticCat</literal>, even if the underlying instance is an "
"instance of <literal>DomesticCat</literal>:"
msgstr ""
"첫 번째로, 심지어 기본 인스턴스가 <literal>DomesticCat</literal>의 인스턴스"
"인 경우조차도, <literal>Cat</literal>의 인스턴스들은 결코 "
"<literal>DomesticCat</literal>으로 타입캐스트가 가능하지 않을 것이다:"

#. Tag: programlisting
#: performance.xml:279
#, no-c-format
msgid ""
"<![CDATA[Cat cat = (Cat) session.load(Cat.class, id);  // instantiate a "
"proxy (does not hit the db)\n"
"if ( cat.isDomesticCat() ) {                  // hit the db to initialize "
"the proxy\n"
"    DomesticCat dc = (DomesticCat) cat;       // Error!\n"
"    ....\n"
"}]]>"
msgstr ""

#. Tag: para
#: performance.xml:281
#, no-c-format
msgid "Secondly, it is possible to break proxy <literal>==</literal>."
msgstr "두번째로, 프락시 <literal>==</literal>를 파기할 가능성이 있다."

#. Tag: programlisting
#: performance.xml:285
#, no-c-format
msgid ""
"<![CDATA[Cat cat = (Cat) session.load(Cat.class, id);            // "
"instantiate a Cat proxy\n"
"DomesticCat dc = \n"
"        (DomesticCat) session.load(DomesticCat.class, id);  // acquire new "
"DomesticCat proxy!\n"
"System.out.println(cat==dc);                            // false]]>"
msgstr ""

#. Tag: para
#: performance.xml:287
#, no-c-format
msgid ""
"However, the situation is not quite as bad as it looks. Even though we now "
"have two references to different proxy objects, the underlying instance will "
"still be the same object:"
msgstr ""
"하지만, 그 경우는 보이는 만큼 그렇게 나쁘지는 않다. 심지어 우리가 이제 다른 "
"프락시 객체들에 대한 두 개의 참조를 가질지라도, 기본 인스턴스는 여전히 동일"
"한 객체들일 것이다:"

#. Tag: programlisting
#: performance.xml:292
#, no-c-format
msgid ""
"<![CDATA[cat.setWeight(11.0);  // hit the db to initialize the proxy\n"
"System.out.println( dc.getWeight() );  // 11.0]]>"
msgstr ""

#. Tag: para
#: performance.xml:294
#, no-c-format
msgid ""
"Third, you may not use a CGLIB proxy for a <literal>final</literal> class or "
"a class with any <literal>final</literal> methods."
msgstr ""
"세번째로, 당신은 <literal>final</literal> 클래스 또는 임의의 <literal>final</"
"literal> 메소드들을 가진 클래스에 대해 CGLIB 프락시를 사용하지 않을 수 있다."

#. Tag: para
#: performance.xml:299
#, no-c-format
msgid ""
"Finally, if your persistent object acquires any resources upon instantiation "
"(eg. in initializers or default constructor), then those resources will also "
"be acquired by the proxy. The proxy class is an actual subclass of the "
"persistent class."
msgstr ""
"마지막으로, 만일 당신의 영속 객체가 초기화 시에 어떤 리소스들을 필요로 할 경"
"우(예를 들어, initializer들 또는 디폴트 생성자 내에서), 그때 그들 리소스들이 "
"또한 프락시에 의해 획득될 것이다. 프락시 클래스는 영속 클래스에 대한 실제 서"
"브클래스이다."

#. Tag: para
#: performance.xml:305
#, no-c-format
msgid ""
"These problems are all due to fundamental limitations in Java's single "
"inheritance model. If you wish to avoid these problems your persistent "
"classes must each implement an interface that declares its business methods. "
"You should specify these interfaces in the mapping file. eg."
msgstr ""
"이들 문제점들은 모두 자바의 단일 상속 모형의 기본적인 제약 때문이다. 만일 당"
"신이 이들 문제점들을 피하고자 원할 경우 당신의 영속 클래스들은 각각 그것의 비"
"지니스 메소드들을 선언하는 인터페이스를 구현해야 한다. 당신은 매핑 파일 속에 "
"이들 인터페이스들을 지정해야 한다. 예를 들면."

#. Tag: programlisting
#: performance.xml:311
#, no-c-format
msgid ""
"<![CDATA[<class name=\"CatImpl\" proxy=\"Cat\">\n"
"    ......\n"
"    <subclass name=\"DomesticCatImpl\" proxy=\"DomesticCat\">\n"
"        .....\n"
"    </subclass>\n"
"</class>]]>"