Ywang Question:
Unsaved-value is a new or old, if unsaved-value = none is new, it will be in the INSERT to the database, if unsaved-value = any means that the object is Load from the database, Update into the database.
My problem is: unsaved-value is to force us to instruct this object to be new or old, then I set an object's unsaved-value set to any, then I want new object, put him save to the database How to do it? Do I feel that this is not a contradiction? Mainly, how can we say an object when writing a configuration file? Is it new or LOAD?
I have checked some posts, what does unsaved-value say? I don't understand, I hope everyone teach me.
Robbin Answer:
When you explicitly use session.save () or session.Update (), you don't do unsaved-value. In some cases (parent sidelic table related to saving) Memory temporary objects that have not been persisted. E.g:
Session session = ...; transaction tx = ...; parent parent = (parent) session.load (parent.class, id); child child = new child (); child.setparent (PARENT); Child.setName "Sun"); parent.addchild (child); s.Update (parent); s.flush (); tx.commit (); s.Close ();
In the above example, the program does not have an explicit session.save (child); then Hibernate needs to know that Child is a temporary object, or has a persistent object in the database. If Child is a newly created temporary object (this is this case), Hibernate should automatically generate SESSION.SAVE (Child) operations, if Child is a persistent object already in the database, then Hibernate should be automatically Generate SESSION.UPDATE (CHILD) operations.
So we need to hint Hibernate, and if the Child object should automatically save it or Update. In the above example, it is apparent that we should suggest Hibernate automatic Save instead of automatic Update. So how does Hibernate judges to CHILD is SAVE or UPDATE? It will take a lower key attribute child.getID (), here, assuming the ID is a java.lang.integer type. If the ID value taken is equal to the Unsave-Value specified in the HBM mapping file, Hibernate believes that Child is a new memory temporary object, send save, if not, Hibernate thinks Child is an object that has already been persisted and sends Update.
Unsaved-value = "null" (default, suitable for most object type primary key integer / long / string / ...)
When Hibernate takes a child ID, NULL (null is definitely taken in the above example), and the unsaved-value set value is equal, send save (child) When Hibernate takes a child ID, take it out Not null, then the UNSAVED-VALUE setting value is not equal, send Update (Child)
For example, the following situation:
Session session = ...; transaction tx = ...; parent parent = (parent) session.load (parent.class, id); child child = (child) session.load (child.class, childid); child. SetParent (PARENT); Child.setName ("Sun"); parent.addchild (child); S.Update (PARENT); S.Flush (); tx.commit (); s.close ();
Child has been in the database. It is a persistent object, not new created, so we hope that Hibernate sends Update (Child), Hibernate takes child.getid (), and unsave-value specified Null compared to the matter, then it is not equal, then send Update (Child).
BTW: Parent objects don't need to worry, because the program explicitly has a load operation and Update for PARENT, does not need hibernate to judge what save or Update. We have to pay attention to the operation of the Child object. The additional unsaved-value is defined in the primary key properties of the Child class.
If the primary key attribute is not an object type, it is a basic type, such as int / long / double / ..., then you need to specify a numeric Unsaved-Value, for example:
Unsaved-null = "0"
Here, many people think that the primary key attribute is defined as int / long, which is high-efficient than the integer / long run. It is considered that the basic type does not need to perform object packages and deconstruction, so I like to define the primary key as int / long. of. But in fact, Hibernate always converts the primary key to the object type, even if you are defined as int / long type, Hibernate should also perform an object construct operation inside, when you return to you, you have to decompose it. Efficiency may be negative or low. So everyone must reverse a point of view. In Hibernate, the primary key attribute is defined as the basic type, and it is not possible to be high, and there are many troubles, and there are many troubles, so I suggest that you use the object-type Integer / long definition. Primary key.
Unsaved-value = "none" and
Unsaved-value = "any"
The main main use is when the primary key attribute is not generated via Hibernate, but the program is when SETID (). Here more, it is highly recommended to use Hibernate ID Generator, or you can extend Hibernate ID Generator, pay special attention not to use the field with actual meaning as a primary key! For example, the user class User, many people like to use the user to log in as the primary key, this is a very bad habit, when the user class and other entity classes are related to the relationship, if you need to modify the user login name, change Need to change the data in a few tables. The coupling is too high, and if you use the id generator that does not have a business meaning, modify the user name, you only modify the USER table.
This problem is discussed, if you design the database in strict accordance with this principle, then you don't use it for hand-to-order (), you use Hibernate ID Generator to OK. So you don't need to understand
Unsaved-value = "none" and
Unsaved-value = "any"
There is any meaning of anything. If you don't have assigned, then continue to explain:
When unsaved-value = "none", since the primary key attribute is any value, it is impossible to be None, so Hibernate always sends Update (Child) for the Child object.
When unsaved-value = "any", since the primary key attribute is any value, it is certainly any, so Hibernate always sends Save (Child) to the Child object.
In most cases, you can avoid using assigned, only when you use the composite primary key, you have to manually setid (), this time you need to consider how to set up Unsaved-Value, depending on your own needs.
BTW: GAVIN KING strongly does not recommend using the Composite-ID, which is highly recommended to use Usertype.
Therefore, if you are designing in the system, follow the following principles:
[color = red] 1, use hibernate ID generator to generate independent primary keys, do not use a field with a business meaning, do not use assigned.
2. Use the object type (string / integer / long / ...) to do the primary key without using the basic type (int / long / ...)
3. Do not use the composite-id to handle the case of the composite primary key, and use Usertype to process the situation. [/ color]
Then you will always use unsaved-value = "null", it is impossible to use any / none / ..
