Mostly Blather is moving from Bloger to Github Pages.

I am using Octopress with the Octostrap3 theme. I imported the old blogger site with jekyll-import.

Some of the formatting of the old site has been lost, and there seems to be no good way of bringing the comments over. Expect my next post to be about how it all worked out.

Note: The old site is still available here.

I need to do a bit of integration testing with Grails and both of the DBUnit plugins I found didn’t seem to be maintained.  To create a simple base class for DBUnit based integration tests turned out to be relatively simple to create.

For the purposes of this sample I created a grails project called bookstore with a single domain class called Book in the bookstore package.  This is what book domain class looks like:

package bookstore

class Book {
    String title
    String author
}

First I had to add the DBUnit dependency to /grails-app/conf/BuildConfig.groovy and also enable the maven central repository.  This is what the grails.project.dependency.resolution section now looks like:

grails.project.dependency.resolution = {
    inherits( "global" ) {
    }
    log "warn"
    repositories {        
        grailsPlugins()
        grailsHome()
        mavenCentral()
    }
    dependencies {
     test 'org.dbunit:dbunit:2.4.7'
    }
}

Next I created a base class for my DBUnit based tests.  I created a class named DbunitGroovyTestCase in /test/integration/bookstore.  The DataSource property named dataSource is injected from the Spring container when the integration tests are run, and I used the DatabaseDataSourceConnection class to create the DBUnit connection.

package bookstore

import javax.sql.DataSource;

import org.dbunit.database.DatabaseDataSourceConnection;
import org.dbunit.database.IDatabaseConnection;
import org.dbunit.dataset.xml.FlatXmlDataSetBuilder
import org.dbunit.dataset.xml.FlatXmlDataSet
import org.dbunit.dataset.IDataSet
import org.dbunit.operation.DatabaseOperation;

import groovy.util.GroovyTestCase;

class DbunitGroovyTestCase extends GroovyTestCase {

    DataSource dataSource
    IDatabaseConnection connection

    protected void setUp() {
        connection = new DatabaseDataSourceConnection(dataSource)
        DatabaseOperation.CLEAN_INSERT.execute(connection, dataSet)
    }

    protected void tearDown(){
        connection.close()
    }

    protected IDataSet getDataSet() {
        return new FlatXmlDataSetBuilder().build(new FileInputStream("test/dbunit/dataset.xml"));
    }

}

Here is a sample data set I created for the book table, located in test/dbunit/dataset.xml:

<dataset>
    <book id="1" version="1" author="Mark Twain" title="The Adventures of Tom Sawyer"/>
    <book id="2" version="1" author="Mark Twain" title="The Prince and the Pauper"/>
    <book id="3" version="1" author="Mark Twain" title="Adventures of Huckleberry Finn"/>
    <book id="4" version="1" author="Mark Twain" title="A Connecticut Yankee in King Arthur's Court"/>
</dataset>

Finally here is a sample integration test, located in test/integration/bookstore/BookPersistenceTest.groovy

package bookstore;

import grails.test.*

class BookPersistenceTest extends DbunitGroovyTestCase  {

    public void testFindAllByAuthor() throws Exception {
        def books = Book.findAllByAuthor("Mark Twain")
        assertEquals(4,books.size)
    }

    public void testFindByTitle() throws Exception {
        def book = Book.findByTitle("Adventures of Huckleberry Finn")
        assertEquals("Mark Twain",book.author)
    }

}

While (still) looking around for a Scala SQL equivalent of iBatis, I found this post on stackoverflow.  Daniel’s answer let me to Querulous.  Several years ago I used the Spring Framework JdbcTemplate and it worked fine, but it was kind of clunky.  That experience with JdbcTemplate led directly to using iBatis on that very same project.  I have been mostly working with Hibernate/JPA since then, but for a certain class of problems, a SQL centric solution seems a better fit that a full blown ORM.

After looking at Querulous, and seeing how it manages to de-clutter the anonymous inner class clunkyness that is JdbcTemplate I’m left wondering if this isn’t the way I should go.

Here is a quick example from the JdbcTemplate documentation in Java:

Collection actors = this.jdbcTemplate.query(
    "select first_name, surname from t_actor",
    new RowMapper() {

        public Object mapRow(ResultSet rs, int rowNum) throws SQLException {
            Actor actor = new Actor();
            actor.setFirstName(rs.getString("first_name"));
            actor.setSurname(rs.getString("surname"));
            return actor;
        }
    });

Here is the equivalent with Querulous in Scala:

  val actors = queryEvaluator.select("select first_name, surname from t_actor") { row =>
    new Actor(row.getString("first_name"), row.getString("surname"))
  }

Simple and easy to understand.  Can’t beat that.