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.bergg...@gmail.com> wrote: > 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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
