Skip to main content

Hibernate - Mapping a parent/children relationship

The first thing many developer try to do when they begin using Hibernate is a mapping of a parent/children relationship. this is usually the first time you encounter collections. it's also the first time you have to think about the differences between entities and value tyhpes, or get lost in the complexity of ORM.

Managing the associations between classes and the relationships between tables is at the heart of ORM. Most of the difficult problems involved in implementing an ORM solution relate to association management.

POJO-oriented persistence engines such as Hibernate don't implement managed associations, and POJO stands such as EJB3.0 and Java Persistence don't require managed assocations. contrary to EJB2.0 CMR, Hibernate and JPA associations are all inherently unidirectional.

Use Bid and Item ( for auction) as the example,
As far as Hibernate is concerned, the association from Bid to Item is a different association than the association from Item to Bid! The association from Bid to Item is a many-to-one assocation. Recalling that associations are directional, you classify the inverse association from item to bid as a one-to-many association.

The association from Bid to Item(and vice versa) is an example of the simplest possible kind of entity association. You have two properties in two classes. One is a collection of references, and the other a single reference.


public class Bid {
...
private Item item;
public void setItem(Item item) {
this.item = item;
}
public Item getItem() {
return item;
}
...
}
Next, this is the Hibernate mapping for this association:
<class
name="Bid"
table="BID">
...
<many-to-one
name="item"
column="ITEM_ID"
class="Item"
not-null="true"/>
</class>

OR in JPA:


public class Bid {
...
@ManyToOne( targetEntity = auction.model.Item.class )
@JoinColumn(name = "ITEM_ID", nullable = false)
private Item item;
...
}




There are two optional elements in this mapping. First, you don't have to include the targetEntity of the association; it's implicit from the type of the field.
The second optoinal element is the @JoinColumn. If you don't declare the name of the foreign key column, Hibernate automatically uses a combination of the target entity name and the database identifier proprety name of the target entity. In other words, if you don't add a @JoinColumn annotation, the default name for the foreign key colum is item plus id, separated with an underscore. However, because you want to make the foreign key column not null, you need to annotation anyway to set nullable=false.




public class Item {
...
private Set bids = new HashSet();
public void setBids(Set bids) {
this.bids = bids;
}
public Set getBids() {
return bids;
}
public void addBid(Bid bid) {
bid.setItem(this);
bids.add(bid);
}
...
}


<class
name="Item"
table="ITEM">
...
<set name="bids">
<key column="ITEM_ID"/>

<one-to-many class="Bid"/>
</set>
</class>

OR in JPA:









Comments

Popular posts from this blog

Quicksort implementation by using Java

 source: http://www.algolist.net/Algorithms/Sorting/Quicksort. The divide-and-conquer strategy is used in quicksort. Below the recursion step is described: 1st: Choose a pivot value. We take the value of the middle element as pivot value, but it can be any value(e.g. some people would like to pick the first element and do the exchange in the end) 2nd: Partition. Rearrange elements in such a way, that all elements which are lesser than the pivot go to the left part of the array and all elements greater than the pivot, go to the right part of the array. Values equal to the pivot can stay in any part of the array. Apply quicksort algorithm recursively to the left and the right parts - the previous pivot element excluded! Partition algorithm in detail: There are two indices i and j and at the very beginning of the partition algorithm i points to the first element in the array and j points to the last one. Then algorithm moves i forward, until an element with value greater or equal

Live - solving the jasper report out of memory and high cpu usage problems

I still can not find the solution. So I summary all the things and tell my boss about it. If any one knows the solution, please let me know. Symptom: 1.        The JVM became Out of memory when creating big consumption report 2.        Those JRTemplateElement-instances is still there occupied even if I logged out the system Reason:         1. There is a large number of JRTemplateElement-instances cached in the memory 2.     The clearobjects() method in ReportThread class has not been triggered when logging out Action I tried:      About the Virtualizer: 1.     Replacing the JRSwapFileVirtualizer with JRFileVirtualizer 2.     Not use any FileVirtualizer for cache the report in the hard disk Result: The japserreport still creating the a large number of JRTemplateElement-instances in the memory        About the work around below,      I tried: item 3(in below work around list) – result: it helps to reduce  the size of the JRTemplateElement Object        

Stretch a row if data overflows in jasper reports

It is very common that some columns of the report need to stretch to show all the content in that column. But  if you just specify the property " stretch with overflow' to that column(we called text field in jasper report world) , it will just stretch that column and won't change other columns, so the row could be ridiculous. Haven't find the solution from internet yet. So I just review the properties in iReport one by one and find two useful properties(the bold  highlighted in example below) which resolve the problems.   example: <band height="20" splitType="Stretch" > <textField isStretchWithOverflow="true" pattern="" isBlankWhenNull="true"> <reportElement stretchType="RelativeToTallestObject" mode="Opaque" x="192" y="0" width="183" height="20"/> <box leftPadding="2"> <pen lineWidth="0.25"/>