2014-11-25 9:29 GMT+01:00 Emmanuel Bernard <emman...@hibernate.org>:
> This is a user related question that should go on our forums
> https://forums.hibernate.org
>
It's intended as a question/discussion on the design of Hibernate, which is
why I thought it was relevant here. The background is that the same
question has appeared for NHibernate, which I'm involved with.
> But to answer you, you sometimes want to have a physical table for that
> abstract class. So Hibernate ORM’s “abstract” really means map it to a
> table or not. Java’s abstract has a different meaning, it means must be
> subclassed or not. Mapping both together does not really work.
>
According to the documentation, it seems to only be used together with
union-subclass, where the tables for the subclasses must contain columns
also for any base class properties.
So I can understand that I might want to specify abstract=true for a
non-abstract base class in case I don't want to have instances of it, and
am unable to change the class. But is there any situation where I would
want to have a table for an abstract superclass when using union-subclass?
Wouldn't any columns in such a table be inaccessible anyway due to never
being used by Hibernate?
Or to put it another way, if it cannot be removed completely, would this
default value be useful in the sense that it would be correct for most
users most of the time?
abstract={IsAbstract(theClass)}
Not that I'm proposing to have it changed, I assume it would be too much of
a compatibility problem. However, in newer and less stable mapping
frameworks (NH's mapping-by-code) it might be possible.
Could you propose a small pull request that clarifies this in the
> documentation ?
>
II think the mechanics of it are ok. When I understand the design issues
that might call for abstract != classIsAbstract, I could certainly submit a
few lines on that.
> Emmanuel
>
> On 24 Nov 2014, at 11:58, Oskar Berggren <oskar.bergg...@gmail.com> wrote:
>
> Hi,
>
> The Hibernate documentation (section 10.1.5. Table per concrete class
>
> http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch10.html#inheritance-tableperconcrete
> ) says:
>
> If your superclass is abstract, map it with abstract="true". If it is not
>
> abstract,
>
> an additional table (it defaults to PAYMENT in the example above), is
>
> needed
>
> to hold instances of the superclass.
>
>
> Why is this keyword needed? Couldn't abstract classes be detected
> automatically using reflection?
>
>
> /Oskar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
