Re: [hibernate-dev] Why must abstract be specified in mappings?
Ah you mean for tooling that might not have access to the classpath
(assuming the class based entity mode)?
Regardless of this Oskar, you are correct, it seems I got it backwards. It would be to
express that a non abstract class has no instance and thus no table
should be created.
If you are working on a type safe programmatic mapping API that receives
the class, then you could change that to the default you mention.
In fact that's what the annotation based mapping seems to do for
Hibernate ORM :)
On Tue 2014-11-25 8:42, Steve Ebersole wrote:
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(a)gmail.com>
wrote:
> 2014-11-25 9:29 GMT+01:00 Emmanuel Bernard <emmanuel(a)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(a)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#inher...
> > ) 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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>