Your time is valuable. “Grails for CFML Developers” is a series of five-to-fifteen minute walk-throughs I’m writing to introduce you do Grails in a way that’s appropriate for anybody but targeted at people who know CFML.

Last time, we wrapped up work on relationships. This time, we’ll take a look at some real-world problems with using GORM and Hibernate. We don’t always have the convenience of creating a new database based on Grails conventions, or we may have to write an application that uses an existing database. To handle these situations, we’ll take a look at how Grails allows use to customize its database mappings.

Let’s get started.

Turning Off Grails Features

As we’ve seen, Grails assumes that you want to use optimistic locking, placing a ‘version’ property on your models and attempting to use a corresponding column in the database. Likewise, if you create properties named ‘dateCreated’ and ‘lastUpdated,’ it’ll maintain their data for you. However, these may not jive with an existing database, and you’ll need to turn them off. To do so, we’ll modify the static ‘mapping’ closure within a domain class, a theme that’s central to everything in this post:

Custom Table Name

Ever worked with a DBA that had a thing for obvious prefixes? I have. Every table had to have “tbl_” preceding its name. Maybe they never got over Hungarian Notation. Anyhow, Grails makes it easy to remap a table name:

Custom Column Names and Types

Some folks don’t like properties named ‘firstName’ to become columns named ‘first_name.’ I’m actually one of them: I’d simply prefer things to stay the same, but I’m willing to concede to Grails convention. If you’re not, it’s easy to control names:

Relationship Column Names

I finished this post, re-read it, and said “what’s missing?” I realized that if a DBA is giving you grief over conventions, you may need to know how to tell Grails to use foreign key column names like ‘otherThingId’ instead of ‘other_thing_id.’ Keeping with a Grails pattern, it’s fairly obvious:

Types: Using Hibernate Types

Hibernate includes a set of types that it translates into platform-specific database types. You’re free to state that your columns should be one of these instead of the Grails-inferred type.

Additionally, you can even implement your own types to match custom database types.

In this case, we’ll add a property named ‘massiveTextField’ and force Grails (Hibernate, really) to use the underlying database’s ‘large text’ column type, whatever that may be:

Types: Going Native

Our prior example simply lets Hibernate create a MySQL ‘text’ column, with a maximum length of 64kb. We may need more control. If so, we can sacrifice being platform-neutral and use ‘sqlType’ instead of ‘type,’ specifying a native database type:

Further Control

I’d recommend reading up on column and the other Database Mappings topics in the Grails Quick Reference. It basically covers how Grails wraps the most used Hibernate mapping items in a pretty friendly DSL. It’s pretty much all there: index control, precisions, foreign key naming, and so on.