englishteeth.co.uk

Some time ago I looked at what was necessary to have Grails work on an existing database rather than the green field scenario painted in most examples.

It seemed straight forward enough, but beyond curiosity, I didn’t have anything I was particularly trying to achieve, so I moved along.

Yesterday, once again messing around with grails, I found something I couldn’t seem to achieve via gorm.

Basically, I couldn’t define the column mapping for an embedded class (where instead of mapping classes onto separate tables a class can be “embedded” within the current table).

I had hoped it would be a straight forward as defining the column mappings in the embedded class definition, but unfortunately not. Any mappings appear to be ignored.

I tried in the embedding class. No. I even experimented with the embedded property, but that was a long shot I didn’t expect to work anyway.

It would seem I will have to define the mapping in the old fashioned hibernate configuration file way.

One useful thing I did find in this frustrating experiment is that the configuration setting …
dataSource {
logSql = "true"
}

… provides a more readable format than …
hibernate {
show_sql = "true"
}


Not a total loss then!

The usual grails approach is to create the database to reflect the model, but if there is an existing database there are a few things to bear in mind.

I got a good start on this from Grails on Oracle, but it’s a bit out of date now and is still from a having control over the database angle.

In the configuration
I was getting an “Unsupported feature” org.springframework.jdbc.support.MetaDataAccessException
Although this appeared to be down to the target database not supporting auto-detection, I was providing org.hibernate.dialect.OracleDialect in the hibernate properties. However, after checking the documentation on Grails Data Sources, this should have been in the data source.

dataSource {
  pooled = true
  driverClassName = "oracle.jdbc.OracleDriver"
  dialect = "org.hibernate.dialect.OracleDialect"
  username = "username"
  password = "password"
}
hibernate {
  show_sql = "true"
  cache.provider_class = "org.hibernate.cache.NoCacheProvider"
  current_session_context_class = "thread"
}

environments {
  development {
    dataSource {
      dbCreate = "update"
      url = "jdbc:oracle:thin:@path:port:sid"
    }
  }
}

After sorting that, the errors were SQL grammar related and needed to be dealt with at the domain object level; show_sql = “true” did work in the hibernate properties and helped identify where these were coming from.

In the domain objects
The differences are captured in mapping declaration… (duh!)

• I didn’t want my domain object to be the same name as the table.
• The id column in the table was not to the grails convention.
• There was no version column in the table.

(There was a lastUpdated column, but the first task was to get something working before I worried about optimistic locking!)

class MyDomainObject {

  static mapping = {
    table 'db_domain_object'
    id column:'domain_object_id'
    version false // no version column in table
  }

  String someProperty
  String someOtherProperty

}

Nothing earth shattering or difficult, but not exactly obvious from the server output.