Over a million developers have joined DZone.

Using Database Views in Grails

DZone's Guide to

Using Database Views in Grails

· Java Zone
Free Resource

Build vs Buy a Data Quality Solution: Which is Best for You? Gain insights on a hybrid approach. Download white paper now!

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.

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: '..') {
		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.

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.

Build vs Buy a Data Quality Solution: Which is Best for You? Maintaining high quality data is essential for operational efficiency, meaningful analytics and good long-term customer relationships. But, when dealing with multiple sources of data, data quality becomes complex, so you need to know when you should build a custom data quality tools effort over canned solutions. Download our whitepaper for more insights into a hybrid approach.


Published at DZone with permission of Michael Scharhag, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}