Hibernate-unsaved

unsaved-value----à主要是给Hibernate在程序没有显示调用save 或者 update时判断使用的?====è不是的，它应该是在Hibernate在清除缓存也就是刷新缓存时，会根据unsaved-value和缓存中的实体对象的id值进行比较，如果id同为null值则采取insert的操作，如果值不一样则使用update sql操作。
    以上是"一"方的重要配置，再看看"多"方的一个重要配置:unsaved-value,就像上面Product.hbm.xml中的设置那样，这一项在id的配置中设置。这一设置是与级联一起工作的。关于这一点，robbin讲的很清楚：
当你显式的使用session.save()或者session.update()操作一个对象的时候，实际上是用不到unsaved-value 的。某些情况下(父子表关联保存)，当你在程序中并没有显式的使用save或者update一个持久对象，那么Hibernate需要判断被操作的对象究竟是一个已经持久化过的持久对象，是一个尚未被持久化过的内存临时对象。例如：

       Session session = ...;  

1. Transaction tx = ...;  
2. Parent parent = (Parent) session.load(Parent.class, id);  
3. Child child = new Child();  
4. child.setParent(parent);  
5. child.setName("sun");  
6. parent.addChild(child);  
7. s.update(parent);  
8. s.flush();  
9. tx.commit();  
10. s.close();  

     在上例中，程序并没有显式的session.save(child); 那么Hibernate需要知道child究竟是一个临时对象，还是已经在数据库中有的持久对象。如果child是一个新创建的临时对象(本例中就是这种情况)，那么Hibernate应该自动产生session.save(child)这样的操作，如果child是已经在数据库中有的持久对象，那么 Hibernate应该自动产生session.update(child)这样的操作。因此我们需要暗示一下Hibernate，究竟 child对象应该对它自动save还是update。在上例中，显然我们应该暗示Hibernate对child自动save，而不是自动 update。那么Hibernate如何判断究竟对child是save还是update呢？它会取一下child的主键属性 child.getId() ，这里假设id是 java.lang.Integer类型的。如果取到的Id值和hbm映射文件中指定的unsave-value相等，那么Hibernate认为 child是新的内存临时对象，发送save，如果不相等，那么Hibernate认为child是已经持久过的对象，发送update。 unsaved-value="null" (默认情况，适用于大多数对象类型主键 Integer/Long/String/...)
当Hibernate取一下child的Id，取出来的是null(在上例中肯定取出来的是null)，和unsaved-value设定值相等，发送save(child)
当Hibernate取一下child的id，取出来的不是null，那么和unsaved-value设定值不相等，发送update(child)
   unsaved-value的可选配置有：
none，any，null
unsaved- value="none"和unsaved-value="any"主要用在主键属性不是通过Hibernate生成，而是程序自己setId()的时候。unsaved-value="none"和unsaved-value="any"究竟有什么含义了。如果你非要用assigned不可，那么继续解释一下：
unsaved-value="none" 的时候，由于不论主键属性为任何值，都不可能为none，因此Hibernate总是对child对象发送update(child)
unsaved-value="any" 的时候，由于不论主键属性为任何值，都肯定为any，因此Hibernate总是对child对象发送save(child)
      大多数情况下，可以避免使用assigned，只有当你使用复合主键的时候不得不手工setId()，这时候需要你自己考虑究竟怎么设置unsaved-value了，根据你自己的需要来定。
      关于为什么不要使主键带有义务意义，robbin的解释很清楚：还是以上面的例子打比方，如果我们将Category的某一个性质（比如产品序号或者名称）作为主键，如果后来由于业务需要，我们把这个性质改了，那将不可僻免地要去修改与这个对象相关联的所有数据的外键，而如果我们只要代理主键，这个问题就可完全僻免