Some workarounds for a few Grails 1.1.x bugs

The sun shines and Grails forges ahead in popularity. Things are good. However I would be kidding you if I hadn’t experienced some major pain in recent weeks on Grails projects due to a couple of specific bugs – and you know how I like to whine. Its not clear if they are new or regressions – and there is some nuance involved in these, so most of it is probably me doing what all we software devs hate in users, namely “pushing it to the limits”.

What’s happened is that I’ve found a couple of “minor” bugs, which have hit me in different ways and in different combinations in a client projects including the Weceem CMS 0.2 which is coming along nicely although we have had to battle with some of these problems. It seems like once you find something you can’t get away from it.

Anyway these issues have been raised in Jira and are scheduled for fixing soon. Here’s a breakdown of them and any workarounds:

1. Grails will no longer (?) let you bind null “noSelection” values to relationships. If you have noSelection=”['':'None']” or similar on a select box, if you select this on a nullable relationship field you will get a plethora of binding/validation errors. It seems the empty value is enough to have grails believe you are trying to create a new “inline” instance of the referenced class, which typically fails validation but may not depending on your constraints. Eg this could be creating extra instances of classes you don’t know about if you have lax constraints on the related class. Jira issue here.
   Current workaround: for a relationship to a “Template” object field named “template”, your action needs to do this:

   if (params.'template') params.remove('template')
   if (params.'template.id' == '') params.remove('template.id')

2. It is currently impossible to query for null associations on 1:1 relationships using any mechanism – criteria, dynamic finders, HQL all return empty results. This ties into the previous issue – say you want a UI to select the “Author” of a book but you only want to allow Author to be used once in any Book(s). To present a list of Authors that have no “book” associated requires this kind of query. This is actually a Hibernate bug that needs votes + comments to get it fixed. Grails Jira is here.
   Current workaround: the insanely inefficient list and collect (beware of blowing heap):

   Author.list().collect { it -> it.book == null }

3. Invoking tags as methods and passing in bodies is a bit broken. Jira issue here – and a workaround for FCK editor is jira’d here. Basically if you invoke a tag as a method and need to pass in a body… your mileage may vary. The body is output immediately when executed, instead of returned as a String. So if you try to say have your own tag that then calls the FCK editor tag with some canned data it won’t work.
   Current workaround: change the tag you call to not evaluate the body() until it is needed in the output. Another option (untested) is to embed the invocation of the tag into a GSP fragment and render that using g:render instead.
4. The “transients” settings on GORM classes is not currently inherited if you have descendent classes. This might be causing you some embarrassment if you aren’t aware of it. Eg. If you have a domain class with descendents, check your database schema and your data to see if values that should be transient are being persisted – in particular passwords. Jira is here.
   Current workaround: Always declare a transients propert in your descendents even if you don’t need it, assigning the inherited value. Eg something like:

   class HTMLContent extends Content {
       static transients = Content.transients + [ 'summary' ]
       //...
   }

Thanks to Graeme for his help confirming and nailing down these problems. Looking forward to fixes in 1.2

It seems that we really do need Grails users to hassle the maintainers of the components Grails depends on eg Hibernate, to get issues that break functionality in Grails fixed. All users of Grails are indirect users of these underlying technologies. This gives us rapid productivity gains, but can also cause delays getting issues resolved when they can’t be worked around in Grails.

So get the vote out – if you find a Grails issue dependent on another project’s bug, please vote for / comment on issues in those other issue trackers to up the pressure!