CODEWITHSUNDEEP
javahibernategrailsgroovygrails-orm
Suren Aznauryan
Suren Aznauryan

Reputation: 1094

org.hibernate.MappingException when using tablePerConcreteClass inheritance strategy in Grails v3.2.9

I'm using grails v3.2.9

I have 2 domain classes(class A and class B) having some common properties. I have created a new class C, extracted common properties from A and B to C and made A and B to extend C as shown bellow:

class A extends C {
   String x
   static constraints = {}
}

class B extends C {
   String y
   static constraints = {}
}

class C {
   String z

   static constraints = {}

   static mapping = {
    tablePerConcreteClass true
   }
}

I want C to reflect JPA @MappedSuperClass, so I have checked the documentation for grails v3.1.12 and found about tablePerConcreteClass which seems to be exactly what I need, however in documentation for grails v3.2.9 there is noting about tablePerConcreteClass and I'm not sure even whether that strategy is supported by grails 3.2.9 or not.

Anyway I have tried to use tablePerConcreteClass with my grails v3.2.9 and got the following exception:

org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.grails.orm.hibernate.HibernateDatastore]: Constructor threw exception; nested exception is org.hibernate.MappingException: org.hibernate.dialect.MySQL5Dialect does not support sequences

I have seen some solutions to create the parent class in src/groovy package and make it abstract, but that is not what I need, I want the parent class to be a domain class as well to be able to write the constraints in a single place as well.

UPDATE ***** Also I have found out that if I make C abstract, put a relation into it and make A to extend it as follows:

abstract class C {
   Bar bar

   static constraints = {}
}

class A extends C {
   String x
   static constraints = {}
}

then the artificial property barId, allowing to get the id of the relation without loading it, is not created by grails, so using A.get(1).barId results into groovy.lang.MissingPropertyException. In contrast in case if we put Bar bar relation into the subclass A, then the barId artificial property is created, so please mention about the solution to this problem if any.

Upvotes: 2

Views: 144

Answers (1)

Daniel
Daniel

Reputation: 3370

You can use an abstract parent class and still write the constraints in a single place.

For example, you could put C into src/main/groovy as such:

@grails.gorm.dirty.checking.DirtyCheckDirtyCheck
abstract class C {
    String z

    static constraints = {}
}

Then in A and B, your constraints block would just look like:

static constraints = {
    importFrom C
}

You can even add additional constraints after the importFrom line if A and B might each have different additional constraints that do not exist in C.

Upvotes: 1

Related Questions