Emmanuel communicated the following to me, and I figured it made sense to post it here since it is directly relevant (hopefully he won't mind):
Quote:
I did not properly understood the forum case hence the "unless you're not explaining all the details" :-)
What you can do could be possible (need to be tested) if the superclass was mapped with @MappedSuperclass, because in this case the FK is held by the entity class. But in your case, the FK is held by the superclass table, so from the relational POV, you have an association between the associated entity and the superclass, which is not what is described in your one to many association. I thought a lot about supporting this kind of case, but right now, I think it would be a bad thing to support: I like the consistency between the object model and the relational one.
Personally, I naturally assumed that you could map a relationship to a subclass using mappedBy on a superclass, even if the superclass is an entity. At least that's more like the way OO inheritance behaves. I recall changing to MappedSuperclass has other effects (at least w/ pure JPA), such loss of ability to do polymorphic queries. IMHO, seems it would be better to make the decision to go with MappedSuperclass versus Entity based on that kind of concern, not how you've set up the inheritance hierarchy. I can relate to wanting to keep things consistent, it's just that it seems like it should work as a few of us expected--so it takes time to figure out why it doesn't and how to work around it.
Instead of using MappedSuperclass, I chose to leave the superclass as an entity, make the accessors in the superclass abstract, and implement them in the subclass. Seems a bit duplicative, but it works and retains the consistency Emmanuel likes.