网站建设山东聚搜网络,c 还可以做网站,广州做营销型网站建设,有动效得网站hibernate状态自然ID是可以唯一标识实体的一个或一组属性。 我们最多可以为一个实体定义一个自然ID。 当Hibernate在实体映射文件中看到natural-id标记时#xff0c;它会自动在构成natural-id的属性上创建唯一且非空的约束。 首先#xff0c;让我们看一下简单和复合自然ID的示… hibernate状态 自然ID是可以唯一标识实体的一个或一组属性。 我们最多可以为一个实体定义一个自然ID。 当Hibernate在实体映射文件中看到natural-id标记时它会自动在构成natural-id的属性上创建唯一且非空的约束。 首先让我们看一下简单和复合自然ID的示例。 简单的自然ID一个人可以通过其选民ID进行唯一标识。 因此我们可以说这可能来自他的自然身份。 !-- Version 1 --
hibernate-mapping packagecom.pramati.modelclass namePerson tablePERSONid nameid columnIDgenerator classnative//idnatural-idproperty namevoterId typestring columnVOTER_ID//natural-idproperty namename typestring columnNAME/!-- Other properties --
/class
/hibernate-mapping 复合自然ID电话号码即标准代码和固定电话号码的组合可以形成个人实体的自然ID。 !-- Version 2 --
hibernate-mapping packagecom.pramati.modelclass namePerson tablePERSONid nameid columnIDgenerator classnative//idnatural-idproperty namestdCode typestring columnSTD_CODE/property namelandlineNumber typestring columnLANDLINE_NUMBER//natural-idproperty namename typestring columnNAME/!-- Other properties --
/class
/hibernate-mapping 因此Hibernate在stdCode和landlineNumber上创建了一个非空约束。 这些属性对于个人实体应该是唯一的。 默认情况下自然ID是不可变的。 因此假设您尝试从数据库中加载人员实体并更改构成自然ID的任何属性则Hibernate将引发异常。 例如我们已加载Person并尝试在活动会话中修改其landlineNumber / stdcode这是我们会得到的例外 org.hibernate.HibernateException:: An immutable natural identifier
of entity com.pramati.model.Person was altered from abc to xyz Hibernate 4.1提出了通过bean的natural-id加载实体的功能。 到目前为止会话缓存将缓存通过当前会话中的get / load加载的对象。 现在默认情况下还将缓存使用natural-id加载的对象。 以下是会话API的最新功能 public NaturalIdLoadAccess byNaturalId(String entityName);
public NaturalIdLoadAccess byNaturalId(Class entityClass);public SimpleNaturalIdLoadAccess bySimpleNaturalId(String entityName);
public SimpleNaturalIdLoadAccess bySimpleNaturalId(Class entityClass); 我们可以通过自然ID加载类的实例如下所示 // In case of version 1 defined above:
Person person (Person)session.byNaturalId(Person.class ).using( voterID, ZAAXDFT435 ).load();// For Version 1, this can be simplified as:
Person person (Person)session.bySimpleNaturalId(Person.class ).load(ZAAXDFT435);// In case of version 2 defined above:
Person person (Person)session.byNaturalId(Person.class ).using(stdCode, 040).using(landlineNumber,2345678).load(); 请注意负载返回的实体不仅是代理而且是实际实体本身。 如果要获取代理则必须使用getReference代替load如下所示 session.byNaturalId(Person.class )
.using(stdCode, 040)
.using(landlineNumber,2345678)
.getReference(); 为了保持一致性新方法也可用于基于标识符的加载。 public IdentifierLoadAccess byId(String entityName);
public IdentifierLoadAccess byId(Class entityClass); 因此我们可以使用session.byIdPerson.class.getReferenceid代替session.loadPerson.classid。 而不是session.getPerson.classid我们可以使用session.byIdPerson.class.loadid 当我们使用查询缓存时自然ID也很有用。 查询缓存通常没有那么有用因为它经常变得无效。 假设事件序列如下 方案1 1.使用实体natural-id中的属性进行HQL查询以加载人员A。 查询也被缓存即query.setCacheabletrue 2.将另一个人B插入到人表中。 3.现在使用与步骤1中相同的查询再次加载A。 问题是在步骤3中将进行新的数据库调用以从“人”表中获取A。 是还是不是 答案是肯定的。 发生的事情是Hibernate在内部维护一个时间戳缓存。 这个时间戳缓存记录特定的Hibernate受管表被修改的时间。 现在在步骤3Hibernate看到它是一个缓存的查询。 但是在返回存在于缓存中的实体之前它会验证缓存的结果相对于表修改时间是否较旧。 现在由于在缓存后修改了表因此Hibernate再次进行了新查询。 为了进一步了解这一点让我们考虑以下情形让我们只在名称为Rama的Person表中进行记录 方案2 一个。 执行缓存的查询以获取名称与“ Rama”匹配的人员列表“来自人员名称为“ Rama”的人员” b。 也将记录插入名称也为“ Rama”的“个人”中。 这不是问题因为名称未定义为唯一属性 C。 现在再次执行步骤a中的查询。 最初在步骤a我们仅获得记录。 但是在步骤c中即使结果被缓存Hibernate也会再次命中数据库。 这是由于时间戳缓存无效而发生的。 Hibernate只是在从高速缓存返回实体之前检查表是否已被修改。 但是无论是更新插入还是后续操作都不会影响表的更新方式。 但是在我们看过的前一种情况下此验证检查似乎完全不相关因为插入的记录与加载的实体无关。 如果我们使用自然ID来获取实体则可以绕过此检查。 使用natural-id时可以保证即使修改数据库后结果也不会改变。 早些时候当我们不支持使用自然ID加载实体时我们在Criteria API中提供了使用自然ID的规定。 我们可以在方案1的步骤1和3中使用以下内容 session.createCriteria(Person.class).add(Restrictions.naturalId().set(stdCode, person.getStdCode()).set(landlineNumber, person.getLandlineNumber())).setCacheable(true).uniqueResult(); 当使用自然ID来获取实体时时间戳缓存检查将被绕过。 因此现在如果我用此条件而不是查询替换第一种情况的步骤1和3则数据库只会被命中一次。 如果我们使用Restrictions.eq而不是Restrictions.naturalId数据库将被命中两次。 另外如果您使用的是最新版本的Hibernate我们可以使用新的API代替构建标准。 参考在prasanthnath博客上来自JCG合作伙伴 Prasanth G的“ Hibernate中的自然ID” 。 翻译自: https://www.javacodegeeks.com/2013/10/natural-ids-in-hibernate.htmlhibernate状态
