本文深入探讨了hibernate 3.6版本中，使用Criteria API为根实体设置自定义表别名时，为何默认别名会覆盖用户指定别名的机制。通过分析Hibernate内部的CriteriaQueryTranslator组件，揭示了在sql别名映射构建过程中，根Criteria实例作为键导致自定义别名被默认别名this_替换的根本原因，帮助开发者理解这一特定版本中的行为限制。
理解Hibernate Criteria API中的根实体别名问题
在使用hibernate criteria api进行查询时，我们经常需要为实体指定别名，以提高sql的可读性或解决列名冲突。通常，可以通过getsession().createcriteria(entity.class, “aliasname”)方法来设置别名。然而，在hibernate 3.6.10.final等特定版本中，为根实体（即查询的起始实体）设置自定义别名（例如temp）后，生成的sql语句却依然使用默认的别名（通常是this_），这给开发者带来了困惑。
例如，当我们尝试将Vehicle实体的别名设置为temp时：
Criteria cr = getSession().createCriteria(Vehicle.class, "temp"); // ... 其他Criteria配置
我们期望生成的sql语句中，vehicle表的别名是temp：
/* criteria query */ select temp.vehicle_id as y0_, temp.vin as y1_, temp.initial_registration as y2_ from vehicle temp where temp.vin=?
但实际观察到的SQL却是：
/* criteria query */ select this_.vehicle_id as y0_, this_.vin as y1_, this_.initial_registration as y2_ from vehicle this_ where this_.vin=?
这表明我们设置的自定义别名并未生效。
示例代码
为了更好地说明这个问题，我们使用一个简化的Vehicle实体和其对应的Criteria查询方法：
Vehicle实体定义：
import static Javax.persistence.GenerationType.IDENTITY; import javax.persistence.*; import java.util.Date; // 导入Date类 import lombok.Getter; import lombok.Setter; @Getter @Setter @Entity @Table(name = "vehicle") public class Vehicle { @Id @GeneratedValue(strategy = IDENTITY) @Column(name = "vehicle_id", unique = true, nullable = false) private int vehicleId; @Column(nullable = false, length = 17) private String vin; @Temporal(TemporalType.TIMESTAMP) @Column(name = "initial_registration") private Date initialRegistration; }
Criteria查询方法：
import org.hibernate.Criteria; import org.hibernate.Session; import org.hibernate.criterion.Projections; import org.hibernate.criterion.ProjectionList; import org.hibernate.criterion.Restrictions; import org.hibernate.transform.Transformers; import java.util.ArrayList; import java.util.List; public class VehicleDao { // 假设这是一个DAO类 private Session session; // 假设session已通过某种方式获取 public VehicleDao(Session session) { this.session = session; } protected Session getSession() { return session; } // 假设begin()和commit()是事务管理方法 protected void begin() { /* 事务开始逻辑 */ } protected void commit() { /* 事务提交逻辑 */ } public <T> List<T> findByProjectionCriteria() { Criteria cr = getSession().createCriteria(Vehicle.class, "temp"); // 尝试设置别名为"temp" cr.setResultTransformer(Transformers.aliasToBean(Vehicle.class)); ProjectionList projectionList = Projections.projectionList(); projectionList.add(Projections.property("vehicleId"), "vehicleId"); projectionList.add(Projections.property("vin"), "vin"); projectionList.add(Projections.property("initialRegistration"), "initialRegistration"); cr.setProjection(projectionList); cr.add(Restrictions.eq("vin", "WVW29343249702776")); begin(); // 事务开始 List<T> list = null; try { list = cr.list(); } catch (Exception e) { e.printStackTrace(); } finally { commit(); // 事务提交 } if (list == null) { list = new ArrayList<>(); } return list; } }
Hibernate内部机制解析
为了理解为何自定义别名会被覆盖，我们需要深入了解Hibernate 3.6版本内部处理Criteria查询的机制。当Criteria.list()方法被调用时，它会触发SessionImpl中的相应逻辑，进而创建一个CriteriaLoader对象。CriteriaLoader在初始化过程中会构造一个CriteriaQueryTranslator对象，而正是这个CriteriaQueryTranslator负责将Criteria查询转换为实际的SQL语句，并在此过程中处理别名。
CriteriaQueryTranslator的核心方法之一是createCriteriaSQLAliasmap()，它负责建立Criteria对象与SQL别名之间的映射。我们来看一下该方法的简化逻辑：
private void createCriteriaSQLAliasMap() { int i = 0; // 遍历所有非根Criteria（例如关联查询中的子Criteria） Iterator criteriaIterator = criteriaEntityNames.entrySet().iterator(); while ( criteriaIterator.hasNext() ) { Map.Entry me = ( Map.Entry ) criteriaIterator.next(); Criteria crit = ( Criteria ) me.getKey(); String alias = crit.getAlias(); // 获取用户设置的别名 if ( alias == null ) { alias = ( String ) me.getValue(); // 如果未设置，则使用实体名 } // 为非根Criteria生成并存储别名 criteriaSQLAliasMap.put( crit, StringHelper.generateAlias( alias, i++ ) ); } // 根Criteria的别名处理 criteriaSQLAliasMap.put( rootCriteria, rootSQLAlias ); // 这里将根Criteria的别名设置为rootSQLAlias（即"this_"） }
问题根源分析：
-
自定义别名添加： 当我们调用getSession().createCriteria(Vehicle.class, “temp”)时，我们创建了一个Criteria实例，并为其设置了别名temp。这个Criteria实例会被添加到criteriaEntityNames集合中（或者类似结构中）。在createCriteriaSQLAliasMap()方法中的while循环里，它会遍历这些Criteria实例。此时，我们的Vehicle根Criteria会被识别，其自定义别名temp会被获取，并作为值与Vehicle根Criteria实例（作为键）一起，暂时存储到criteriaSQLAliasMap中。
-
默认别名覆盖： while循环结束后，createCriteriaSQLAliasMap()方法会执行关键的最后一行代码： criteriaSQLAliasMap.put( rootCriteria, rootSQLAlias ); 这里的rootCriteria就是我们创建的Vehicle根Criteria实例，而rootSQLAlias在Hibernate 3.6中默认通常是this_。由于rootCriteria作为Map的键是唯一的，这一行代码会用默认的this_别名覆盖之前为同一个rootCriteria实例存储的自定义别名temp。
因此，无论我们在createCriteria()方法中为根实体指定了什么别名，最终都会被CriteriaQueryTranslator内部的默认rootSQLAlias（即this_）所覆盖。
结论与注意事项
在Hibernate 3.6版本中，由于其内部CriteriaQueryTranslator的实现机制，通过getSession().createCriteria(Entity.class, “aliasName”)为根实体设置自定义表别名是无效的，最终生成的SQL仍会使用默认的this_别名。
注意事项：
- 版本限制： 这种行为是Hibernate 3.6特定版本的一个特性或限制。在后续的Hibernate版本（例如Hibernate 5及更高版本）中，Criteria API的使用方式和内部实现可能有所不同，并且对根实体别名的处理也可能得到改进。
- 理解而非规避： 对于仍在使用Hibernate 3.6的开发者而言，理解这一机制的重要性在于，不要期望通过createCriteria()方法来改变根实体的默认SQL别名。如果对SQL别名有严格的自定义需求，可能需要考虑以下替代方案：
- HQL（Hibernate Query Language）： HQL允许在查询中明确指定别名，例如from Vehicle temp where temp.vin = ?。
- Native SQL： 直接编写原生SQL查询，可以完全控制SQL语句的每一个细节，包括表别名。
- 升级考量： 如果项目允许，升级到更高版本的Hibernate可能是解决此类问题的更根本途径，因为新版本通常会带来更多的功能、优化和更灵活的API设计。
总之，在Hibernate 3.6环境下，当我们使用Criteria API时，应知晓根实体的表别名将始终默认为this_，并据此调整开发策略。
评论（已关闭）
评论已关闭