Grails: Validating Domain Object

In this series of articles I am going to talk about the validations or constraints that can be added to Grails domain objects so that any junk data should not get stored to the database and hence our database keeps clean from garbage data.

Grails validation capability is built on Spring's Validator API and data binding capabilities. However Grails takes this further and provides a unified way to define validation "constraints" with its constraints mechanism.Constraints in Grails are a way to declaratively specify validation rules. Most commonly they are applied to domain classes, however URL Mappings and Command Objects also support constraints. In subsequent topic I will discuss in detail about the validations that are being used in Grails.

Basic Validations:

Basic validation in Grails are pretty straight forward, expressed in the static constraints member of the class. Lets see in the following example how basic validation can be used in a domain class.

class User {
   String login
   String password
   String email
   Integer age

   static constraints = {
        login size: 5..15, blank: false, unique: true
        password size: 5..15, blank: false
        email email: true, blank: false
        age min: 18
    }
}

In this example we've declared that the login property must be between 5 and 15 characters long, it cannot be blank and must be unique. We've also applied other constraints to the password, email and age properties.By default, all domain class properties are not nullable (i.e. they have an implicit nullable: false constraint). One thing to note here is that constraints are only evaluated once which may be relevant for a constraint that relies on a value i-e if you create an instance of the domain object, the constraints are not evaluated. They will only get evaluated when validations on that domain object are checked by calling validate() method on that instance. When you call save() method, it will first call validate() method and after validating will save the data.

Custom Validations:

To do a simple custom validation, just add a validator closure to a property.Lets consider the following simple example.

static constraints = {
    iMustBeEven validator:  { value ->
        return (value % 2) == 0
    }
}

In the above example we are simply checking that the number should be even. Here we are passing only one parameter which is being validated. If we pass two parameters, the second is the instance of object being validated. For example, the Usage model needs an end date that’s after its start date:

class Usage {
    User user

    Date startDate
    Date endDate
    int maxUserSourceLinks

    static constraints = {
        maxUserSourceLinks min: 1

        endDate validator: { value, usage ->
            return value && value > usage.startDate
        }
    }
}

In the above example we are passing usage parameter which is being validated and we are checking that endDate should be after the startDate of the Usage domain object. Similarly if we pass three, we are playing with the underlying Spring bean validation object, and this is where we can add a custom error message. Note that the second argument can line up with a message code in our i18n files. So the endDate in the above example will look like this:

endDate validator: { value, usage, errors ->
    if ( value && value < usage.startDate ) {
        errors.rejectValue( "endDate", "usage.endDate.afterStartDate", "End date cannot be before start date.")
        return false
    }    
    return true
}

In this example we are validating that if endDate is before the startDate then display the error that can be found in 18n files.