grails notes

Grails note to future self: domain object String are assumed to be not nullable. Plus, .save() with failed validation returns false but does not throw an exception.
(You can call .save(failOnError: true) though)
---
Also, IntelliJ's debugging with breakpoints wouldn't work until I followed the advice at http://stackoverflow.com/questions/19247944/intellij-idea-debugger-isnt-working-on-a-grails-project, namely swapping out BuildConfig.groovy's grails.project.fork to

grails.project.fork = [
        test: false,
        run: false
]
---
Also, when making a domain object, it can be tempting to just define a 1 to Many relation with something like:

static hasMany = [ people : Person ]

The thing is, you might have to explicitly declare a member Set... also if you are adding in things to the many and they have a pointer the other way, you might have to explicitly set that as well. (I think using the default scaffolding hides some of the potential tripups of GORM)
---
LOL, this is turning into a liveblog.

Had some frustration because I assumed setting "many" members of a one to many relation, and then saving the parent object, would save the members. NOPE!

However, I like being able to say
def map = ["code": params.id,"group":myGroup, people: myGroup.goons as JSON];
That as JSON is pretty sweet, and a nice way to shove stuff into JQuery land.
---
YAARGH... if you're not doing things the right way and putting stuff in services and transactions and what not, DON'T FORGET TO FLUSH. I burnt like a super frustrating hour on this.
---
More late hour mistakes: unlike some similar systems, Grails isn't smart enough to say that a parameter coming in as the string "false" is actually boolean false.
---
OK, that was fun. By fun, I mean intensely frustrating at times, but with success at the end.

Probably my biggest rookie mistake was having my Grails controllers manipulate domain objects directly rather than using Services - which also would have helped me construct some better tests.

It's worth me reflecting on unit tests at that point. I write tons of ad-hoc, test-ish things when I'm developing, I tend to code in almost absurdly small tests and make sure what I just wrote works before moving on. But I guess each one is a proof to myself that I am using the system correctly... so when the part it's working on works, I throw the ad hoc test bit away. In general, I don't intuitively feel the value of preserving the ad hoc test by elevating it into a proper unit test; if what it's testing fails, that seems like a really fundamental problem in the underlying plumbing! I have more of a knack for component and integration tests.

A lot of smart people emphasize unit tests, and while they still feel "too small" to be useful to me (and also much more likely to be confirm implementation than functionality) I want to better internalize the instinct for them.

Here's a pretty good page: What I wish I knew about Grails before my first Grails Project.

GORM seems better than some alternatives, but its opaqueness added a lot of friction to this project. It's funny, too, because really the Object layer was an artifact I didn't care about much, just a middle man between some underlying relational storage, and the JSON that I really wanted. (Alas, the old "Object Oriented Porgramming Oversold" site, a surprising survivor of the worst of the geocities purges, finally sucumbed, but you can see it on the Internet Wayback machine. Again, sometimes it's hard to say that kind of thing without sounding like a kook, but I think he had some points - which is one reason why people dig "encapsulation over inheritance", for instance.)
---
PS if using "grails war" to build something for tomcat 6 (instead of 7) you may have to edit
grails.servlet.version = "3.0" 
to 2.5 in BuildConfig.groovy