Hibernate 3.6 Criteria API 根别名设置问题
在使用Hibernate Criteria API进行查询时，开发者通常可以通过createCriteria(Class entityClass, String alias)方法为实体指定一个别名，以便在查询条件或投影中引用。然而，在Hibernate 3.6.10.Final等较旧版本中，即便明确指定了根Criteria的别名，例如getSession().createCriteria(Vehicle.class, "temp")，生成的SQL语句中根表的别名却可能依然是默认的this_，而非期望的temp。
以下是一个简化的示例，展示了这种行为：
实体定义 (Vehicle.java):
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.Restrictions;
import org.hibernate.transform.Transformers;
import org.hibernate.criterion.ProjectionList;
import java.util.ArrayList;
import java.util.List;
public class VehicleDAO {
private Session session; // 假设session已通过某种方式获取和管理
public VehicleDAO(Session session) {
this.session = session;
}
protected List findByProjectionCriteria() {
// 尝试设置根别名为 "temp"
Criteria cr = session.createCriteria(Vehicle.class, "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()和commit()是事务管理方法
// begin();
List list = null;
try {
list = cr.list();
} catch (Exception e) {
e.printStackTrace();
}
if (list == null)
list = new ArrayList<>();
// commit();
return list;
}
// 省略getSession(), begin(), commit() 等方法实现
} 预期生成的SQL (带有 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 (带有 this_ 别名):
/* criteria query */ select this_.vehicle_id as y0_, this_.vin as y1_,this_.initial_registration as y2_ from vehicle this_ where this_.vin=?
深入解析内部机制
这个问题并非代码错误，而是Hibernate 3.6内部处理根Criteria别名的一种特定行为。通过分析Hibernate的源代码，特别是CriteriaQueryTranslator类的实现，可以揭示其原因。
当SessionImpl的list()方法被调用时，它会创建一个CriteriaLoader对象，进而调用CriteriaQueryTranslator的构造函数。在CriteriaQueryTranslator中，有一个关键方法createCriteriaSQLAliasMap()负责设置查询中的SQL别名。
createCriteriaSQLAliasMap()方法的核心逻辑如下（简化版，基于原答案描述）：
private void createCriteriaSQLAliasMap() {
int i = 0;
Iterator criteriaIterator = criteriaEntityNames.entrySet().iterator();
while ( criteriaIterator.hasNext() ) {
Map.Entry me = ( Map.Entry ) criteriaIterator.next();
Criteria crit = ( Criteria ) me.getKey();
String alias = crit.getAlias(); // 获取用户设置的别名，例如 "temp"
if ( alias == null ) {
alias = ( String ) me.getValue(); // 实体名称
}
// 这里可能会将用户别名添加到映射中
criteriaSQLAliasMap.put( crit, StringHelper.generateAlias( alias, i++ ) );
}
// 关键点：在循环结束后，根Criteria的别名被明确地重新设置
criteriaSQLAliasMap.put( rootCriteria, rootSQLAlias );
}问题出在criteriaSQLAliasMap.put( rootCriteria, rootSQLAlias );这一行。在while循环中，用户为根Criteria（Vehicle.class）指定的别名（例如"temp"）可能确实被添加到了criteriaSQLAliasMap中。然而，由于rootCriteria对象本身被用作映射的键，并且在循环结束后，rootCriteria对应的别名又被rootSQLAlias覆盖。而rootSQLAlias在Hibernate 3.6的内部逻辑中，通常会默认生成为this_。
换句话说，即使您通过createCriteria(Vehicle.class, "temp")设置了别名，这个别名在CriteriaQueryTranslator内部的别名生成和映射过程中，最终会被硬编码或默认生成的根别名（this_）所替换，因为rootCriteria作为键的最终值被重新赋值了。
结论与注意事项
- 版本特定行为： 这种根别名被覆盖的行为是Hibernate 3.6.x版本的一个特点。在更新的Hibernate版本中，这一行为可能已经得到优化或改变。
- 功能影响： 尽管SQL语句中的别名与预期不符，但通常情况下，这并不会影响Criteria查询的正确性或结果。Hibernate内部会正确地将this_映射回您的实体。
-
限制与替代：
- 在Hibernate 3.6中，如果对SQL语句中根表的别名有严格的命名要求，通过Criteria API直接控制根别名会非常困难。
- 在这种情况下，可以考虑使用HQL（Hibernate Query Language）或原生SQL查询来精确控制别名，但这会牺牲一部分Criteria API的类型安全和可编程性优势。
- 对于大多数应用场景，默认的this_别名是完全可接受的，无需过度关注。
理解Hibernate旧版本内部的工作机制，有助于开发者在遇到类似问题时，能够准确地诊断问题根源，并决定是否需要调整开发策略或升级Hibernate版本。
