Hibernate example source code file (example_parentchild.po)

This example Hibernate source code file (example_parentchild.po) is included in the DevDaily.com "Java Source Code Warehouse" project. The intent of this project is to help you "Learn Java by Example" ^TM.

Java - Hibernate tags/keywords

hibernate, hibernate, however, in, null, sql, tag, tag, the, the, this, this, we, you

The Hibernate example_parentchild.po source code

msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2010-02-04T04:51:22\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Tag: title
#, no-c-format
msgid "Example: Parent/Child"
msgstr "예제: 부모/자식"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"One of the first things that new users want to do with Hibernate is to model "
"a parent/child type relationship. There are two different approaches to "
"this. The most convenient approach, especially for new users, is to model "
"both <literal>Parent and Child as entity "
"classes with a <literal><one-to-many> association from "
"<literal>Parent to Child. The alternative "
"approach is to declare the <literal>Child as a <"
"composite-element></literal>. The default semantics of a one-to-many "
"association in Hibernate are much less close to the usual semantics of a "
"parent/child relationship than those of a composite element mapping. We will "
"explain how to use a <emphasis>bidirectional one-to-many association with "
"cascades</emphasis> to model a parent/child relationship efficiently and "
"elegantly."
msgstr ""
"새로운 사용자들이 Hibernate로 행하고자 시도하는 바로 첫 번째 것들 중 하나는 "
"부모/자식 타입의 관계를 모형화 시키는 것이다. 이것에 대한 두 가지 다른 접근법"
"들이 존재한다. 여러가지 이유들로 인해 특히 새로운 사용자들에게 가장 편한 접근"
"법은 <literal>Parent로부터 Child로의 "
"<literal><one-to-many> 연관을 가진 엔티티 클래스들로서 "
"<literal>Parent와 Child 양자를 모형화 시키는 것"
"이다. (다른 접근법은 <literal>Child를 <composite-"
"element></literal>로 선언하는 것이다.) 이제, (Hibernate에서) one to many "
"연관에 대한 디폴트 의미는 composite 요소 매핑의 의미보다 부모/자식 관계의 통"
"상적인 의미에 훨씬 덜 가깝다는 것이 판명된다. 우리는 부모/자식 관계를 효율적"
"이고 강력하게 모형화 시키기 위해 <emphasis>케스케이드들을 가진 양방향 one to "
"many 연관</emphasis>을 사용하는 방법을 설명할 것이다. 그것은 전혀 어렵지 않"
"다!"

#. Tag: title
#, no-c-format
msgid "A note about collections"
msgstr "콜렉션들에 관한 노트"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Hibernate collections are considered to be a logical part of their owning "
"entity and not of the contained entities. Be aware that this is a critical "
"distinction that has the following consequences:"
msgstr ""
"Hibernate 콜렉션들은 그것들의 소유하고 있는 엔티티의 논리적 부분으로 간주된"
"다; 결코 포함된 엔티티들의 부분이 아니다. 이것은 중대한 구분점이다! 그것은 다"
"음은 다음 결과들을 갖는다:"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"When you remove/add an object from/to a collection, the version number of "
"the collection owner is incremented."
msgstr ""
"콜렉션으로부터 객체를 제거하고/콜렉션에 객체를 추가 시킬 때, 콜렉션 소유자의 "
"버전 번호가 증가된다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"If an object that was removed from a collection is an instance of a value "
"type (e.g. a composite element), that object will cease to be persistent and "
"its state will be completely removed from the database. Likewise, adding a "
"value type instance to the collection will cause its state to be immediately "
"persistent."
msgstr ""
"만일 콜렉션으로부터 제거되었던 객체가 하나의 값 타입의 인스턴스(예를 들어 "
"composite 요소)이면, 그 객체는 영속상태를 끝내고 그것의 상태가 데이터베이스로"
"부터 완전히 제거될 것이다. 마찬가지로 하나의 값 타입의 인스턴스를 콜렉션에 추"
"가시키는 것은 그것의 상태가 즉시 영속화 되도록 강제시킬 것이다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Conversely, if an entity is removed from a collection (a one-to-many or many-"
"to-many association), it will not be deleted by default. This behavior is "
"completely consistent; a change to the internal state of another entity "
"should not cause the associated entity to vanish. Likewise, adding an entity "
"to a collection does not cause that entity to become persistent, by default."
msgstr ""
"반면에, 만일 엔티티가 콜렉션으로부터 제거될 경우(one-to-many 또는 many-to-"
"many 연관), 그것은 디폴트로 삭제되지 않을 것이다. 이 특징은 완전하게 일관적이"
"다 - 다른 엔티티의 내부 상태에 대한 변경은 연관된 엔티티를 사라지도록 강제하"
"지 않을 것이다! 마찬가지로 콜렉션에 엔티티를 추가시키는 것은 디폴트로 그 엔티"
"티가 영속화 되도록 강제시키지 않는다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Adding an entity to a collection, by default, merely creates a link between "
"the two entities. Removing the entity will remove the link. This is "
"appropriate for all sorts of cases. However, it is not appropriate in the "
"case of a parent/child relationship. In this case, the life of the child is "
"bound to the life cycle of the parent."
msgstr ""
"대신에 콜렉션으로의 엔티티 추가가 두 엔티티들 사이에 단지 하나의 링크를 생성"
"시키는 반면에, 그것을 제거하는 것은 링크를 제거한다는 점이 디폴트 특징이다. "
"이것은 모든 종류의 경우들에 대해 매우 적절하다. 그것이 전혀 적절하지 않은 곳"
"은 부모/자식 관계인 경우이고, 여기서 자식의 생애는 부모의 생명주기에 묶여져 "
"있다."

#. Tag: title
#, no-c-format
msgid "Bidirectional one-to-many"
msgstr "ì–‘ë°©í–¥ one-to-many"

#. Tag: para
#, no-c-format
msgid ""
"Suppose we start with a simple <literal><one-to-many> "
"association from <literal>Parent to Child."
msgstr ""
"<literal>Parent로부터 Child로의 간단한 "
"<literal><one-to-many> 연관관계로 시작한다고 가정하자."

#. Tag: para
#, fuzzy, no-c-format
msgid "If we were to execute the following code:"
msgstr "우리가 다음 코드를 실행시켰다면"

#. Tag: para
#, no-c-format
msgid "Hibernate would issue two SQL statements:"
msgstr "Hibernate는 두 개의 SQL 문장들을 실행할 것이다:"

#. Tag: para
#, no-c-format
msgid ""
"an <literal>INSERT to create the record for c"
msgstr ""
"<literal>c에 대한 레코드를 생성시키는 INSERT"

#. Tag: para
#, no-c-format
msgid ""
"an <literal>UPDATE to create the link from p to "
"<literal>c"
msgstr ""
"<literal>p로부터 c로의 링크를 생성시키는 "
"<literal>UPDATE"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"This is not only inefficient, but also violates any <literal>NOT NULLparent_id column. You can fix "
"the nullability constraint violation by specifying <literal>not-null=\"true"
"\"</literal> in the collection mapping:"
msgstr ""
"이것은 비효율적일 뿐만 아니라, 또한 <literal>parent_id 컬럼 상의 임"
"의의 <literal>NOT NULL 컨스트레인트에 위배된다. 우리는 콜렉션 매핑"
"에서 <literal>not-null=\"true\"를 지정함으로써 null 허용 가능 컨스"
"트레인트 위반을 정정할 수 있다:"

#. Tag: para
#, no-c-format
msgid "However, this is not the recommended solution."
msgstr "하지만 이것은 권장되는 해결책이 아니다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The underlying cause of this behavior is that the link (the foreign key "
"<literal>parent_id) from p to cChild "
"object and is therefore not created in the <literal>INSERT. The "
"solution is to make the link part of the <literal>Child mapping."
msgstr ""
"이 행위의 기본 원인은 <literal>p로부터 c로의 링"
"크(foreign key <literal>parent_id)가 Child 객체"
"의 상태의 부분으로 간주되지 않고 그러므로 <literal>INSERT로 생성되"
"지 않는다는 점이다. 따라서 해결책은 <literal>Child 매핑의 링크 부분"
"을 만드는 것이다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"You also need to add the <literal>parent property to the "
"<literal>Child class."
msgstr ""
"(우리는 또한 <literal>parent 프로퍼티를 Child 클"
"래스에 추가시킬 필요가 있다.)"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Now that the <literal>Child entity is managing the state of the "
"link, we tell the collection not to update the link. We use the "
"<literal>inverse attribute to do this:"
msgstr ""
"이제 <literal>Child 엔티티가 링크의 상태를 관리한다는 점을 노트하"
"고, 우리는 링크를 업데이트 시키지 말도록 콜렉션에게 통보한다. 우리는 "
"<literal>inverse 속성을 사용한다."

#. Tag: para
#, fuzzy, no-c-format
msgid "The following code would be used to add a new <literal>Child:"
msgstr ""
"다음 코드는 새로운 <literal>Child를 추가시키는데 사용될 것이다"

#. Tag: para
#, fuzzy, no-c-format
msgid "Only one SQL <literal>INSERT would now be issued."
msgstr ""
"그리고 이제, 유일하게 한 개의 SQL <literal>INSERT가 실행될 것이다!"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"You could also create an <literal>addChild() method of "
"<literal>Parent."
msgstr ""
"약간 거칠게, 우리는 <literal>Parent의 addChild() looks like this:"
msgstr "이제, <literal>Child를 추가하는 코드는 다음과 같다"

#. Tag: title
#, no-c-format
msgid "Cascading life cycle"
msgstr "케스케이딩 생명주기"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"You can address the frustrations of the explicit call to <literal>save()에 대한 명시적인 호출은 여전히 성가시다. 우리는 케스"
"케이딩을 사용하여 이것을 얘기할 것이다."

#. Tag: para
#, fuzzy, no-c-format
msgid "This simplifies the code above to:"
msgstr "다음은 위의 코드를 단순화 시킨다"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Similarly, we do not need to iterate over the children when saving or "
"deleting a <literal>Parent. The following removes p를 저장하거나 삭제할 때 자식들에 대"
"해 반복하는 것을 필요로 하지 않는다. 다음은 데이터베이스로부터 <literal>p from the database. In this case, it "
"will only remove the link to <literal>p and cause a NOT "
"NULL</literal> constraint violation. You need to explicitly delete()"
"</literal> the Child."
msgstr ""
"는 데이터베이스로부터 <literal>c를 제거하지 않을 것이다; 그것은 오"
"직 <literal>p에 대한 링크만을 제거할 것이다(그리고 이 경우에 "
"<literal>NOT NULL 컨스트레인트 위반을 일으킬 것이다 ). 당신은 명시"
"적으로 <literal>Child를 delete() 시킬 필요가 있"
"다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"In our case, a <literal>Child cannot exist without its parent. So "
"if we remove a <literal>Child from the collection, we do want it "
"to be deleted. To do this, we must use <literal>cascade=\"all-delete-orphan"
"\"</literal>."
msgstr ""
"이제 우리의 경우에 <literal>Child는 그것의 부모 없이는 진정으로 존"
"재할 수 없다. 따라서 만일 우리가 콜렉션으로부터 하나의 <literal>Child을 사용해야 한다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Even though the collection mapping specifies <literal>inverse=\"true\"를 지정할 지라"
"도, 케스케이드들은 여전히 콜렉션 요소들을 반복함으로써 처리된다. 따라서 객체"
"가 케스케이드에 의해 저장되고, 삭제되거나 업데이트 되는 것을 당신이 필요로 "
"할 경우, 당신은 그것을 그 콜렉션에 추가해야 한다. 단순히 <literal>setParent()"
"</literal>를 호출하는 것으로는 충분하지 않다."

#. Tag: title
#, no-c-format
msgid "Cascades and <literal>unsaved-value"
msgstr "케스케이드들과 <literal>unsaved-value"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Suppose we loaded up a <literal>Parent in one Session. The "
"<literal>Parent will contain a collection of children and, since "
"the cascading update is enabled, Hibernate needs to know which children are "
"newly instantiated and which represent existing rows in the database. We "
"will also assume that both <literal>Parent and ChildLongIn Hibernate3, it is no longer "
"necessary to specify an <literal>unsaved-value explicitly. 속에 Parent를 로"
"드시켰고 UI 액션에서 어떤 변경들을 행했고, <literal>update()를 호출"
"하여 새로운 세션에서 이들 변경들을 영속화 시키는 것을 원한다고 가정하자. "
"<literal>Parent는 자식들을 가진 콜렉션을 포함할 것이고, 케스케이딩 "
"업데이트가 사용 가능하기 때문에, Hibernate는 어느 자식들이 새로이 초기화 되는"
"지 그리고 어느 것이 데이터베이스에서 현재 행들을 표현하는지를 알 필요가 있"
"다. <literal>Parent와 Child 모두 Longunsaved-value를 더이상 명시적으"
"로 지정할 필요가 없다.</emphasis>"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The following code will update <literal>parent and childnewChild:"
msgstr ""
"다음 코드는 <literal>parent와 child를 업데이트하"
"고 <literal>newChild를 삽입시킬 것이다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"This may be suitable for the case of a generated identifier, but what about "
"assigned identifiers and composite identifiers? This is more difficult, "
"since Hibernate cannot use the identifier property to distinguish between a "
"newly instantiated object, with an identifier assigned by the user, and an "
"object loaded in a previous session. In this case, Hibernate will either use "
"the timestamp or version property, or will actually query the second-level "
"cache or, worst case, the database, to see if the row exists."
msgstr ""
"물론 그것은 생성되는 식별자의 경우에는 모두 매우 좋지만, 할당되는 식별자들과 "
"composite 식별자들에 대해서는 어떠한가? 이것은 보다 어렵다. 왜냐하면 "
"Hibernate는 (사용자에 의해 할당된 식별자를 가진) 새로이 초기화 된 객체와 이"
"전 세션에서 로드되었던 객체 사이를 구별짓는데 식별자 프로퍼티를 사용할 수 없"
"기 때문이다. 이 경우에, Hibernate는 timestamp 프로퍼티 또는 version 프로퍼티"
"를 사용하거나 실제로 second-level 캐시를 질의하거나 가장 나쁜 경우에는 행이 "
"존재하는지를 알기 위해 데이터베이스를 질의할 것이다."

#. Tag: title
#, no-c-format
msgid "Conclusion"
msgstr "ê²°ë¡ "

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The sections we have just covered can be a bit confusing. However, in "
"practice, it all works out nicely. Most Hibernate applications use the "
"parent/child pattern in many places."
msgstr ""
"여기에 숙지할 것이 약간 있고 그것은 처음에는 혼동스러운 것처럼 보일 수 있다. "
"하지만 실제로 그것은 모두 매우 좋게 동작한다. 대부분의 Hibernate 어플리케이션"
"들은 많은 장소들에서 부모/자식 패턴을 사용한다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"We mentioned an alternative in the first paragraph. None of the above issues "
"exist in the case of <literal><composite-element> mappings, "
"which have exactly the semantics of a parent/child relationship. "
"Unfortunately, there are two big limitations with composite element classes: "
"composite elements cannot own collections and they should not be the child "
"of any entity other than the unique parent."
msgstr ""
"우리는 첫 번째 단락에서 대안을 언급했다. 위의 쟁점들 중 어느 것도 정확하게 부"
"모/자식 관계의 의미를 가진, <literal><composite-element> 매핑"
"들의 경우에는 존재하지 않는다. 불행히도, composite 요소 클래스들에 대한 두 개"
"의 커다란 제약들이 존재한다: composite 요소들은 콜렉션들을 소유하지 않고, 그"
"것들은 유일한 부모가 아닌 다른 어떤 엔티티의 자식일 수는 없다."