Example 1-59 @OneToMany - Customer Class With Generics
@Entity
public class Customer implements Serializable {
...
@OneToMany(cascade=ALL, mappedBy="customer")
public Set<Order> getOrders() {
return orders;
}
...
}
Example 1-60 @ManyToOne - Order Class With Generics
@Entity
public class Order implements Serializable {
...
@ManyToOne
@JoinColumn(name="CUST_ID", nullable=false)
public Customer getCustomer() {
return customer;
}
...
}To understand this, you must take a step back. In OO, the customer owns the orders (orders are a list in the customer object). There can't be an order without a customer. So the customer seems to be the owner of the orders.
But in the SQL world, one item will actually contain a pointer to the other. Since there is 1 customer for N orders, each order contains a foreign key to the customer it belongs to. This is the "connection" and this means the order "owns" (or literally contains) the connection (information). This is exactly the opposite from the OO/model world.
This may help to understand:
public class Customer {
// This field doesn't exist in the database
// It is simulated with a SQL query
// "OO speak": Customer owns the orders
private List<Order> orders;
}
public class Order {
// This field actually exists in the DB
// In a purely OO model, we could omit it
// "DB speak": Order contains a foreign key to customer
private Customer customer;
}
The inverse side is the OO "owner" of the object, in this case the customer. The customer has no columns in the table to store the orders, so you must tell it where in the order table it can save this data (which happens via mappedBy).
The entity which has the table with foreign key in the database in owning entity and other side is inverse entity
*******************************************************************************************************************************************
Assume that we have 2 tables, ENQUIRY and ELEMENT with a One-to-Many relationship such that an Enquiry has many Elements. And if we want to enforce the NOT NULL constraint on foreign key column ELEMENT.ENQUIRY_ID. This relationship looks like so when modeling the Enquiry object with Hibernate:
@OneToMany(cascade = CascadeType.ALL)
@JoinColumn(name = "ENQUIRY_ID", referencedColumnName = "ID")
private Set elements = new HashSet();
When you enforced the NOT NULL constraint at the database level you will received the following error
Caused by: java.sql.BatchUpdateException: ORA-01400: cannot insert NULL into ("ELEMENT"."ENQUIRY_ID")
So Hibernate is obviously persisting the collection of elements before the parent enquiry and then going back and doing an UPDATE on the foreign key field afterwards (so INSERT collection items with NULL foreign key, INSERT parent, UPDATE collection item foreign keys) as it doesn’t realise the foreign key column will always be non-null.
We must explicitly tell Hibernate that the foreign key column is NOT NULL. It can then persist the parent enquiry first followed by the collection items. To do this, add the following clause to the @JoinColumn annotation:
@JoinColumn(name = "ENQUIRY_ID", referencedColumnName = "ID", nullable = false)
This way, not only are you ensuring database best-practice, but Hibernate will also have to issue less statements (so INSERT parent, INSERT collection items) which should be a more efficient transaction statement.
*******************************************************************************************************************************************
Bidirectional One-To-Many
Let us create a Bidirectional One-To-Many relationship between Question and Choice, a Question has many choices.
- Setup entities
@Entity
@Table (name = "QUESTION")
public class Question implements Serializable
{@Id
@GeneratedValue (strategy = GenerationType.AUTO)
@Column (name = “QUESTION_ID”)
private Long id;@Column (name = “TEXT”)
private String text;
……………
@Entity
@Table (name = "CHOICE")
public class Choice implements Serializable
{@Id
@GeneratedValue (strategy = GenerationType.AUTO)
@Column (name = “CHOICE_ID”)
private Long id;@Column (name = “TEXT”)
private String text;
…………… - Setup the ONE side on Question – I read ONE Question has MANY CHOICE(S).
Question
@OneToMany (mappedBy="question")
private Set choices = new HashSet();mappedBy – means “I am not the owner side”, I am mapped by question from the other side of the relationship. It will also not create the database column which makes sense, I would expect a foreign key on the CHOICE table instead.
- Setup the Many side on Choice – I read on Choice.java MANY Choice has ONE Question
@ManyToOne
@JoinColumn (name="QUESTION_ID")
private Question question;the @JoinColumn indicate the owning side of the relationship, it is responsible for updating the database column. It will create the QUESTION_ID column on the CHOICE table
- Reversing the Relationship so that the owning side is the Question instead
Question
@OneToMany
@JoinColumn (name = "QUESTION_ID")
private Set choices = new HashSet();Choice
@ManyToOne
@JoinColumn (name="QUESTION_ID", updatable = false, insertable = false)
private Question question; - Finally we need to use a List instead of Set – so we can preserve the order of the Choice(s).Question
@OneToMany (
cascade = {CascadeType.ALL},
fetch = FetchType.EAGER
)
@JoinColumn (name = "QUESTION_ID")
@org.hibernate.annotations.Cascade(
value = org.hibernate.annotations.CascadeType.DELETE_ORPHAN
)
@org.hibernate.annotations.IndexColumn(name = "CHOICE_POSITION")
private List choices = new ArrayList();Choice
@ManyToOne
@JoinColumn (name="QUESTION_ID", nullable = false, updatable = false, insertable = false)
private Question question;the @org.hibernate.annotations.IndexColumn defines the colum CHOICE_POSITION that will be used to maintain the order of the list. Some how reversing the ownership is the only way to get the IndexColumn to work
*******************************************************************************************************************************************