Thursday, January 23, 2014

Using database views in Grails

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 and country.

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 setting grails.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.

Share this post using Facebook, Twitter or Google+

5 comments:

  1. Great post!

    I only have one question. What about integration tests? Let me explain myself. If I create a db view and map it to my grails app is to reduce or hide the complex relationships to my app. I'm thinking about a search that implies some tables but in my grails app I want to keep it simple and just search in this view. If I write this business logic I want to test it, so how I can create the view during test-app phase?

    Regards, Iván.

    ReplyDelete
    Replies
    1. @Iván: You can think of the view just like any other table in your database. So, testing it is exactly the same as if you were testing a domain class that pointed at a table.

      Delete
    2. @Iván: Like tables views are typically created on application start (if they are not already available). So you can access them through domain classes during an integration test in the same way as you access tables (like Rick said).

      Delete
    3. Hi,

      thank you for your answers. I'm not really sure if I have understand you.

      What Rick says is that as the view is mapped with a grails domain class, during the startup the table with this fields will be created and I can use it like another domain class. The problem with this is that I'm testing my "fake" domain class instead of my database view.

      On the other hand, what I think Michael says is that the view will be created during the startup by the database migration plugin. Is it right? In this case I can test my view without problems, but the question is: do the database migration plugin execute the migrations on application start in test-app phase?

      Thanks and regards, Iván.

      Delete
    4. You can enable the automatic database migration using the 'grails.plugin.databasemigration.updateOnStart' property. I guess if you set it to true for the test environment it should work for tests too.

      Delete