When I started to play with Grails, I was impressed with the design of it. However, as soon as I got into actually developing a Grails application of my own, I have found myself spending (read: wasting) a lot of time on issues, not documented, that only a newbie like me would do, but that ate a lot of my time. So, to save you from the same (and your time from wasting), here’s a list of “gotchas” I ran into:

The list:

• Use size instead of length.
• Use right type parent reference when defining one-to-many relationship
• Unit testing
  • Don’t call dynamic methods from controller or unit test
  • Hidden validation error messages
  • Hidden unit test error log
    

Details:

• Domain property constraints: do not use length, but size. If you use length, you won’t be warned at all, but it won’t work either. And a book (and a very good one!) by Graeme, the “The Definitive Guide to GRAILS”, still uses the “length” in all examples. So, stay warned.

• When defining a one-to-many relationship, in the child object you have to define a declare it by static belongsTo = Parent, but also you need to define a property that references the parent. Now, this property, has to be of the Parent type. As obvious, as it seems to be, I have spent another couple hours to figure out, why the dynamic views were not reflecting one side of the relationship. Again, there is no warning. It’s up to you, so stay alert.

• Unit testing
  • First, if you try to call dynamic methods (in controller you have: def scaffold = Book), from your unit tests, you’ll get an ugly message, that doesn’t help you understand what’s the problem. The thing is, you need to switch to static scaffolding in order to be able to call controller methods from unit tests.
  • If you have a def book = new Book(title:’Ala ma Kota’).save() and the constraints are violated by it, you’ll get a null returned from save() as a result. But how to find what is the problem with new Book()? Well, it’s a secret. Use book.errors.allErrors to get the list of errors and println on them. And by the way, they will not show up in the unit test stdout. See next bullet for this.
  • Unit tests send errors to a file well hidden in <app_base>/target folder.

– Stan Berka on Grails.org

Tags: Grails