Grails comes with many of the standard checks that you will need but there will be cases where these checks aren’t sufficient. If you need to check a value in relation to another value or do a more complicated check, you can create a custom validator. These are defined as closures with the "validator" name:

class User {
   String username
   String password

   static constraints = {
      username blank: false, unique: true
      password blank: false, size: 8..100, validator: { pwd, user ->
         if (user.password == pwd) {
            return 'user.password.matchesUsername'
         }
      }
   }
}

A custom validator can have from zero to 3 parameters. If it declares one its value is the field value being validated (declaring none is the same, except that there is one parameter with default closure name it):

static constraints = {
   ...
   fieldName validator: { fieldValue ->
      // validate the field's value
   }
}

If a custom validator declares two parameters then the first is the value and the second is the domain class instance being validated. This variant is useful if you need to access other persistent values in the instance, and also to access other class data such as dependency-injected fields. For example, it’s a common practice to delegate business logic to services. By adding a dependency injection for the service we can access it from the current instance:

class User {

   def userService

   String username
   String password

   static constraints = {
      ...
      password blank: false, size: 8..100, validator: { pwd, user ->
         return user.userService.validatePassword(pwd, user)
      }
   }
}

If the validator has three parameters then the first is the value, the second is the instance, and the third is the Spring Errors instance. Use this approach when you need to directly call rejectValue or other Errors methods:

static constraints = {
   ...
   fieldName validator: { fieldValue, instance, errors ->
      ...
   }
}

Grails ignores any return value when using the three-parameter variant since it’s assumed that your validator works directly with the Errors instance.

class Validators {
   static passwordCheck = { pwd, user -> ... }
   static otherValidator = { value, obj, errors -> ... }
}

static constraints = {
   ...
   password blank: false, size: 8..100, validator: Validators.passwordCheck
}

If you need to accessing the database in a custom validator be sure to wrap the calls in a withNewSession block. If you don’t you run the risk (only in Hibernate currently) of the query triggering a flush and causing unexpected problems.

To really take matters into your own hands you can completely bypass the standard validation approach and define your own validator class (or reuse an existing one, for example from a traditional Spring application). Each domain class artifact has a org.codehaus.groovy.grails.validation.GrailsDomainClassValidator. This is registered as a Spring bean with a bean name that’s the full class name with package and the suffix "Validator", so the com.myapp.User domain class would have a corresponding com.myapp.UserValidator validator bean. So to define your own, register it in grails-app/conf/spring/resources.groovy with the correct name and it will replace the one that Grails registers by default:

import com.myapp.MyUserValidator

beans = {
   'com.myapp.UserValidator'(MyUserValidator)
}

Put this class in src/groovy or src/java and implement the Spring org.springframework.validation.Validator interface. Grails validators support cascading to validate associated many-to-one fields; to participate in this implement org.codehaus.groovy.grails.validation.CascadingValidator instead. You’ll probably find that it’s most convenient to subclass org.codehaus.groovy.grails.validation.GrailsDomainClassValidator and override one or more of validate(Object obj, Errors errors), validate(Object obj, Errors errors, boolean cascade), and postValidate(Object obj, Errors errors).

If you just implement one of the validator interfaces and don’t subclass GrailsDomainClassValidator you’ll also need to wire up the validator to the domain class in BootStrap.groovy since this won’t be done automatically:

class BootStrap {

   def grailsApplication

   def init = { servletContext ->
      grailsApplication.getDomainClass('com.myapp.User').validator =
         grailsApplication.mainContext.getBean('com.myapp.UserValidator')
   }
}

There are also plugins available that offer custom validation. The extra-validators plugin has a validator for password confirmation, and one that checks post codes for the UK, the US, and Canada.

The constraints plugin does a great job of formalizing the process for creating custom constraints. Each validator is defined as a closure in its own class, and by convention the name of the class is used as the constraint type in the constraints block. For example if you have custom logic to validate a zip code, you can create a ZipCodeConstraint class in grails-app/utils and the plugin will make it available as zipCode:

class Address {
   String line1
   String line2
   String state
   String zip

   static constraints = {
      ...
      zip zipCode: true
   }
}

See the plugin documentation for more examples of how to use the plugin.

When debugging it’s common to render the validation errors, but you’ve probably found that the default toString representation of the Errors object isn’t very useful. Here’s a convenient way to add a getErrorStrings method to the MetaClass of all domain classes in BootStrap.groovy:

class BootStrap {

   def grailsApplication
   def messageSource

   def init = { servletContext ->

      for (dc in grailsApplication.domainClasses) {
         dc.metaClass.getErrorStrings = { Locale locale = Locale.getDefault() ->
            def stringsByField = [:]
            for (fieldErrors in delegate.errors) {
               for (error in fieldErrors.allErrors) {
                  def resolved = stringsByField[error.field]
                  if (!resolved) {
                     resolved = []
                     stringsByField[error.field] = resolved
                  }
                  resolved << messageSource.getMessage(error, locale)
               }
            }
            stringsByField
         }
      }
   }
}

It uses the messageSource bean to resolve the validation message from the appropriate messages.properties file for the specified Locale and returns a Map where the keys are field names and the values are a List of resolved validation messages. You can print all of the errors:

def person = new Person(...)
if (!person.save()) {
   log.debug "$person errors: $person.errorStrings"
}

or grab just the errors for a particular field:

def person = new Person(...)
if (!person.save()) {
   log.debug "$person username errors: $person.errorStrings.username"
}

In many cases a blank string and null are equivalent; there’s no value set. But HTTP submissions from web browser POST requests send blank strings for inputs without a value. This won’t be the case with non-HTTP data such as from other external clients like web services or during testing, so converting blanks to nulls for the HTTP tier will help simplify validation. While we’re at it we can also trim extra whitespace from submitted values.

To do this, create a filter in whatever package makes sense for your application (or add this code to an existing filters class):

grails create-filters com.mycompany.myapplication.SiteFilters

The name of the filter isn’t important; it’s just there so each one is distinct. In this case we want to filter all requests but ignore GET requests since we’re only concerned with form submissions, so we check for GET or POST with the isPost() metamethod added to HttpServletRequest:

package com.mycompany.myapplication

class SiteFilters {

   def filters = {
      blankToNullAndTrim(controller: '*', action: '*') {
         before = {
            if (request.post) {
               convertBlanksToNullsAndTrim(params)
            }
            true
         }
      }
   }

   private static void convertBlanksToNullsAndTrim(Map map) {
      def keys = [] + map.keySet() // copy to avoid ConcurrentModificationException
      for (name in keys) {
         def value = map[name]
         if (value instanceof String) {
            value = value.trim()
            if (value.length() == 0) {
               map[name] = null // don't remove - explicity set to null
            }
            else {
               map[name] = value // update if trimmed
            }
         }
         else if (value instanceof Map) {
            // recurse with empty nested param, e.g. "location":["id":""]
            convertBlanksToNullsAndTrim value
         }
      }
   }
}

If you use this approach you can remove all of your blank: false constraints since you’ll never have a blank string, only null or a String with a non-zero length.

I described this issue at SpringOne/2GX in 2010; you can watch the talk online at http://www.infoq.com/presentations/GORM-Performance and you can also see this discussed in my http://burtbeckwith.com/blog/?p=169 blog post which addresses these issues and has sample code and a PDF of an earlier presentation.

Once you have determined that the number of elements in a mapped collection will be a performance concern (there is no standard number for this - it depends on your use cases) you can address the issue by simply not using mapped collections. You will lose some convenience, but it is relatively easy regain a lot of it.

The solution for the OrderItem/Purchase many-to-one mapping is to remove the hasMany in Purchase, replace the belongsTo in OrderItem with a reference to the owning Purchase, for example Purchase purchase. This will result in the same database structure (unless you were using a join table which is rare in many-to-one) since there is still a foreign key from the order_item table to the purchase table. Saving an OrderItem instance changes, from adding it to the orderItems collection in Purchase to setting the purchase reference in the OrderItem and saving it directly. This will be more efficient and is arguably more intuitive.

One thing that is lost in this approach is a convenient way to get all of the OrderItem instances associated with a Purchase, but that’s easy to get back: add a method in the Purchase class that returns OrderItem.findAllByPurchase(this). You also lose cascaded deletes if you had specified the dependsOn property, but it’s simple enough to delete a Purchase in a transactional service method that deletes the associated OrderItem instances first.

The fix for many-to-many is more involved, but not too bad. Ordinarily Grails developers don’t think much about the join table that links the two "many" tables since it’s transparent in the code. But you can map a domain class to that table, and it just needs two properties, foreign keys for each of the other tables. If the primary key is defined as composite and comprised of these two foreign keys, the table structure will be the same as what Grails was using; this makes data migration a no-op. There is a bit more work involved since Hibernate requires that the join table domain class implement Serializable and have well-defined equals and hashCode methods. You can see an example of this in the above referenced presentation, and if you’re using the spring-security-core plugin you already have an example in your application since the UserRole class uses exactly this approach.