I guess I would have to disagree on the definition of 'expected'. If I remove the abstract keyword, then all of the subclasses end up in a single DB table. In my current project, I have a base class that the majority of DOs extend. The "Boolean active" field is in the base class so I don't want to have a single table for 90% of my DOs.
In the broader perspective I personally try to end up with a database model that makes sense independent of Grails or any specific framework. This is simply a best practice from my experience because the database often outlives a specific application or is leveraged by multiple applications, especially in larger orgs. Additionally these orgs have very specific conventions around their datamodeling requirements.
On the past couple of non-trivial Grails projects, I have run into a similar type of problem where I can get about 98% of the way there using GORM but eventually resort to redoing the whole model using Hibernate directly due to one of the many inconsistencies with Grails handling of field and mapping definitions in subclasses. Granted things have gotten better but there are still too many edge cases left to get tripped up by. It just seems like a shame to have so much available in GORM but still not be able to use it due to "obvious" and somewhat minor gaps in behavior.
These "broken" cases seem like they fall into one of two categories. I think it would be reasonable to expect the first set be supported ASAP?
- Standard: Single level abstract subclassing. Consistent inheritance of field and mapping definitions. Overriding of field and mapping definitions.
- Obscure: Multi-level inheritance. Self-referencing associations.
Here's the bottom line for me:
– Any complex enterprise app will end up with one or more subclassed Domain class scenarios
– Some low level tweaking of subclass properties or mappings will be required
– GORM does not currently handle these situations effectively
So the usage path for Grails under the above project conditions could be one of the following:
1) Use GORM with the understanding that subclassing may be problematic and the timeframe for a GORM-based solution is unknown (it appears to have been pushed back several times)
2) Use Hibernate from the start and exclusively (maybe this is really the best practice?)
3) Issues with GORM subclassing behavior are escalated and addressed in the next release (post 1.1 would possibly be another 4+ months down the road I'd imagine..probably too long/uncertain for any project in development or even in planning)