select statement for discriminated class does not include discriminator column if no subclass exists
Description
Environment
Activity
I just noticed from the NH 2.0 alpha release notes
Added [ Table per subclass, using a discriminator ] Support to Nhibernate
http://ayende.com/Blog/archive/2008/03/31/NHibernate-2.0-Alpha-is-out.aspx
does this mean NH 2.0 supports this case?
oops, just noticed a typo. what I meant to say is this.
in the legacy system, I only want the records with a specific discriminator value. in the new system, each class uses a separate table.
that sounds good in theory, except that it's not reality. Say I'm loading data from a legacy database, which has a column that acts like a discriminator. Since NH doesn't include the discriminated column in the select statement, you end up getting all rows in the table, when you only want the rows with a specific value.
Now, say that I'm loading data from 2 different databases. One is legacy and one is new. In the new system I only want rows with a specific value in the discriminator column. In the new system each class uses a separate table. So although it's theoritically fine for the new system since the discriminator "isn't" a property, it's not fine for reading data out of the legacy system. Of course, there's always the work around I mentioned in the original post, but I would consider it a design flaw that NH doesn't include the discriminator column in the select.
Expected behavior.
The discriminator is not a property.
If you have subclasses NH load it to discriminate each DataReaderRow.
If you don't have subclasses NH don't need to know the discriminator because all Row represent states of the same class.
There appears to be a minor issue with discriminated classes. If I create a class that uses discriminator, but don't have a subclass, the generated select statement does not include the discriminated column in the query. I turned on show sql to verify that is the case. If i add a subclass, the issue goes away and the discriminated column is included in the select statement as expected.
I see two simple work arounds for this issue. The simple solution is to create a dummy subclass with a different discriminator value. some people may find this work around undesirable. The second work around is to create a view that includes the appropriate where clause and map the class to the view.