在一个条件查询中没有必要显式的使用 "group by" 。某些投影类型就是被定义为 分组投影，他

们也出现在SQL的group by子句中。

可以选择把一个别名指派给一个投影，这样可以使投影值被约束或排序所引用。下面是两种不同的

实现方式：
 
List results = session.createCriteria(Cat.class)
    .setProjection( Projections.alias( Projections.groupProperty("color"), "colr" ) )
    .addOrder( Order.asc("colr") )
    .list();

我写的hql为：

from Department as d where d.employees.name='Tom';

运行时出现异常：org.hibernate.QueryException: illegal attempt to dereference collection

是因为：在上面的HQL语句 中，Department的关联实体employees是一个集合，而不直接是一个Employee实体。

在 Hibernate3.2.2以前的版本，Hibernate会对关联实体自动使用隐式的inner join，

也就是说如下SQL语句 不会有任何问题 :from Department as d where d.employees.name='Tom';

从 Hibernate3.2.3以后，Hibernate改变了这种隐式的inner join的策略

对于如下这条语句：

from Department as d where d.employees.name='Tom';

如果employees是普通组件属 性，或单个的关联实体，则Hibernate会自动生成隐式的inner join

如果myEvents是也一个集合，那么对不起！系 统将会出现 org.hibernate.QueryException: illegal attempt to dereference collection异常。
据Hibernate官方说法:
这样可以让这使得隐含关联更具确定性（原文：This makes implicit joins more deterministic ）。

推荐这样写：

在前一篇日志中自动生成hibernate配置文件的时候，会在dao层用到getSession()方法来操作数据库记录，但是他还有个方法getHibernateTemplate()，这两个方法究竟有什么区别呢？

1.使用getSession()方法你只要继承sessionFactory，而使用getHibernateTemplate()方法必须继承 HibernateDaoSupport当然包括sessionFactory，这点区别都不是特别重要的，下面这些区别就很重要了

2.getSession()方法是没有经过spring包装的，spring会把最原始的session给你，在使用完之后必须自己调用相应的 close方法，而且也不会对声明式事务进行相应的管理，一旦没有及时关闭连接，就会导致数据库连接池的连接数溢 出，getHibernateTemplate()方法是经过spring封装的，例如添加相应的声明式事务管理，由spring管理相应的连接。

在实际的使用过程中发现的确getHibernateTemplate()比getSession()方法要好很多，但是有些方法在getHibernateTemplate()并没有提供，这时我们用HibernateCallback 回调的方法管理数据库.

例如如下代码：

/**
     * 使用 hql 语句进行操作
     * @param hql HSQL 查询语句（使用回调函数访问外部变量，必须是final的）
     * @param offset 开始取数据的下标
    * @param length 读取数据记录数
    * @return List 结果集
*/
public List getListForPage ( final String hql , final int offset , final int length ) {

              List list = getHibernateTemplate().executeFind ( new HibernateCallback ( ) {
                            public Object doInHibernate ( Session session ) throws HibernateException, SQLException {
                                            Query query = session.createQuery ( hql ) ;
                                            query.setFirstResult ( offset ) ;
                                            query.setMaxResults ( length ) ;
                                            List list = query.list ( ) ;
                                            return list ;
                           }
               }) ;
               return list ;
}

遇到这种错误，一般是因为并发过大引起的。

查询解决方法:

查看一下数据库现有的进程数，是否已经达到参数processes的大小。

1.select count(*) from v$process;                         取得数据库目前的进程数。
2.select value from v$parameter where name = 'processes'; 取得进程数的上限。
3.如已达到上限，修改initSID.ora中的processes的大小。
4.重新启动数据库到nomount状态下，执行create spfile from pfile; 并startup open。

查询数据库自启动以来最大的并发数量

select * from v$license

<filter>

<filter-name>hibernateFilter</filter-name>

<filter-class>

org.springframework.orm.hibernate3.support.OpenSessionInViewFilter

    </filter-class>

<init-param>

<param-name>singleSession</param-name>

        <param-value>true</param-value>

</init-param><!-- 和 spring 中的sesssionfactory ID 一致 -->

 </filter>

<filter-mapping><filter-name>hibernateFilter</filter-name><url-pattern>*.do</url-pattern><!-- *.jsp, *.do--></filter-mapping>

Write operations are not allowed in read-only mode (FlushMode.NEVER/MANUAL): Turn your Session into FlushMode.COMMIT/AUTO or remove 'readOnly' marker from transaction definition.

这时候再去网上找解决方案, 会有人说: 把参数 singleSession改为false, 就行了. 不过, 改完后, 估计不久就会遇到另一个郁闷的异常:

org.hibernate.HibernateException: Illegal attempt to associate a collection with two open sessions

这下完了, 两个方案都不行, 到底怎么办? 还好, 在http://xuliangyong.javaeye.com/blog/144818的主页上, 给了一个方案, 就是改写 OpenSessionInViewFilter 的代码, 非常感谢, 下面给出的就是最终方案:

web.xml

< filter-name >hibernateFilter</filter-name>

< filter-class > org.springframework.orm.hibernate3.support.OurOpenSessionInViewFilter </filter-class>

OurOpenSessionInViewFilter.java 代码:

package org.springframework.orm.hibernate3.support;







import org.hibernate.*;







/** * 单session模式下, 默认会发生无法提交的错误: * Write operations are not allowed in read-only mode (FlushMode.NEVER/MANUAL): Turn your Session into FlushMode.COMMIT/AUTO or remove 'readOnly' marker from transaction definition. * 需要设置FlushMode并刷新session. * 参考: http://xuliangyong.javaeye.com/blog/144818 * @author 刘长炯 */publicclass OurOpenSessionInViewFilter extends OpenSessionInViewFilter {







public OurOpenSessionInViewFilter() {



super.setFlushMode(FlushMode.AUTO);



}







protectedvoid closeSession(Session session, SessionFactory sessionFactory) {



session.flush();







try {



session.getTransaction().commit();



} catch (HibernateException e) {



// TODO Auto-generated catch block//e.printStackTrace();



}







super.closeSession(session, sessionFactory); 



} 



}

如果各位有更好的解决方案, 欢迎讨论哦!!!

题外话:

感觉 Spring + Hibernate 的健壮性还是不够啊! 容易抛异常, 这是事实, 也许这是开源软件的通病吧.

About a year and an half ago I wrote an entry about the problem that rises when mapping an entity with multiple bags using eager fetching. At the end of the entry I suggested three different solutions: (a) to use lazy fetching, (b) to use sets instead of bags, and (c) to use the @IndexColumn annotation. Few months later I elaborated on the usage of @IndexColumn, this time another way – using the @CollectionId annotation.

Environment

·         Hibernate Entity Manager – 3.3.1.GA

·         Hibernate core – 3.2.5.GA

·         Hibernate annotations- 3.3.0.GA

·         Database – PostgreSQL 8.1

First one, first…

Just before we start a warning – the @CollectionId annotation is a Hibernate specific annotation – not a part of the specification. And it doesn't work on one-to-many associations (but it can be used in conjunction with one-to-many associations). After putting that behind of us lets see the problem.

The Problem

Assume the following entities relation, a parent entity has two collections of child entities. Both collections should be eagerly loaded.

First try will be to just to map it as is (Child1 has a many-to-many association; Child2 has a one-to-many):

@ManyToMany( fetch = FetchType.EAGER, cascade=CascadeType.ALL)

@JoinTable(name = "PARENT_CHILD1", 

joinColumns = @JoinColumn(name = "PARENT_ID", referencedColumnName = "ID"), 

inverseJoinColumns = @JoinColumn(name = "CHILD1_ID", referencedColumnName = "ID"))

List<Child1> child1s = new LinkedList<Child1>();

@OneToMany(mappedBy = "parent", cascade = CascadeType.ALL, fetch = FetchType.EAGER)

List<Child2> child2s = new LinkedList<Child2>();

But when loading a persistence unit with the above configuration the "org.hibernate.HibernateException: cannot simultaneously fetch multiple bags" will be thrown.

Using an idbag

The reason is that when we add the @CollectionId to a List or a Collection its semantics changes from "just a bag" to "a bag with primary key" (a.k.a, idbag). It means that a surrogate key is assigned to each row on the collection

When transforming the association to Child1 into an idbag (using the @CollectionId annotation) the problem is solved. The reason is that when we switch the association semantics from "a simple bag" to "a bag with primary key" (a.k.a, idbag) it means that a surrogate key is assigned to each row on the collection.

@Entity

public class Parent {

………

@ManyToMany( fetch = FetchType.EAGER, cascade=CascadeType.ALL)

@JoinTable(name = "PARENT_CHILD1", 

joinColumns = @JoinColumn(name = "PARENT_ID", referencedColumnName = "ID"), 

inverseJoinColumns = @JoinColumn(name = "CHILD1_ID", referencedColumnName = "ID"))

@GenericGenerator(name="uuid-gen", strategy = "uuid")

@CollectionId(columns = @Column(name = "COL_ID"), type = @Type(type = "string"), generator = "uuid-gen")List<Child1> child1s = new LinkedList<Child1>();

@OneToMany(mappedBy = "parent", cascade = CascadeType.ALL, fetch = FetchType.EAGER)

List<Child2> child2s = new LinkedList<Child2>();

}

The problem with bags is that when Hibernate eagerly loads multiple collections it issues an outer join select to the RDBMS which can cause multiple entries on some of the collections. But when using an idbag each row in the collections is uniquely identified by the surrogate key, therefore Hibernate can identify it within the collection, even if the SQL statement returns an entry more than once.

Notice the usage of a generator assigned to the collection id, the generator is responsible for creating the surrogate keys of the collection rows. I decided to use the UUID strategy. You can, of course, use JPA standard generators (such as Sequence or Table generators). The @CollectionId references the COL_ID column on PARENT_CHILD1 table (the join table). The value of the collection id is invisible to the application (it is not being mapped to a property).

So why not on one-to-many

The Hibernate annotations documentation says that to announce idbag semantics you should assign the @CollectionId to a @ManyToMany, @CollectionOfElements, or @OneToMany (look at the table on this section), but the Hibernate core documentation it says "Hibernate provides a feature that allows you to map many to many associations and collections of values to a table with a surrogate key." (here). I've tried it and indeed when annotating a @OneToMany collection with the @CollectionId an exception with the message "one-to-many collections with identifiers are not supported " is thrown by Hibernate.

Idbag - Not Just For Eager Fetching

Don't forge that you can use idbag for reasons other than solving multiple eager associations. For example it can give a major performance boost over simple bags for mutative operations. If entries in a collection have surrogate keys Hibernate will be able to locate the matching rows in the database using these keys (each row in the association table becomes unique) – there is no need for the fetch -> delete-all -> insert-all cycle when updating the collection.

Posted at 03:49PM Jan 18, 2008 by Eyal Lupu in Persistence  |  Comments[6]

@Entity

@Table(name = "customer")

public class CustomerEO implements java.io.Serializable {

……

         private CustomerType type;

         @Enumerated(EnumType.STRING)

         public CustomerType getType() {

                   return type;

         }

         public void setType(CustomerType type) {

                   this.type = type;

         }

         public enum CustomerType {

                   COMPETITOR, INVESTOR, PARTNER, VENDER

         }

}

在实体中虽然标注成枚举类型，但当实体持久化后，表中所对应的值仍旧是基本的数据类型，以上代码创建表的SQL语句是：

CREATE TABLE customer (

         id int(20) NOT NULL auto_increment,

         name varchar(255),

         type varchar(255),

         PRIMARY KEY (id)

)

使用枚举类型后，在创建实体时便可以直接引用枚举类型，例如以下代码所示。

CustomerEO customer = new CustomerEO();

customer.setName("Janet2");

customer.setType(CustomerType.PARTNER);

entityManager.persist(customer);

在使用@Enumerated注释时，需要注意以下几个问题：

l         因为枚举类型的有名称和值两个属性，所以在持久化时可以选择持久化名称或是持久化值。通过EnumType来定义，它有两个值如下所示。

public enum EnumType {

ORDINAL,

STRING

}

ORDINAL表示持久化的为枚举类型的值，STRING表示持久化的为枚举类型的名称。默认为ORDINAL，持久化值。例如以上示例中标注的为STRING，这样持久化实体后，数据库中保存的是枚举类型的名称，如图所示。

若此时改成ORDINAL，代码如下：

         @Enumerated(EnumType.ORDINAL)

         public CustomerType getType() {

                   return type;

         }

则同样持久化的实体后，数据库保存的结果如图所示。

l         如何选择STRING和ORDINAL：

如果使用STRING保存，虽然从数据库中查询数据时非常直观，能够清楚的看出该类型代表意义，但这样也会带来其他的问题。若此时枚举类型的定义改变，例如上例中的枚举类型名称改为：

         public enum CustomerType {

                   CUST_COMPETITOR, INVESTOR, PARTNER, VENDER

         }

则此时数据库中保存的“COMPETITOR”的值将不能转化为枚举类型CustomerType中的“CUST_COMPETITOR”的值。但若使用ORDINAL则不会带来这种问题。所以建议使用ORDINAL类型来持久化枚举类型。

l         枚举类型的定义位置，实体外部VS实体内部。

上例中CustomerType枚举类型定义在CustomerEO实体内部，这是因为只有CustomerEO这个实体会使用CustomerType类型，其他的实体不会使用该类型。该类型与这个实体关系紧密联系。

但若此时多个实体公用一个枚举类型时，则可以将枚举类型单独定义，定义在实体的外部。有这样一个枚举类型BusinessLine，它定义在实体外部，代码如下：

public enum BusinessLine {

         REAL_ESTATE,FINANCE, NON_PROFIT

}

例如CustomerEO实体增加一个BusinessLine的枚举类型，代码如下所示。

@Entity

@Table(name = "customer")

public class CustomerEO implements java.io.Serializable {

……

         private BusinessLine businessLine;

         @Enumerated(EnumType.STRING)

         public BusinessLine getBusinessLine() {

                   return businessLine;

         }

         public void setBusinessLine(BusinessLine businessLine) {

                   this.businessLine = businessLine;

         }

}

We want a collection field belonging to an entity object to be sorted.

Solution

There are two possible solutions:

• If you want the collection to be sorted when loaded, but not necessarily keep that sorting order all the time, use the OrderBy annotation where you set the actual ORDER BY SQL clause. In that case, the collection can be of any type (e.g. Collection).

• If you want the collection to be sorted at all times, make it of type SortedSet or SortedMap and set the Sort annotation.

  • If the objects in the collection implements Comparable set type to SortType.NATURAL.
  • Otherwise set it to SortType.COMPARATOR and specify your own Comparator class in the comparator attribute.

Remarks

• There exists an annotation with name OrderBy in both the javax.persistence package as well as the org.hibernate.annotations package. The former should be used.