Wednesday, September 30, 2009

Grails Constraints Across Relationships

Holy Moley am I glad to see the back of this problem!

This blog post is a summary of an issue I raised on the Grails User mailing list, here, and let me first give thanks to Dave Klein and Daniel Honig who really helped in figuring out this issue and explaining it to me, even though the time difference meant I could not stay awake any longer :)

OK so, suppose we have the following domains:


class Parent {

static hasMany = [children: Child]

String name;

static constraints = {
}
}



and ...



class Child {
static belongsTo = [parent: Parent]

String name

static constraints = {
name nullable: false, blank: false
}
}



Here we can see typical one to many relationship which allows me (you) to do the following in say, a Grails Service:



def parent = new Parent(name:"Father")
def billy= new Child(name:"Billy")
parent.addToChidren(billy)
parent.save()



So what happens here? We create a Parent, add a child to it, call save() on the parent and because the child "belongsTo" the parent, the child instance is saved too. That's just good parenting in my opinion!

OK so, our Parent doesn't want to be confused and have 2 children with the same name, nothing wrong with this, it's just this parents preference! So the knee-jerk reaction is to add a "unique:true" constraint to the Child domain.... hmmm wait a minute, if we do this, this means that we can only have one child named "Billy" in the entire world, hmmm that wont work. So thinking about it again, we want the Child's name to be unique only for a specific parent, so maybe we do something like "unique:'parent'" on the name property of the Child domain. If we do this, our Child domain becomes:


class Child {
static belongsTo = [parent: Parent]

String name

static constraints = {
name nullable: false, blank: false, unique: 'parent'
}
}


OK so, now lets start afresh:


def parent = new Parent(name:"Father")
def billy= new Child(name:"Billy")
def robert= new Child(name:"Robert")
parent.addToChidren(billy)
parent.addToChidren(robert)
parent.save()


Uh oh, something has gone wrong, I am now getting this madness when i try to save(): "InvalidDataAccessApiUsageException: object references an unsaved transient instance - save the transient instance before flushing: Parent".... Hmmm, something is not quite right here.

After some very good debugging from the aforementioned Groovynauts, it was discovered that Grails needed the Parent to be persisted before proper validation could take place on the children. This is only a minor annoyance if we wrap the code in a withTransaction{} block, why you ask? If we use a withTransaction block we can save our Parent confident in the fact that if any constraints fail on our children (or something else goes wrong) we will not have Parents in our database missing their children. Grails will roll back and remove the Parent from the database for us. So here it is (place this in a service method for instance):


Parent.withTransaction{
def parent = new Parent(name:"Father")
parent.save(flush:true)

def billy= new Child(name:"Billy")
def robert= new Child(name:"Robert")
parent.addToChidren(billy)
parent.addToChidren(robert)
parent.save(flush:true)
}


And there we have it, no parent can have multiple children that have the same name! For more info on how this was all figured out, check the link to the user list above, also check here for how to do something like this in a single domain and not across relationships.

Oh and if you do attempt to add children with the same, a "org.springframework.dao.DataIntegrityViolationException" is thrown!

Thanks again to the grails community! I hope someone finds this blog useful and doesn't lose as may hours (days?) as i did :)

Oh and one more thing, if you add unique:'parent' after you have done some dev work, i.e. your database is already built, you may need to rebuild the database as MySql did not update the indexes for me, might save some more confusion!

6 comments:

  1. Good one John,
    You da man!

    ReplyDelete
  2. Ey, Mikhail, kak delischki?

    ReplyDelete
  3. Very well timed post. I was struggling to find any documentation on this. Keep up the "groovy" work!

    ReplyDelete
  4. Thanks for giving this back to the community! Was fun to read.

    ReplyDelete
  5. Thanks very useful!!

    ReplyDelete