The Grails Object Relational Mapping (GORM)

(For more resources on Groovy DSL, see here.)

The Grails framework is an open source web application framework built for the Groovy language. Grails not only leverages Hibernate under the covers as its persistence layer, but also implements its own Object Relational Mapping layer for Groovy, known as GORM. With GORM, we can take a POGO class and decorate it with DSL-like settings in order to control how it is persisted.

Grails programmers use GORM classes as a mini language for describing the persistent objects in their application. In this section, we will do a whistle-stop tour of the features of Grails. This won’t be a tutorial on building Grails applications, as the subject is too big to be covered here. Our main focus will be on how GORM implements its Object model in the domain classes.

Grails quick start

Before we proceed, we need to install Grails and get a basic app installation up and running. The Grails’ download and installation instructions can be found at http://www.grails.org/Installation. Once it has been installed, and with the Grails binaries in your path, navigate to a workspace directory and issue the following command:

grails create-app GroovyDSL

This builds a Grails application tree called GroovyDSL under your current workspace directory. If we now navigate to this directory, we can launch the Grails app. By default, the app will display a welcome page at http://localhost:8080/GroovyDSL/.

cd GroovyDSL
grails run-app

The grails-app directory

The GroovyDSL application that we built earlier has a grails-app subdirectory, which is where the application source files for our application will reside. We only need to concern ourselves with the grails-app/domain directory for this discussion, but it’s worth understanding a little about some of the other important directories.

• grails-app/conf: This is where the Grails configuration files reside.
• grails-app/controllers: Grails uses a Model View Controller (MVC) architecture. The controller directory will contain the Groovy controller code for our UIs.
• grails-app/domain: This is where Grails stores the GORM model classes of the application.
• grails-app/view: This is where the Groovy Server Pages (GSPs), the Grails equivalent to JSPs are stored.

Grails has a number of shortcut commands that allow us to quickly build out the objects for our model. As we progress through this section, we will take a look back at these directories to see what files have been generated in these directories for us.

In this section, we will be taking a whistle-stop tour through GORM. You might like to dig deeper into both GORM and Grails yourself. You can find further online documentation for GORM at http://www.grails.org/GORM.

DataSource configuration

Out of the box, Grails is configured to use an embedded HSQL in-memory database. This is useful as a means of getting up and running quickly, and all of the example code will work perfectly well with the default configuration. Having an in-memory database is helpful for testing because we always start with a clean slate. However, for the purpose of this section, it’s also useful for us to have a proper database instance to peek into, in order to see how GORM maps Groovy objects into tables. We will configure our Grails application to persist in a MySQL database instance.

Grails allows us to have separate configuration environments for development, testing, and production. We will configure our development environment to point to a MySQL instance, but we can leave the production and testing environments as they are.

First of all we need to create a database, by using the mysqladmin command. This command will create a database called groovydsl, which is owned by the MySQL root user.

mysqladmin -u root create groovydsl

Database configuration in Grails is done by editing the DataSource.groovy source file in grails-app/conf. We are interested in the environments section of this file.

environments {
   development {
         dataSource {
                dbCreate = "create-drop"
                url = "jdbc:mysql://localhost/groovydsl"
                driverClassName = "com.mysql.jdbc.Driver"
                username = "root"
                password = ""
         }
   }
   test {
         dataSource {
                dbCreate = "create-drop"
                url = "jdbc:hsqldb:mem:testDb"
         }
   }
   production {
          dataSource {
                 dbCreate = "update"
                 url = "jdbc:hsqldb:mem:testDb"
          }
   }
}

The first interesting thing to note is that this is a mini Groovy DSL for describing data sources. In the previous version, we have edited the development dataSource entry to point to the MySQL groovydsl database that we created.

In early versions of Grails, there were three separate DataSource files that need to be configured for each environment, for example, DevelopmentDataSource.groovy. The equivalent DevelopmentDataSource.groovy file would be as follows:

class DevelopmentDataSource {
   boolean pooling = true
   String dbCreate = "create-drop"
   String url = " jdbc:mysql://localhost/groovydsl "
   String driverClassName = "com.mysql.jdbc.Driver"
   String username = "root"
   String password = ""
}

The dbCreate field tells GORM what it should do with tables in the database, on startup. Setting this to create-drop will tell GORM to drop a table if it exists already, and create a new table, each time it runs. This will keep the database tables in sync with our GORM objects. You can also set dbCreate to update or create.

DataSource.groovy is a handy little DSL for configuring the GORM database connections. Grails uses a utility class—groovu.utl. ConfigSlurper—for this DSL. The ConfigSlurper class allows us to easily parse a structured configuration file and convert it into a java.util.Properties object if we wish. Alternatively, we can navigate the ConfigObject returned by using dot notation. We can use the ConfigSlurper to open and navigate DataSource.groovy as shown in the next code snippet. ConfigSlurper has a built-in ability to partition the configuration by environment. If we construct the ConfigSlurper for a particular environment, it will only load the settings appropriate to that environment.

def development =
          new ConfigSlurper("development").parse(new
File('DataSource.groovy').toURL())
def production =
           new ConfigSlurper("production").parse(new
File('DataSource.groovy').toURL())
assert development.dataSource.dbCreate == "create-drop"
assert production.dataSource.dbCreate == "update"
def props = development.toProperties()
assert props["dataSource.dbCreate"] == "create-drop"