Don't let hibernate steal your ID.

Summary:

When an object is persisted to the database, the identifier of the object is always difficult to implement properly. However, the problem is entirely derived from the existence of objects that do not hold IDs before they are saved. We can solve this problem by taking responsibility for assigning object IDs from an object-relational image framework such as hibernate. In contrast, once an object is instantiated, it should be assigned an ID. This makes the object identifier simple and error-prone, and also reduces the amount of code needed in the domain model.

Enterprise-class Java applications often move data back and forth between Java objects and relational databases. There are many ways to implement this process from manually writing SQL code to using mature objects such as hibernate---relational image (ORM) solution. No matter what technology you use, once you start to persist Java objects into a database, object identifiers will become a complex and unmanageable subject. What might happen is that you instantiate two different objects, but they represent the same row in the database. In order to solve this problem, you might take the approach of implementing Equals () and hashcode () in your persistent object, but it is more skillful to implement these two methods properly than at first glance. To make matters worse, traditional ideas, including those advocated by hibernate official documents, do not necessarily offer the most practical solutions for new projects.

The difference between the object identity in the virtual machine (VM) and in the database is a breeding ground for problems. In a virtual machine, you don't get the ID of the object, you're simply holding the object's direct reference. Behind the scenes, the virtual machine does assign a 8-byte ID to each object, which is the real reference to the object. When you persist an object to a database, the problem begins to occur. Suppose you create a person object and deposit it in the database (we can call it Person1). And one of your other pieces of code reads the data of the person object from the database and instantiates it as another new person object (we can call it Person2). Now you have two images in your memory that are in the same row of objects in the database. An object reference can only point to one of them, but we need a way to indicate that the two objects actually represent the same entity. This is why the object identifier is introduced (in the virtual machine).

In the Java language, object identifiers are defined by the Equals () method (and the associated Hashcode () method) that each object holds. Whether two objects (references) are the same instance, the Equals () method should be able to determine whether they represent the same entity. The Hashcode () method is associated with the Equals () method because all objects that are judged equivalent (equal) should return the same hash value (hashcode). In the default implementation, the Equals () method only compares the reference of an object, an object that is equivalent to itself, and is not equivalent to any other instance. For persistent objects, it is important to override both methods so that the two objects representing the same row in the database are judged to be equivalent. This is especially important for the correct work of collection data structures (Set,map and lists) in Java.

To illustrate the different ways to implement equal () and hashcode (), let's consider a simple object person who is ready to persist into a database.

public class Person {
　 private Long id;
　 private Integer version;
　 public Long getId() { return id; }
　 public void setId(Long id) {
　　 this.id = id;
　 }
　 public Integer getVersion() {
　　 return version;
　 }
　 public void setVersion(Integer version) {
　　 this.version = version;
　 }
　 // person-specific properties and behavior
}

In this example, we followed the best practices for holding both the ID field and the Version field. The ID field holds the value used as the primary key in the database, and the version field is an increment that starts at 0 and changes with each update of the object (it helps us avoid concurrent updates). To see more clearly, let's take a look at the hibernate to persist this object to the database's image file.

<?xml version="1.0"?>
<class name="Person" table="PERSON">
<id name="id" column="ID" unsaved-value="null">
<generator class="sequence">
<param name="sequence">PERSON_SEQ</param>
</generator>
</id>
<version name="version" column="VERSION" />
<!-- Map Person-specific properties here. -->
</class>