blog rss feed

A guide to mapping databases in Grails with GORM

Keywords:

Last editor: Dave Cherry, last modified: Aug 3, 2008

An Introduction to GORM

GORM is the data abstraction layer that is used to map domain objects to database tables in Grails. Although GORM can be used outside of Grails, we do not discuss that here, we assume that you are using Grails. Infact we assume you are using V1.0 of Grails.

Grails gets you started quickly, when you create a new project, setting up the database for development should not be required, this is because Grails creates a default datasource that uses an in-memory database.

Unlike Ruby on Rails, GORM starts with the definition of a POGO (groovy object). This object is then used as the template to build the table on the database. Although this can be changed, it is by convention the default way. This article assumes that you are familiar with Grails, and have already created a test project that can be used for this article. If not create one now as follows:

grails create-app <your-app-name>

Creating a domain object

Before anything else we need to create the domain object, to do so lets use the grails command:

grails create-domain-class Book

Now you should have an empty class called Book.groovy in the grails-app/domain directory. Lets start by defining what we want our book object to represent.

Field Type Size Constraint
Id Long 64bit Primary Key
Title String 200 chars Not blank
Description String 20000 Not blank
Reference String 10-16 Not blank
Revision int 1-20 Not blank

So next we need to make the Book.groovy domain object represent the table above. Lets start by adding the appropriate fields. Each property added to a domain object is automagically added to the database table. Again, convention is used to do the mapping as follows. Domain object Book will be mapped to a table called book. Camel case thats commonly used in class names is mapped onto the database. For example: a domain object called MapMe would be mapped to a table called 'map_me'. Database column mapping follows the same rules.

class Book {

String title;
String description;
String reference;
int revision;

}

Dealing with constraints

So what we've done above is created column mappings for each of the properties, but they have no constraints; which in practice we would always need. Notice also that we did not add the ID field, this has been done by convention. GORM provides many constraints that suit nearly all situations. Here we will introduce a few of the common ones.

class Book {
static constraints = {
title(maxSize:
200, blank: false)
description(maxSize:
20000, blank: false)
reference(size:[
10..16], blank: false)
revision(range: [
1..20])
}

String title;
String description;
String reference;
int revision;

}

In the above class we have now defined the constraints for the object, these are placed in a static closure called constraints. Constraints are used for validation and building the database schema. For example if you don't apply constraints to a field the default for a string field is 255 chars, non unique. Below we list some of the most common constraint types:

  • size specifies the range of sizes that are acceptable eg: 5..42. Normally used with strings.
  • maxSize specifies the maximum size of the field. Normally used with strings.
  • blank defines if the field can be left blank (true, false). Normally used with strings
  • unique defines if the field is to be unique (true, false).
  • range defines the range of values for a numeric type.
1 2 3 4 5 >>

Please leave a comment



Search

Blog calendar

blog: previous month September 2010 blog: next month
su mo tu we th fr sa
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30