EJB3 does NOT require use of discriminators with JOINED mapping strategies. It is allowed for inferior implementations of the JOINED mapping strategy which require a discriminator. Hibernate does not need a discriminator because Hibernate is better than these other inferior implementations.

Hibernate may be better in other respects, but those other so-called "inferior" implementations can handle the following object model much more cleanly than Hibernate can:

@Entity(access=FIELD)
@Inheritance(strategy=JOINED)
public class TopLevel {
@Id
public int id;
... some other properties ...
}

@Entity(access=FIELD)
@Inheritance(discriminatorValue="middle")
public class ConcreteMiddleLevel extends TopLevel {
public int prop1;
public String prop2;
}

@Entity(access=FIELD)
public abstract class AbstractMiddleLevel extends TopLevel {
public String prop3;
public int prop4;
}

@Entity
@Inheritance(discriminatorValue="bottom1")
public class BottomLevel1 extends AbstractMiddleLevel { }

@Entity
@Inheritance(discriminatorValue="bottom2")
public class BottomLevel2 extends AbstractMiddleLevel { }

Without using discriminator values, how can Hibernate possibly distinguish between instances of BottomLevel1 and BottomLevel2, since they have no properties (and thus no tables of their own to outer-join with)?

The only way to model this with Hibernate, as far as I can tell, is to use the SINGLE_TABLE strategy and put @SecondaryTable on all the subclasses that have properties – at which point you also have to annotate each and every property with @Column(secondaryTable="whatever"). Which kind of defeats the purpose of EJB3's "configure by exception" philosophy.

A discriminator column can also be used to choose the right subclass for a lazy proxy. Now in a lazy OneToOne the proxy is always the topmost class, which is bad, because there is no way of telling the real class behind the proxy! I strongly suggest to revisit this issue and use an optional discriminator column as a hint.

See http://forum.hibernate.org/viewtopic.php?p=2319629#2319629 for an example.

discriminator is not gonna help your case.

I don't understand Gavin's stance on this issue.
Yes, Hibernate is very smart and its way of doing joined subclasses has superios performance over implementations that require a discriminator column.
But hibernate's algorithm doesn't prevent a discriminator column. In fact, Hibernate itself supports discriminator columns with joined subclasses, so why are you explicitly disallowing it in hibernate annotations?

It leaves users out in the cold who are using a legacy database; the only way to get around it is to not use annotations for the superclass and all subclasses.

In addition to that, even if a discriminator column never gives any performance bonuses, it still makes the database model more resilient. If for some reason (dbas mucking about the database by hand, other apps interfering with the direct use of sql) data ends up in multiple subclass tables, a discriminator column makes it possible to clean up the database, since it is the judge on what the intended subclass was.

Please change the three lines of code and make it possible to configure discriminator columns with joined subclasses using hibernate annotations.

Patch welcome, but it's probably more 3k lines than 3

I'd like to add another possible requirement for discriminator column support. If you have a discriminator column, you can have it inside DB constraints, and achieve constraints in which subclasses participate as different entities.

Example: I have the following entities:

A {
id, name
}

B extends A {
height
}

C extends A {
width
}

I need the following constraint: I don't want to allow (more than 1 2 or more instances of B with the same name, and I don't want (more than 1 2 or more instances of C with the same name. However, I DO want to allow 1 instance of B with the name "Jack", and another instance, this time of C, with that same name, "Jack". The only way to achieve this, I think, is having a discriminator column in A which will allow you to define a unique constraint containing A.discriminator and A.name.

It would be nice to see how the problem with the multiple joins is faced when the underlying DB has restriction on the number of joins one can execute in a single SQL? For instance MySQL seems to allow only 31 joins. What happens if the class hierarchy has more than 31 sub-classes?

I've the same problem with strategy=JOINED and Discriminator Values.
It's very important to me to have not null value of discriminator field, I use it in group queries.

Now I have to do in base classes something like:

public MyBase () { // set the value of discriminator's field kind = this.getClass().getSimpleName(); }

I think it is really ugly

4 years passed since this issue was opened.
Any changes?

"Status: Resolved Resolved
Resolution: Rejected "

Rejected? Why? This is very important functionality. Can anyone tell why this issue was skipped, please.

Using discriminator column with "joined" strategy used to work when we were using .hbm.xml files to describe ORM. Moreover it's clearly documentated:
http://docs.jboss.org/hibernate/stable/core/reference/fr/html/inheritance.html#inheritance-tablepersubclass-discriminator

SInce we moved to annotations instead of XML files, we can't do that anymore except using secondary tables but it's painful.