Big Data/Analytics Zone is brought to you in partnership with:

I am a Java Web Developer, Blogger, technology enthusiast and 3D graphic hobbyist. Mostly I am writing about Java related technologies including Java EE, Spring and Grails. Michael is a DZone MVB and is not an employee of DZone and has posted 23 posts at DZone. You can read more from them at their website. View Full User Profile

Using Database Views in Grails

01.25.2014
| 6363 views |
  • submit to reddit

This post is a quick explanation on how to use database views in Grails.

For an introduction I tried to summarize what database views are. However, I noticed I cannot describe it better than it is already done on Wikipedia. Therefore I will just quote the Wikipedia summary of View (SQL)here:

In database theory, a view is the result set of a stored query on the data, which the database users can query just as they would in a persistent database collection object. This pre-established query command is kept in the database dictionary. Unlike ordinary base tables in a relational database, a view does not form part of the physical schema: as a result set, it is a virtual table computed or collated from data in the database, dynamically when access to that view is requested. Changes applied to the data in a relevant underlying table are reflected in the data shown in subsequent invocations of the view.
(Wikipedia)

Example
Let's assume we have a Grails application with the following domain classes: 

class User {
String name
Address address
...
}
class Address {
String country
...
}

For whatever reason we want a domain class that contains direct references to the name and the country of an user. However, we do not want to duplicate these two values in another database table. A view can help us here.

Creating the view
At this point I assume you are already using the Grails database-migration plugin. If you don't you should clearly check it out. The plugin is automatically included with newer Grails versions and provides a convenient way to manage databases using change sets.

To create a view we just have to create a new change set:

changeSet(author: '..', id: '..') {
createView("""
SELECT u.id, u.name, a.country
FROM user u
JOIN address a on u.address_id = a.id
""", viewName: 'user_with_country')
}

Here we create a view named user_with_country which contains three values: user id, user name andcountry.

Creating the domain class
Like normal tables views can be mapped to domain classes. The domain class for our view looks very simple:

class UserWithCountry {
String name
String country
static mapping = {
table 'user_with_country'
version false
}
}

Note that we disable versioning by setting version to false (we don't have a version column in our view).

At this point we just have to be sure that our database change set is executed before hibernate tries to create/update tables on application start. This is typically be done by disabling the table creation of hibernate in DataSource.groovy and enabling the automatic migration on application start by settinggrails.plugin.databasemigration.updateOnStart to true. Alternatively this can be achieved by manually executing all new changesets by running the dbm-update command.

Usage
Now we can use our UserWithCountry class to access the view:

Address johnsAddress = new Address(country: 'england')
User john = new User(name: 'john', address: johnsAddress)
john.save(failOnError: true)
assert UserWithCountry.count() == 1
UserWithCountry johnFromEngland = UserWithCountry.get(john.id)
assert johnFromEngland.name == 'john'
assert johnFromEngland.country == 'england'

Advantages of views
I know the example I am using here is not the best. The relationship between User and Address is already very simple and a view isn't required here. However, if you have more sophisticated data structures views can be a nice way to hide complex relationships that would require joining a lot of tables. Views can also be used as security measure if you don't want to expose all columns of your tables to the application.

Published at DZone with permission of Michael Scharhag, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)