[hibernate-dev] Why must abstract be specified in mappings?

[Steve Ebersole]

There is also the case of non-POJO entities...

But the issue is a matter of timing.  At the time this information is used
(to create the "denormalized table" mapping) we do not yet know the entity
Class reference.  So it is a matter of practicality given the current
Configuration/mapping design.

On Tue, Nov 25, 2014 at 4:31 AM, Oskar Berggren <oskar.berggren at gmail.com>
wrote:

> 2014-11-25 9:29 GMT+01:00 Emmanuel Bernard <emmanuel at 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.berggren at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>