|
Hibernate example source code file (example_parentchild.pot)
This example Hibernate source code file (example_parentchild.pot) 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.
The Hibernate example_parentchild.pot source code
#
# AUTHOR <EMAIL@ADDRESS>, YEAR.
#
msgid ""
msgstr ""
"Project-Id-Version: 0\n"
"POT-Creation-Date: 2010-02-11T05:38:15\n"
"PO-Revision-Date: 2010-02-11T05:38:15\n"
"Last-Translator: Automatically generated\n"
"Language-Team: None\n"
"MIME-Version: 1.0\n"
"Content-Type: application/x-publican; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#. Tag: title
#, no-c-format
msgid "Example: Parent/Child"
msgstr ""
#. Tag: para
#, 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 <one-to-many> association from Parent to Child. The alternative approach is to declare the Child as a <composite-element>. 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 bidirectional one-to-many association with cascades to model a parent/child relationship efficiently and elegantly."
msgstr ""
#. Tag: title
#, no-c-format
msgid "A note about collections"
msgstr ""
#. Tag: para
#, 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 ""
#. Tag: para
#, 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
#, 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 ""
#. Tag: para
#, 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 ""
#. Tag: para
#, 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 ""
#. Tag: para
#, no-c-format
msgid "Suppose we start with a simple <literal><one-to-many> association from Parent to Child."
msgstr ""
#. Tag: para
#, 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 ""
#. Tag: para
#, no-c-format
msgid "an <literal>INSERT to create the record for c"
msgstr ""
#. Tag: para
#, no-c-format
msgid "an <literal>UPDATE to create the link from p to c"
msgstr ""
#. Tag: para
#, no-c-format
msgid "This is not only inefficient, but also violates any <literal>NOT NULL constraint on the parent_id column. You can fix the nullability constraint violation by specifying not-null=\"true\" in the collection mapping:"
msgstr ""
#. Tag: para
#, no-c-format
msgid "However, this is not the recommended solution."
msgstr ""
#. Tag: para
#, no-c-format
msgid "The underlying cause of this behavior is that the link (the foreign key <literal>parent_id) from p to c is not considered part of the state of the Child object and is therefore not created in the INSERT. The solution is to make the link part of the Child mapping."
msgstr ""
#. Tag: para
#, no-c-format
msgid "You also need to add the <literal>parent property to the Child class."
msgstr ""
#. Tag: para
#, 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 inverse attribute to do this:"
msgstr ""
#. Tag: para
#, no-c-format
msgid "The following code would be used to add a new <literal>Child:"
msgstr ""
#. Tag: para
#, no-c-format
msgid "Only one SQL <literal>INSERT would now be issued."
msgstr ""
#. Tag: para
#, no-c-format
msgid "You could also create an <literal>addChild() method of Parent."
msgstr ""
#. Tag: para
#, no-c-format
msgid "The code to add a <literal>Child looks like this:"
msgstr ""
#. Tag: title
#, no-c-format
msgid "Cascading life cycle"
msgstr ""
#. Tag: para
#, no-c-format
msgid "You can address the frustrations of the explicit call to <literal>save() by using cascades."
msgstr ""
#. Tag: para
#, no-c-format
msgid "This simplifies the code above to:"
msgstr ""
#. Tag: para
#, 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 and all its children from the database."
msgstr ""
#. Tag: para
#, no-c-format
msgid "However, the following code:"
msgstr ""
#. Tag: para
#, no-c-format
msgid "will not remove <literal>c from the database. In this case, it will only remove the link to p and cause a NOT NULL constraint violation. You need to explicitly delete() the Child."
msgstr ""
#. Tag: para
#, no-c-format
msgid "In our case, a <literal>Child cannot exist without its parent. So if we remove a Child from the collection, we do want it to be deleted. To do this, we must use cascade=\"all-delete-orphan\"."
msgstr ""
#. Tag: para
#, no-c-format
msgid "Even though the collection mapping specifies <literal>inverse=\"true\", cascades are still processed by iterating the collection elements. If you need an object be saved, deleted or updated by cascade, you must add it to the collection. It is not enough to simply call setParent()."
msgstr ""
#. Tag: title
#, no-c-format
msgid "Cascades and <literal>unsaved-value"
msgstr ""
#. Tag: para
#, no-c-format
msgid "Suppose we loaded up a <literal>Parent in one Session, made some changes in a UI action and wanted to persist these changes in a new session by calling update(). The 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 Parent and Child have generated identifier properties of type Long. Hibernate will use the identifier and version/timestamp property value to determine which of the children are new. (See .) In Hibernate3, it is no longer necessary to specify an unsaved-value explicitly."
msgstr ""
#. Tag: para
#, no-c-format
msgid "The following code will update <literal>parent and child and insert newChild:"
msgstr ""
#. Tag: para
#, 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 ""
#. Tag: title
#, no-c-format
msgid "Conclusion"
msgstr ""
#. Tag: para
#, 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 ""
#. Tag: para
#, 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 ""
Other Hibernate examples (source code examples)
Here is a short list of links related to this Hibernate example_parentchild.pot source code file:
|