Archive

Archive for September, 2009

Cruising on other people’s work

September 11th, 2009 No comments

I love it when other people do my work for me.  For example, I needed to store a few random settings in a Grails app, such as the last time a service polled an external resource.  So I went to the main Grails Plugin site and, sure enough, someone else has already written a Grails Settings plugin.  It needs a few enhancements to do what I want, but it’s better than starting from scratch.  While I was perusing the plugin list, I found a few others that can replace features I had started to sketch out (like Taggable) and was inspired by yet others that would let me easily add features that I hadn’t thought of before (like Commentable and Sparkline).

Another example is yet another good post by my friend and coworker Jeff Erikson detailing his research into problems with Grails config options getting wiped during integration tests.  I had been meaning to write up a note about how the GrailsUnitTestCase class hides the true config settings, so you don’t want to accidentally use it in integration tests.  Jeff took my little tip a lot farther with his post.  Thanks, Jeff!

Categories: grails, groovy, unit test Tags:

Corrections to Grails Documentation

September 5th, 2009 No comments

Here are two quick tips for anyone working with Grails 1.1.1:

1) The User Guide has conflicting info about cascading persistence.   Section 5.2.1.2 says “The default cascading behaviour is to cascade saves and updates, but not deletes unless a belongsTo is also specified.” Section 5.3.3 says, “If you do not define belongsTo then no cascades will happen and you will have to manually save each object.”

The former, 5.2.1.2, is correct. Create and Update actions are cascaded for one-to-many relations. However, hey are not cascaded for one-to-one relations.

2) Section 9.1 (Unit Testing) demonstrates how to pass in a list to the mockDomain(clazz, instanceList) call.  It then says that you can check that list to verify that persistence actions behaved as expected.  This is no longer correct.  The list is copied inside the mockDomain call.  To get access to the list of persisted objects for a class, use the MockUtils.TEST_INSTANCES map with the class name as the key.  For example:

def testInstances = []
mockDomain(Item, testInstances)
def i = new Item(name:"foo").save()
assertEquals 0, testInstances.size()
testInstances = MockUtils.TEST_INSTANCES[Item]
assertEquals 1, testInstances.size()

And in case you try the same thing as me, the mocking behavior does not support cascades.