Not sure if there is a way that I'm missing here

If the column that I am using is a char(n), but my values could be from 1-n, then my discriminator value MUST have the same number of characters.

Example:

column here is a char(7)

INPUT
OUTPUT
PENDING

In defining my DiscriminatorValue( "INPUT" ) creates a failure of .... Object with id: X was not of the specified subclass: ... (Discriminator "INPUT ")

It appears that I have to define the DiscriminatorValue to the char value, so it would need to be DiscriminatorValue( "INPUT " );

Is this supposed to be how it operates?

In SQL, char(n) columns are defined to be exactly n characters long, and the implementation will right-pad values with blanks to get them to the proper length.

varchar(n) columns, on the other hand, can be up to n characters long.

So, yes, it's supposed to work the way you're observing.

I understand how SQL works and the difference between varchar and char. What's I'm suggesting is that for setting the discriminator value - wouldn't it make more sense for it to be a trimmed value - or give that option?

Hello?

Shouldn't the discriminator value be trimmed for CHAR columns?

Assuming that I would have values:

"ONE"
"TWO"
"THREE"

and it's defined as a char(5)

then for my DiscriminatorValue, I have to set it to:

(^=space)
"ONE^^"
"TWO^^"
"THREE"

I think it is your responsibility. If you say that a column should be char(5) values will be space-padded at insertion. When retrieving those values the spaces are of course not trimmed. If you need varchar behavior you should define the column as varchar(5).

I don't know how to answer your question. In SQL, the padded and unpadded values are equivalent, as you are aware, but in Java, when you retrieve the value of the char(5) column, you get back the padded value. Hibernate does the discriminator value comparisons in Java.

Hibernate's behavior may not be what you want, but I don't really see a problem with it. By using a fixed-width type, semantically you're saying that the values should be of fixed width, so it seems reasonable to me that the discriminator values should be, too.

If it bothers you too much, I think you could use a user type for the discriminator column - at least, the code seems to support it, although I didn't look into how to configure it, or even if it's possible to do so.

As many of us don't have a say in OLD database design, I wouldn't be surprised to see this out there more than anyone is saying.

I understand the reality of what you are saying, but it just seems that trimming that column simplifies...but the ship has sailed.