3
votes

I have 2 abstract Grails domain classes that look like

abstract class A {
   static hasMany = [ b : B ]
   static mapping = {
     tablePerHierarchy false
   }
}

class AChild extends A {
}

abstract class B {
   static belongsTo = A
   static mapping = {
     tablePerHierarchy false
   }
}

class BChild extends B {
}

I have some code that does

A a = new AChild()
a.b << new BChild()
a.save(flush:true)

This works as expected

Now, when I try to do

b.delete(flush:true)

This fails because of an referential integrity violation in the join table created between A/B. It looks like the first query by GORM as part of the delete is to do a delete from the B table, not the join table, and the join has a reference back to the B table by its id, which causes the violation.

delete from b where id=? and version=?

The reason I would like to keep A and B in the domain folder is so I can do things like A.list(), so moving it out to src/groovy would only be a very last option.

1
nice question, if A was not abstract will b.delete() be successful? - dsharew
I haven't tried all of the combinations of abstract/non-abstract to see what works. But I have other relationships in my code that work fine, so I'm assuming it's an abstract problem issue. in any case, I've reported it to the grails team. - Jeff Storey

1 Answers

0
votes

I think this is a bug in gorm with abstract classes. I have opened an issue https://github.com/grails/grails-core/issues/593