Shulou(Shulou.com)06/02 Report--

This article mainly explains the "Hibernate check id field method is what", the article explains the content is simple and clear, easy to learn and understand, the following please follow the editor's ideas slowly in-depth, together to study and learn "Hibernate check id field method is what" it!

This is a problem when you want to create a domain object that stores other domain objects in Set,Map or List. To solve this problem, you must provide an implementation of equals () and hashCode () for all your objects, which ensures that they work correctly before and after the object is saved and will not change when the object is in memory (return value). The Hibernate reference documentation provides the following recommendations:

"instead of using database identifiers to achieve equivalence, use commercial key values (business key), a combination of attributes that usually do not change. When an buk non-serializable object (transient object) is persisted, the database identifier changes. When a non-serializable instance (often with detached instances) is contained in a Set, a change in the hash value destroys the Set dependency. The properties of commercial key values do not need to be as stable as database primary keys, you just need to ensure that objects are stable when they are in a Set.

"We recommend implementing the equals () and hashCode () methods by judging the equivalence of business key values. This means that the equals () method only compares attributes that can distinguish the business key values (a candidate code) of real-world instances." (Hibernate reference document v. 3.1.1).

In other words, equals () and hashCode () use commercial key values for processing, while objects use Hibernate-generated key values as id values. This requires that there is an associated business key value that will not change for each object. However, not every object type has such a key, and you may try to use fields that change but not from time to time. This is consistent with the idea that business key values do not have to be as stable as database primary keys. If the keys don't change when objects are in Collection, they seem to be "good enough". This is a dangerous proposition, which means that your application may not crash, but only if no one updates a particular field in a particular situation. So there should be a better solution, and it does exist. Trying to create and maintain identifiers with separate definitions between objects and database rows is at the root of all the issues discussed so far. If we unify the form of all identifiers, these problems will no longer exist. In other words, as an alternative to database-centric and object-centric identifiers, we should create a generic, entity-specific ID to represent data entities, and this ID should be generated during data input. Whether a data entity is stored in a database, resided in memory as an object, or stored in media in other formats, this general-purpose ID should recognize it. By using the ID assigned when the data entity was created *, we can safely return to our original definitions of equals () and hashCode (). They simply use this id:

Public class Person {/ / assign an id as soon as possible private String id = IdGenerator.createId (); private Integer version; public String getId () {return id;} public void setId (String id) {this.id = id;} public Integer getVersion () {return version;} public void setVersion (Integer version) {this.version = version;} / / Person-specific fields and behavior here public boolean equals (Object o) {if (this = = o) return true If (o = = null | |! (o instanceof Person) return false; Person other = (Person) o; if (id = = null) return false; return id.equals (other.getId ());} public int hashCode () {if (id! = null) {return id.hashCode ();} else {return super.hashCode ();}

This example uses id as the criterion for determining the equivalence of the equals () method and the source of the hash value returned by hashCode (). It's a lot easier. But for it to work, we need two things. First, we need to make sure that each object has an id value before it is saved. In this example, when the id variable is declared, it is assigned a value. Second, we need a means to determine whether the object is newly generated or previously saved. In our earliest example, Hibernate is newly generated when it checks whether the id field is empty to determine whether the object is or not. Since our object id is never empty, this method is obviously no longer valid. To solve this problem, we can easily configure Hibernate to check whether the version field, rather than the id field, is empty. The version field is a more appropriate indicator for determining whether your object has been saved.

The following is the Hibernate mapping file for our improved Person class.

< hibernate-mapping package= "my.package" > < class name= "Person" table= "PERSON" > < id name= "id" column= "ID" > < generator class= "assigned" / > < / id > < version name= "version" column= "VERSION" unsaved-value= "null" / >

Share To

Weibo Tencent Renren QQZone Douban More

Weibo Tencent Renren QQZone Douban Yixin