Component of Components

Hibernate allows us to compose our components out of other components. This is making extreme use of java in the SQL world, but provides us with a great deal of flexibility. I modified the address class in the previous example to be composed of components.

Ordered Collection

In an earlier post we saw that hibernate provides us with the option to use Sorted Collections. In these collections the objects were fetched form the database and inserted into collections in a sorted order. Thus the sorting of elements happened in the Java Domain. This was an example of in-memory sorting.
Hibernate also provides an alternative to the above technique called ordered collections.

Hibernate Collections - The whole variety -2

In the last post we saw a java class that included the different collections supported in Hibernate and the mapping file. If we were to start the server with the hibernate set to DDL creation then the logs are as below:

Exception in thread "main" org.hibernate.InvalidMappingException: 

Hibernate Collections - The whole variety -1

In the previous post we saw the varied collections available for use in Hibernate. I created a class which includes the different collection types.

public class Person {
    private Long id;
    private String name;

Hibernate And Collections Support

Hibernate supports the use of Collections in the Java model objects. Associations between tables are represented using these collections.
e.g.: If there is a one-to-many relation between owner and pet (1 Owner has many pets) then a collection of pets can be mapped in the Owner class.

class Owner {
    private List<Pet> pets = new ArrayList<Pet>();
}

The Hibernate Inheritance Mechanism - 3 + 4

We saw in approach 3 that a single table is used to represent an entire hierarchy. The end result was a table with sets of unrelated columns, absence of nullability constraints and constantly changing column count on addition of new sub-classes.
In approach 4 we saw how the 3 class hierarchy was split into 3 tables with each class being given a table. Although the resultant schema was a highly normalized schema,  it required joins for fetching records of any of the concrete class and was slightly more complex to implement compared to earlier approaches.
Here we shall modify approach 3 to use approach 4 techniques to come up with a slightly more cleaner implementation for approach 3.

The Hibernate Inheritance Mechanism - 4

We have seen three of the inheritance techniques as of yet.This is the fourth in the series.
Table per subclass
In this technique a table is created for every class in the hierarchy. There exists a separate table for every interface/abstract class/concrete class that has any persistent properties.

<?xml version="1.0"?>

The Hibernate Inheritance Mechanism - 3

Table per Class Hierarchy:
In this technique an entire class hierarchy is mapped to a single table. Both the Footballer and Cricketer Information will be saved as different rows in the same table.To distinguish the data in each row a discriminator is added.

The Hibernate Inheritance Mechanism - 2

Table Per Concrete Class + Unions
Continuing with the inheritance mechanisms, I shall now attempt to implement the second approach. This approach tries to overcome the drawbacks of the first technique.
In this technique

1. The abstract class is also mapped into Hibernate.