Hibernate–difference between save() and persist()

save() method can return that primary key id value which is generated by hibernate and we can see it by

long s = session.save(k);

In this same case, persist() will never give any value back to the client, hope you are clear.

When to use Persist() and when to use save() ?

persist() is well defined. It makes a transient instance persistent. However, it doesn’t guarantee that the identifier value will be assigned to the persistent instance immediately, the assignment might happen at flush time. The spec doesn’t say that, which is the problem I have with persist().

persist() also guarantees that it will not execute an INSERT statement if it is called outside of transaction boundaries. This is useful in long-running conversations with an extended Session/persistence context.

A method like persist() is required.

save() does not guarantee the same, it returns an identifier, and if an INSERT has to be executed to get the identifier (e.g. “identity” generator, not “sequence”), this INSERT happens immediately, no matter if you are inside or outside of a transaction. This is not good in a long-running conversation with an extended Session/persistence context.

Hibernate : Named Query

Often times, developer like to put HQL string literals scatter all over the Java code, this method is hard to maintaine and look ugly. Fortunately, Hibernate come out a technique called “names queries

HQL in annotation
@NamedQueries({
	@NamedQuery(
	name = "findStockByStockCode",
	query = "from Stock s where s.stockCode = :stockCode"
	)
})
@Entity
@Table(name = "stock", catalog = "mkyong")
public class Stock implements java.io.Serializable {
...

Native SQL in annotation

@NamedNativeQueries({
	@NamedNativeQuery(
	name = "findStockByStockCodeNativeSQL",
	query = "select * from stock s where s.stock_code = :stockCode",
        resultClass = Stock.class
	)
})
@Entity
@Table(name = "stock", catalog = "mkyong")
public class Stock implements java.io.Serializable {
...

In native SQL, you have to declare the ‘resultClass‘ to let Hibernate know what is the return type, failed to do it will caused the exception “org.hibernate.cfg.NotYetImplementedException: Pure native scalar queries are not yet supported“.

Call a named query

In Hibernate, you can call the named query via getNamedQuery method.

Query query = session.getNamedQuery("findStockByStockCode")
.setString("stockCode", "7277");
Query query = session.getNamedQuery("findStockByStockCodeNativeSQL")
.setString("stockCode", "7277");
Thanks to : http://www.mkyong.com/hibernate/hibernate-named-query-examples/

Hibernate : Parameter Binding

Without parameter binding, you have to concatenate the parameter String like this (bad code) :

String hql = "from Stock s where s.stockCode = '" + stockCode + "'";
List result = session.createQuery(hql).list();

Pass an unchecked value from user input to the database will raise security concern, because it can easy get hack by SQL injection. You have to avoid the above bad code and using parameter binding instead.

Hibernate parameter binding

There are two ways to parameter binding : named parameters or positional.

1. Named parameters

This is the most common and user friendly way. It use colon followed by a parameter name (:example) to define a named parameter. See examples…

Example 1 – setParameter

The setParameter is smart enough to discover the parameter data type for you.

String hql = "from Stock s where s.stockCode = :stockCode";
List result = session.createQuery(hql)
.setParameter("stockCode", "7277")
.list();
Example 2 – setString

You can use setString to tell Hibernate this parameter date type is String.

String hql = "from Stock s where s.stockCode = :stockCode";
List result = session.createQuery(hql)
.setString("stockCode", "7277")
.list();
Example 3 – setProperties

This feature is great ! You can pass an object into the parameter binding. Hibernate will automatic check the object’s properties and match with the colon parameter.

Stock stock = new Stock();
stock.setStockCode("7277");
String hql = "from Stock s where s.stockCode = :stockCode";
List result = session.createQuery(hql)
.setProperties(stock)
.list();
2. Positional parameters

It’s use question mark (?) to define a named parameter, and you have to set your parameter according to the position sequence. See example…

String hql = "from Stock s where s.stockCode = ? and s.stockName = ?";
List result = session.createQuery(hql)
.setString(0, "7277")
.setParameter(1, "DIALOG")
.list();

This approach is not support the setProperties function. In addition, it’s vulnerable to easy breakage because every change of the position of the bind parameters requires a change to the parameter binding code.

String hql = "from Stock s where s.stockName = ? and s.stockCode = ?";
List result = session.createQuery(hql)
.setParameter(0, "DIALOG")
.setString(1, "7277")
.list();
Conclusion

In Hibernate parameter binding, i would recommend always go for “Named parameters“, as it’s more easy to maintain, and the compiled SQL statement can be reuse (if only bind parameters change) to increase the performance.

Hibernate : Object states and lifecycle

An object is in transient state when it is in heap but not persisted or yet not been given to the hibernate session for persistence.

Once the object/entity is inatilized and exists in memory, however it is not handed over to hibernate, it is in transient state.
When object is being handled or tracked by hibernate session or is in control of hibernate it is called as persistent state. Object in this state remains in synch with the database and is managed by the persistence manager.
After the session is close or once hibernate session leaves the control of object it is called as detached state.

Persistent objects become Detached objects when the session is closed. Calling session.evict() on the object
reference or session.clear() will also remove an object from session. These later session operations will be
covered later in class when cache is discussed.

 

Detached objects can be reassociated and synchronized to the database after a new session is opened. Calling
session.update() or session.saveOrUpdate() on a Detached object reference transitions the Detached object
back to the Persistent state. When a Detached object is “reattached,” the database is updated with object’s
current state; to include changes made while detached.

A detached instance can be reattached to a new Session at a later point in time, making it (and all the modifications) persistent again. This feature enables a programming model for long running units of work that require user think-time. We call them application transactions, i.e., a unit of work from the point of view of the user.
Hence once the object is persisted, it transition is mainly in between two states detached and attached (persistent) in its life cycle. It can also come back to transient state only if call delete() in session.

Hibernate : The Object-Relational Impedance Mismatch

Persistence

Hibernate is concerned with helping your application to achieve persistence.  So what is persistence?  Persistence simply means that we would like our application’s data to outlive the applications process.  In Java terms, we would like the state of (some of) our objects to live beyond the scope of the JVM so that the same state is available later. 

Relational Databases

Specifically, Hibernate is concerned with data persistence as it applies to relational databases (RDBMS).  In the world of Object-Oriented applications, there is often a discussion about using an object database (ODBMS) as opposed to a RDBMS.  We are not going to explore that discussion here.  Suffice it to say that RDBMS remain a very popular persistence mechanism and will so for the foreseeable future. 

The Object-Relational Impedance Mismatch

‘Object-Relational Impedance Mismatch’ (sometimes called the ‘paradigm mismatch’) is just a fancy way of saying that object models and relational models do not work very well together.  RDBMSs represent data in a tabular format (a spreadsheet is a good visualization for those not familiar with RDBMSs), whereas object-oriented languages, such as Java, represent it as an interconnected graph of objects.  Loading and storing graphs of objects using a tabular relational database exposes us to 5 mismatch problems…

1. Granularity

Sometimes you will have an object model which has more classes than the number of corresponding tables in the database (we says the object model is more granular than the relational model).  Take for example the notion of an Address…

2. Subtypes (inheritance)

Inheritance is a natural paradigm in object-oriented programming languages. However, RDBMSs do not define anything similar on the whole (yes some databases do have subtype support but it is completely non-standardized)…

3. Identity

A RDBMS defines exactly one notion of ‘sameness’: the primary key.  Java, however, defines both object identity (a==b) and object equality (a.equals(b)).

4. Associations

Associations are represented as unidirectional references in Object Oriented languages whereas RDBMSs use the notion of foreign keys. If you need bidirectional relationships in Java, you must define the association twice.

Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.

5. Data navigation

The way you access data in Java is fundamentally different than the way you do it in a relational database. In Java, you navigate from one association to an other walking the object network.

This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

Hibernate : use of mappedBy

Relationship is something in which two objects are related in some way. Now in object orientation it not necessary that both the side must show same relationship status,

For example :

I love her (1 to 1)
however she might love others (1 to many)

Now when we want to delegate the responsibility of maintaining the relationship on other side that time we can use mappedBy, In this way we might not require join table as well. In this case a separate join table can also be avoided.

image

Hibernate : Differences in @one-To-Many relation and @ElementCollection

This is for sure that to maintain one to many relation we need to have a collection reference in the source object class. Then what is the difference between the two ?

In simple words, a join table will always get created when using @ElementCollection, however the join table can be avoided if

    @OneToMany(mappedBy = “driver”) here drive is the member variable from other entity.

image

How to decide what kind should be used when ?

I believe @ElementCollection is mainly for mapping non-entities (embeddable or basic) while @OneToMany is used to map entities. So which one to use depend on what you want to achieve.

ElementCollection is a standard JPA annotation, which is now preferred over the proprietary Hibernate annotation CollectionOfElements.

It means that the collection is not a collection of entities, but a collection of simple types (Strings, etc.) or a collection of embedded elements (class annotated with @Embedded).

It also means that the elements are completely owned by the containing entities: they’re modified when he entity is modified, deleted when the entity is deleted, etc. They can’t have their own lifecycle.

Hibernate : Data inconsistency

I have 2 entities Team and Player.

Team has  references of player and player has reference of a team. 

One-To-Many relationship from team to player ie Team object holds a collection of player object and can be saved irrespective of Player object pointing to a particular team. Hibernate allows to have this inconsistency. It delegates the logic on the programmer to maintain the data consistency.

Here you might save a team object with reference to players but when you call player.getTeam() you might get null pointer exception Smile

A way to avoid it could  be :

Team.addPlayertoList(Player player  ){

player.setTeam(this);
team.playerList.add(player);

}

Note : Handle both the operation in a single methods and make it atomic while adding and removing both from data design perspective.

Hibernate : Is Many-to-One is same as One-To-One mapping

In both these relation ship the source object has one foreign key or pointer to the target object.

For example : –
One-to-One
A car can have one owner – here the source object car will have pointer to target object person.

Many-to-One
Many cars can have one owner – here too the source object car will have pointer to target object person.

In java or object world all the relationships are established from source object, target may or may not point to the source at all. However in RDBMS when a query is fired in relationship the inverse query or bi-directional relationship has to be there without violation.

A ManyToOne relationship in Java is where the source object has an attribute that references another target object and (if) that target object had the inverse relationship back to the source object it would be a OneToMany relationship. All relationships in Java and JPA are unidirectional, in that if a source object references a target object there is no guarantee that the target object also has a relationship to the source object. This is different than a relational database, in which relationships are defined through foreign keys and querying such that the inverse query always exists.

JPA also defines a OneToOne relationship, which is similar to a ManyToOne relationship except that the inverse relationship (if it were defined) is a OneToOne relationship. The main difference between a OneToOne and a ManyToOne relationship in JPA is that a ManyToOne always contains a foreign key from the source object’s table to the target object’s table, where as a OneToOne relationship the foreign key may either be in the source object’s table or the target object’s table.

In JPA a ManyToOne relationship is defined through the @ManyToOne annotation or the <many-to-one> element.

In JPA a ManyToOne relationship is always (well almost always) required to define a OneToMany relationship, the ManyToOne always defines the foreign key (JoinColumn) and the OneToMany must use a mappedBy to define its inverse ManyToOne.

Hibernate : What is lazy Loading in Hibernate ?

Lazy setting decides whether to load child objects while loading the Parent Object. You need to specify parent class.Lazy = true in hibernate mapping file. By default the lazy loading of the child objects is true. This make sure that the child objects are not loaded unless they are explicitly invoked in the application by calling getChild() method on parent. In this case hibernate issues a fresh database call to load the child when getChild() is actully called on the Parent object. But in some cases you do need to load the child objects when parent is loaded. Just make the lazy=false and hibernate will load the child when parent is loaded from the database. 

Examples: Address child of User class can be made lazy if it is not required frequently. But you may need to load the Author object for Book parent whenever you deal with the book for online bookshop. 

Hibernate does not support lazy initialization for detached objects. Access to a lazy association outside of the context of an open Hibernate session will result in an exception. 

The annotations can be directly put onto the fields or on the corresponding getter methods. In the following example we use the fields:

import javax.persistence.*   @Entity
public class Person {   @Id @GeneratedValue
  private long id;   private String name;   public String getId() {
    return this.id;
  }   public String getName() {
    return this.name;
  }
}

Anyways, putting the annotations to the fields has a painful – although non obvious – side effect in connection with hibernate proxies created by lazy loading.

Let’s have a look at the following example of a 1:1 relationship (constructors have been omitted to keep the code short):

@Entity
public class Person {   @Id @GeneratedValue
  private long id;   private String name;   @OneToOne(fetch = FetchType.LAZY)
  private Address address;   public String getId() {
    return this.id;
  }   public String getName() {
    return this.name;
  }
}   @Entity
public class Address {
  @Id @GeneratedValue
  private long id;   private String town;   public long getId() {
    return this.id;
  }   public String getTown() {
    return this.town;
  }
}

If we now load a Person object in a Hibernate session, then the Address is not loaded initially (due to the FetchType.LAZY); Hibernate creates a proxy for it:

Person person = (Person) session.load(Person.class, Long.valueOf(1));
Address address = person.getAddress();   // Hibernate returns a proxy here

Those Hibernate proxies access the database as soon as the field is first accessed:

String town = address.getTown(); // implicit db access by Hibernate

This is true for all fields except the identifier property (the field with the @Id Annotation) as this value is already fetched with the SELECT on the table Person.

long addressId = address.getId();

And that’s the trap: Although we only access the ID, Hibernate initializes the Proxy and fetches the whole record. The reason is that Hibernate doesn’t know anything about the methodgetId() if the @Id-Annotation is placed on the field. Hibernate therefore thinks that getId()is a standard field access and loads the whole record. If you access that field outside the Hibernate session, you therefore get a LazyInitializationException.

To fix that problem, the @Id annotation needs to be put to the getter method. That in turn makes it necessary to put all other annotations to the getters as Hibernate does not allow to mix field and getter annoations. And as we’re now using getters for our annotations, we also need to provide setters as well (those can be private or protected).

Our code now looks as follows:

@Entity
public class Person {   private long id;
  private String name;
  private Address address;   @Id @GeneratedValue
  public String getId() {
    return this.id;
  }   public String getName() {
    return this.name;
  }   @OneToOne(fetch = FetchType.LAZY)
  public Address getAddress() {
    return this.address;
  }
}   @Entity
public class Address {
  private long id;   private String town;   @Id @GeneratedValue
  public long getId() {
    return this.id;
  }   public String getTown() {
    return this.town;
  }
}

Lazy loading is working as expected:

Person person = (Person) session.load(Person.class, Long.valueOf(1)); 
Address address = person.getAddress(); long addressId = address.getId(); // no DB-Select String town = address.getTown(); // Proxy gets initialized, DB-Select