Hibernate3.6Criteria别名覆盖详解

本文深入解析了Hibernate 3.6版本中Criteria API的一个常见困惑：为根实体设置自定义别名失效的问题。通过分析Hibernate内部的`CriteriaQueryTranslator`组件，揭示了在SQL别名映射构建过程中，根`Criteria`实例作为键，导致用户指定的别名被默认的`this_`覆盖的根本原因。针对Hibernate 3.6，使用`getSession().createCriteria(Entity.class, "aliasName")`为根实体设置别名无效。开发者应理解这一版本限制，考虑使用HQL、原生SQL或升级Hibernate版本等替代方案，以满足对SQL别名自定义的需求。本文旨在帮助开发者深入理解Hibernate 3.6的这一特性，避免在实际开发中遇到不必要的困扰，并提供相应的解决方案建议。

理解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_"）
}

问题根源分析：

1. 自定义别名添加： 当我们调用getSession().createCriteria(Vehicle.class, "temp")时，我们创建了一个Criteria实例，并为其设置了别名temp。这个Criteria实例会被添加到criteriaEntityNames集合中（或者类似结构中）。在createCriteriaSQLAliasMap()方法中的while循环里，它会遍历这些Criteria实例。此时，我们的Vehicle根Criteria会被识别，其自定义别名temp会被获取，并作为值与Vehicle根Criteria实例（作为键）一起，暂时存储到criteriaSQLAliasMap中。

2. 默认别名覆盖： 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_，并据此调整开发策略。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。