Friday, February 27, 2009

Grails many-to-many

by Richard Vowles

I am sure others have come across this and figured out, but just in case Google (TM) wishes to index it, I had the problem trying to figure out how to remove an item from the many part of one side of a many to many collection.

Here it basically was:

DanceStyle
static hasMany = [danceLevels:DanceLevel]
static belongsTo = DanceStyle


DanceLevel
static hasMany = [danceStyles:DanceStyle]

So the key here is that you can only remove/delete from the side noted in the belongsTo - you cannot take a dance style and remove a specific dance level from it, you have to find the dance styles on the dance level and remove the style - otherwise Hibernate (although it recognizes the dirty collection) does not do anything about it. No matter how you stuff about the cascade maping.

Friday, February 20, 2009

Grails plugins

by Richard Vowles

So I am working on a replacement website for a customer using Grails and I am using 7 plugins: acegi, easybtest, code-coverage, fck-editor, mail, morph-deploy and navigation. This is cool, the plugins are generally very good, but the only ones I have not had any problems with are easybtest, code-coverage and fck-editor. Why?

  • mail - mail has problems in that it isn't suitable for morph (mor.ph), it also has no support for attachements, has code that isn't reliable (when setting to/cc/bcc) and various other problems. I notice there is a mail-0.6-SNAPSHOT which adds support for headers - done by Peter Ledbrook, which has not yet seen the light of day.
  • acegi - when something goes wrong here, it is almost impossible to figure out what - there is little or no logging. This is really irritating. Other than that, it is an absolutely wonderful plugin that is mature and comprehensive and growing with the capabilities of the Internet (eg. Facebook and openId integration)
  • morph-deploy - this is an early work given the increasing popularity of morph amongst grails devotees, but it is missing the removal of the mail archive (which is understandable as you don't need to do it unless you have the mail plugin!). It is a pity it can't recognize plugins and remove their dependencies if morph doesn't want them
  • navigation - shipped this has blocking faults with requiring logging and occasionally loading before logging is loaded (which is now fixed by Marc Palmer in the latest snapshot) and also that when you have multiple navigation elements in a single controller it blows chunks (null pointers - which is as yet unfixed in the HEAD).
What does this mean for me? Well, I am using grails 1.1 (beta 3) now, and plugins are no longer included in the source tree (which is sensible, it is a good change), but it leads to a big pain in the backside problem - to use these plugins I have to fix them. To fix them - they are not in the local project, and managing them in a source code development environment when you have more than one developer and you need to share fixes is now problematic.

I'm going to need to figure out how to sort this out - and I've bitten the bullet and decided to join grails plugin dev to see if I can make a difference.