Building GORM Criteria Queries Dynamically

I originally wrote most of the queries in the spring-security-ui plugin using HQL because I find it more intuitive than criteria queries, but HQL only works with Hibernate and relational databases. A pull request updated the queries to use criteria queries to allow the plugin to be used with NoSQL datastores, but one query didn’t fit the programming style that I was using. That wasn’t a big deal, but since a lot of the controller code is basically CRUD code and very similar to the others, I’ve tried to keep the code generic and push shared logic into the base classes.

The original HQL included this

hql.append " AND e.aclObjectIdentity.aclClass.id=:aclClass"

and the converted criteria code was

aclObjectIdentity {
   aclClass {
      eq 'id', params.long('aclClass')
   }
}

with the whole query being similar to this:

def results = lookupClass().createCriteria().list(max: max, offset: offset) {
   // other standard criteria method calls

   if (params.aclClass) {
      aclObjectIdentity {
         aclClass {
            eq 'id', params.long('aclClass')
         }
      }
   }
}

That got me thinking about creating a way to represent that two-level projection and criterion generically.

If we restore the omitted optional parentheses the code becomes

aclObjectIdentity({
   aclClass({
      eq('id', params.long('aclClass'))
   })
})

So it should be more clear that this is a sequence of method calls; calling aclObjectIdentity with a closure argument, then aclClass with a closure argument, and finally eq with a String and a long argument. Splitting out the closures as local variables makes it more clear, first as

def aclClassClosure = {
   eq('id', params.long('aclClass'))
}

aclObjectIdentity({
   aclClass(aclClassClosure)
})

and then

def aclClassClosure = {
   eq 'id', params.long('aclClass')
}

def aclObjectIdentityClosure = {
   aclClass(aclClassClosure)
}

aclObjectIdentity(aclObjectIdentityClosure)

To make this a bit more concrete, lets say we have three domain classes;

Department:

class Department {
   String name
}

Manager:

class Manager {
   String name
   Department department
}

and Employee:

class Employee {
   String name
   Manager manager
}

We create some instances:

Department d = new Department(name: 'department1').save()
Manager m = new Manager(name: 'manager1', department: d).save()
Employee e1 = new Employee(name: 'employee1', manager: m).save()
Employee e2 = new Employee(name: 'employee2', manager: m).save()

and later want to run a query:

Employee.createCriteria().list(max: 10, offset: 0) {
   eq 'name', 'employee1'

   manager {
      department {
         eq 'name', 'department1'
      }
   }
}

My goal is to represent this query with only some helper methods and without any closures (or as few as possible). Splitting that out like above we have

def departmentClosure = {
   eq 'name', 'department1'
}

def managerClosure = {
   department(departmentClosure)
}

def criteriaClosure = {
   eq 'name', 'employee1'

   manager(managerClosure)
}

Employee.createCriteria().list([max: 10, offset: 0], criteriaClosure)

When the query is run, the delegate of criteriaClosure is set to an instance of HibernateCriteriaBuilder when using Hibernate, or an analogous builder for MongoDB or whatever other GORM implementation you’re using. The builder has defined methods for eq, like, between, etc., so when you make those calls in your criteria closure they’re run on the builder.

It turns out that it works the same way if you split the closure into multiple closures and call them with the builder as the delegate for each. So a method like this works:

def runCriteria(Class clazz, List<Closure> criterias, Map paginateParams) {
   clazz.createCriteria().list(paginateParams) {
      for (Closure criteria in criterias) {
         criteria.delegate = delegate
         criteria()
      }
   }
}

and that means that we can split

Employee.createCriteria().list(max: 10, offset: 0) {
   eq 'name', 'employee1'

   manager {
      department {
         eq 'name', 'department1'
      }
   }
}

into

def closure1 = {
   eq 'name', 'employee1'
}

def closure2 = {
   manager {
      department {
         eq 'name', 'department1'
      }
   }
}

and run it as

runCriteria Employee, [closure1, closure2], [max: 10, offset: 0]

But how can we make that projection generic? It’s an inner method call, wrapped in one or more closures that project down to another domain class.

What I ultimately want is to be able to specify a projection with an inner criteria call without closures:

def projection = buildProjection('manager.department',
                                 'eq', ['name', 'department1'])
runCriteria Employee, [closure1, projection], [max: 10, offset: 0]

Here’s the buildProjection method that does this:

Closure buildProjection(String path, String criterionMethod, List args) {

   def invoker = { String projectionName, Closure subcriteria ->
      delegate."$projectionName"(subcriteria)
   }

   def closure = { ->
      delegate."$criterionMethod"(args)
   }

   for (String projectionName in (path.split('\\.').reverse())) {
      closure = invoker.clone().curry(projectionName, closure)
   }

   closure
}

To understand how this works, look again at the innermost closure:

department {
   eq 'name', 'department1'
}

This will be invoked as a method call on the delegate, in effect

delegate.department({
   eq 'name', 'department1'
})

Groovy lets us call methods dynamically using GStrings, so this is the same as

String methodName = 'department'

delegate."$methodName"({
   eq 'name', 'department1'
})

So we can represent the nested closures as an inner closure invoked as the closure argument of its containing closure, and that invoked as the closure argument of its containing closure, and so on until we run out of levels.

And we can build a closure that calls eq 'name', 'department1' (or any criterion method with arguments, this is just a simplified example), as

def closure = { ->
   delegate."$criterionMethod"(args)
}

So to represent the nested closures, start with an ‘invoker’ closure:

def invoker = { String projectionName, Closure subcriteria ->
   delegate."$projectionName"(subcriteria)
}

and successively clone it at each nesting level, and curry it to embed the projection name and its inner closure since the criteria builder doesn’t expect any closure arguments, working from the inside out:

for (String projectionName in (path.split('\\.').reverse())) {
   closure = invoker.clone().curry(projectionName, closure)
}

So, finally we can run the decomposed query as one or more ‘core’ criteria closures with standard criterion method calls, plus zero or more derived projection closures:

def criteria = {
   eq 'name', 'employee1'
}
def projection = buildProjection('manager.department',
                                 'eq', ['name', 'department1'])

runCriteria Employee, [criteria, projection], [max: 10, offset: 0]

I doubt there’s a lot of reuse potential here to be honest, but working through this helped me to better understand how GORM runs criteria queries. I’ll be talking about this and some other GORM topics at Greach next month, so if you find this interesting be sure to check out the recording of that talk.

4 Responses to “Building GORM Criteria Queries Dynamically”

  1. jneira says:

    Hi, interesting post, i found grails criteria dsl a little bit rigid when i started to use in grails 1.3.7. I did a hack with closures to compose them to build criterias in a flexible way:

    https://gist.github.com/jneira/1212513#file-darkmagic-groovy

    With closure composition, threading the closure delegate you can compose criteria in this way:

    https://gist.github.com/jneira/1212513#file-objetivo-groovy

    def like(property,val) {
    if (this[property])
    return {ilike (property,”%${val}%”)}
    }

    def getFilter() {
    like(“prop1″,”val1”) >>> like(“prop2″,”val2”)
    }

    (blog post about in spanish http://javierneirasanchez.blogspot.com.es/2011/09/abracadabra-componiendo-criterios-de.html)

  2. […] Building GORM Criteria Queries Dynamically (Burt Beckwith) […]

  3. Farai says:

    Very very informative, great article Burt, thanks.

  4. Aaron says:

    This is interesting, I was not thinking about generalizing the criteria creation methods when writing the code. In reading the article, two concerns crossed my mind. I question the validly of both concerns.

    My first was all the extra work we have do when writing a criteria, one thing I really like about criteria is how flexible they are while still being extremely readable. I found it interesting in your talk you mentioned that you like the HQL better since it looks more like SQL. I like the criteria better because it mimics the Domain Objects and I am already thinking about objects as I write code. I always felt it was really easy to read a criteria and understand what the another programmer was trying to accomplish.

    The second concern was around performance and if this puts extra cycles during the run time as groovy is interpreting the closures and GString methods. I would be interested to see a performance test if writing the one nested criteria versus doing the criteria as you mentioned above had any effect, especially when try to doing something with an absurd amount of nesting.

    Thanks for writing this article and the talk was interesting as well.

Leave a Reply

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 License.