Although Grails provides a great abstraction on top of hibernate (GORM), it is sometimes necessary to execute raw SQL against the configured data source. An example of when you might want to do this is when you’d like to execute a query with computed values for reporting purposes.

For example, say you have an “events” table, and you’d like to chart how many events were created grouped by the entry dates. You could have SQL like such:


select substring(event.data_created, 1, 10) as dateCreated, count(event.id) from event where event.date_created > ? group by dateCreated order by event.date_created;


With the above query, you’ll retrieve the amount of events grouped by the day they occurred. Since you’re not binding this return data to any entity, its easier (and in my opinion cleaner), to execute this query apart from any hibernate approach (such as a named query).

In your service, define the following:


def sessionFactory;


This line will ensure grails will inject the configured hibernate session factory into your service. Now, within your service method, you could write code as such:


Session session = sessionFactory.openSession();
session.doWork new Work() {
@Override
public void execute(Connection conn) throws SQLException {
// execute your statement against the connection
}
};


Let me know if you have any better ideas…

Per the Hibernate documentation, Hibernate can perform dirty checks only when the objects are loaded and changed in the scope of a single Session. This means we cannot use detached objects, but we must keep our session open for one conversation (multiple http requests) using Managed Sessions, just to get hibernate’s dirty check. This introduces new challenges of storing the Hibernate Session object in HttpSession, which fails if we deploy in a clustered environment, since most of the fields in Hibernate org.hibernate.impl.SessionImpl class are transient. So, how do we get the benefit of using Detached Objects and also get Hibernate’s automatic dirty checking?

The following is a brief background of how Hibernate does its dirty checking:

Hibernate Session contains a PersistenceContext object, which maintains a cache of all the objects read from the database as a Map. In the same Session, when I read an object from the db and make changes to it, Hibernate compares the objects and triggers the updates when the session is flushed. Every object in the PersistenceContext is called Persistent object. Once the session closes, the PersistenceContext is lost and so is the cached copy. A detached object, when saved, opens a new session containing an empty PersistenceContext, so there is nothing to compare against for the dirty check.

If we have an original cached copy of the Detached Object (a clone saved in HttpSession) and we are able to place that copy in the PersistenceContext somehow, we can get the dirty check to work. Here is how to do it.

Couple of points here, before we start reading the code -

1)  All your domain models have a generic way to expose their primary key. Here I have defined PrimaryKeyAwareDomainModelObject interface, which exposes a method to access the primary key property.

public interface PrimaryKeyAwareDomainModelObject {
public Integer getPrimaryKey();
}

2) You already have the original cached copy of the Detached Object, and have made changes to service layers to pass it to the DAO layer.

3) Also, your Detached Objects are POJO’s.

4) You are using Spring HibnerateDaoSupport, else you can get the SessionFactory to access the Hibernate Session.

/*** This class handles adding the cached Detached Object to PersistenceContext of a new Session.

** 1) Get a new session, or the session associated with this transaction from the
* sessionFactory.

*2) Inside the PersistentContext of the session, add the old
* Model object, so hibernate thinks that it was loaded as part of read
* operation in the same session

*3) Copy the changed values from the new Model
* object to the old Model object, since hibernate does identity check on the
* object in the persistenceContext, passing a new Model directly to hibernate
* will not trigger dirty checking, but create issues.

*4) Call usual saveOrUpdate, which will check the object if its dirty before update.
***/

import org.hibernate.EntityMode;
import org.hibernate.LockMode;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.engine.EntityKey;
import org.hibernate.engine.PersistenceContext;
import org.hibernate.engine.SessionFactoryImplementor;
import org.hibernate.engine.Status;
import org.hibernate.impl.SessionImpl;
import org.springframework.orm.hibernate3.support.HibernateDaoSupport;

public class HibBeforeUpdateListener<T extends PrimaryKeyAwareDomainModelObject, Q extends HibernateDaoSupport> {

/***
* Before doing a call on saveOrUpdate on hibernate session - fetch the
* session - get the PersistenceContext, and add the oldModelObj - copy the
* modified fields from new modelObj to oldModelObj.
* You can pass SessionFactory directly instead of HibernateDaoSupport
*/
@SuppressWarnings("unchecked")

public T beforeUpdate(T modelObj, T oldModelObj, Q dataAccessor) {

SessionFactory factory = dataAccessor.getSessionFactory();
Session session = factory.getCurrentSession();
// get the PersistenceContext of this session
PersistenceContext persistenceContext = session instanceof SessionImpl ? ((SessionImpl) session).getPersistenceContext(): null;
if (null != persistenceContext) {
addEntityToPersistenceContext(persistenceContext, oldModelObj,(SessionFactoryImplementor) factory);
}
// copy modified values from newModel to oldModel

// I am using Dozer

return (T) DozerUtility.copy(modelObj, oldModelObj);
}

private EntityKey generateKey(T modelObj, SessionFactoryImplementor sessionFactory) {
// EntityKey is the key used in the map of objects stored in
// PersistenceContext  it requires the primary key, defined by the @Id annotation in the model class
// , persister object which is SingleTableEntityPersister class in my case, and our models type, which is POJO
return new EntityKey(modelObj.getPrimaryKey(), sessionFactory.getEntityPersister(modelObj.getClass().getCanonicalName()),EntityMode.POJO);
}

/***
 * Hibernate stores the entities as an EntityEntry inside a IdentityMap, ie.
 * 2 objects are equal, if they reference the same object, rather than
 * Object.equals and hashcode is equal. EntityEntry contains the original
 * object as loaded from the db, plus also its original state as an Object
 * array, called loadedState. This method mimics the same behavior of
 * hibernate internals, and stores the object and its loadedState.
 *
 * @param context
 * @param oldModelObj
 * @param sessionFactory
 */
 private void addEntityToPersistenceContext(PersistenceContext context, T oldModelObj, SessionFactoryImplementor sessionFactory) {
       Map<String, T> allEntitiesMap = new HashMap<String, T>();
       for(T modelObj : getAllEntityObjects(oldModelObj, allEntitiesMap).values()){
                 context.addEntity(modelObj, Status.MANAGED, sessionFactory.getEntityPersister(modelObj.getClass().getCanonicalName())
                                 .getPropertyValues(modelObj, EntityMode.POJO), generateKey(
                                  modelObj, sessionFactory), null, LockMode.READ, true,
                                  sessionFactory.getEntityPersister(modelObj.getClass().getCanonicalName()), false, true);
     }
 }

 /***
 * Make a list of all sub Entity objects instances inside the object,
 * and add them separately
 * @return
 */
 private Map<String, T> getAllEntityObjects(T object, Map<String, T> allEntityObjects){
   // definitely this object will be added to persistence context
   if(!allEntityObjects.containsKey(object.getClass().getCanonicalName())){
            allEntityObjects.put(object.getClass().getCanonicalName(), (T)object);
    }
   // get all the instance variables and check their annotations
   Field[] fields = object.getClass().getDeclaredFields();
   // if no fields (impossible scenario), then just add the object and send it back
    if(fields.length == 0){
     return allEntityObjects;
   }
   for(Field f : fields){
    Class fieldClass = f.getType();
    if(fieldClass.getAnnotation(javax.persistence.Entity.class) != null){
     try{
         f.setAccessible(true);
         Object fieldValue = f.get(object);
        // only add the domain model objects
         if(fieldValue instanceof PrimaryKeyAwareDomainModelObject && !allEntityObjects.containsKey(fieldClass.getCanonicalName())){
            allEntityObjects.put(fieldClass.getCanonicalName(), (T)fieldValue);
            getAllEntityObjects((T)fieldValue, allEntityObjects);
         }
      }catch(IllegalAccessException ex){
        // do nothing and move to next field
      }
    }
  }
    return allEntityObjects;
 }
}

And here is how to use it in a DAO -

public class MyDataAccessorImpl extends
HibernateDaoSupport{

public void update(T modelObj, T oldModelObj) {
PrimaryKeyAwareDomainModelObject modelObjToUpdate = new HibBeforeUpdateListener().beforeUpdate(modelObj, oldModelObj, this);
getHibernateTemplate().saveOrUpdate(modelObjToUpdate);
}

}

This approach was the most efficient that used Hibernate’s own public APIs. If anyone else has a similar approach to the same problem, I would love to hear…

Today I was tasked with converting some queries to HQL; however, in one instance, a mapping was not defined. My entities looked something like:

AuditObject
– id
– value
– modifiedBy
– updatedBy

UserObject
– id
– name

In my scenario, the AuditObject’s modifiedBy value should be the name of the user who’s ID is equal to the updatedBy field in the Audit table (I know this is a very strange situation, but I’ve inherited a legacy system).

The approach I used to solve this was to use a Cartesion/Cross join in HQL. So my HQL looked something similar to:

getHibernateTemplate.find("select new AuditObject({...}, user.name) from AuditObject as audit, UserObject as user where audit.id = ? and audit.updatedBy = user.id")

This returns me a list of AuditObjects with the modifiedBy property set as the user’s name. Also notice that I’m using the data-transfer approach by defining a constructor that takes in all the properties that I want set. This is very convenient, and hibernate creates the correct join syntax for me.

I’d be interested if any others out there have found other solutions to this problem.

I ran into this problem today while working at a client, and I thought I could help others out with a bit more information than I was able to find online.

The problem is that my client has a standard to have “WITH UR” appended to all SELECT queries. This wasn’t a problem with Spring JDBC, but now with the move to Hibernate, I had to find a way to provide this functionality. Keep in mind that I don’t have a choice in this standard, so I’m not arguing if appending “WITH UR” is a good approach or not.

Anyway, I came across this link,  http://opensource.atlassian.com/projects/hibernate/browse/HHH-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32665#action_32665, which provides a workaround for this very problem. It involves creating a Hibernate interceptor that checks the query before executing, and appending “WITH UR” as appropriate. For my case, since I can assume that every SELECT query requires this suffix, the interceptor code looks as follows:

public class DB2Interceptor extends EmptyInterceptor {

	private static final long serialVersionUID = 1L;

	private static final Logger logger = Logger.getLogger(DB2Interceptor.class
			.getName());

	@Override
	public String onPrepareStatement(String str) {

		// Transform the original query into lower case
		String compstr = str.toLowerCase();

		// Check if we're dealing with a simple select statement
		if (compstr.matches("^select.*") && !compstr.matches(".*for update.*")) {
			if (!compstr.matches(".*with ur.*")) {
				str += " with ur ";

				if (logger.isDebugEnabled()) {
					logger.debug("Appending \"WITH UR\" to query.");
				}
			}
		}
		return str;
	}
}

Now you can wire this up in your Spring application context as such:

<bean id="sessionFactory"
		class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
		<property name="dataSource" ref="dataSource" />
		<property name="entityInterceptor">
    		<bean class="com.company.dao.hibernate.DB2Interceptor"/>
  		</property>
...

Since this satisfies my requirement, I’m leaving the code as-is for my client; however, if you have a need of setting a specific transaction isolation value (as in the case of the link I mentioned previously), I have a better solution than his proposed Hashtable/thread approach.

Instead, create the ThreadUtils class as he has done, but make the TransactionManager class extend ThreadLocal to ensure this is specific to the calling thread. Be sure to remove the thread local after use, and you can even generate the getter/setter code in an aspect.

Since I wasn’t required to code the ThreadLocal side of things, I left that out; however, if anyway would benefit from seeing some extra code, let me know.