Question

Is it possible to get a table per concrete mapping in nhibernate/fluent to issue a database statement to determine the type of class and then issue another statement for the detail rather than joining all the subclass tables in a massive left joined uber-statement.

In other words can the sub class detail be ‘lazy’ loaded.

I have a class heirarchy mapped using fluent nhibernate and ClassMap/SubClassMap mapping classes. Each derived class (most of them anyway) have their own table. So it’s a table per concrete class.

I have not specified discriminator values because they are used when all the sub classes are contained in the same table. I do however have an integer value in the base class table that indicates which type it is. Is nhibernate capable of using this data and issuing a lazy load for the derived class data. The discriminator value is an integer in the database that corresponds to an enum in the base class.

example.

public sealed class PartyMap : ClassMap<Party>
{
  public PartyMap()
  {
     Table("Party");
     // I thought this might do it, but it doesn't :-(
     Polymorphism.Explicit();
     Id(x => x.Id).Column("PartyId");
     Map(x => x.PartyType).CustomType<PartyType>().Column("PartyTypeId");
     Map( ...
     // if I specify this, nhibernate expects all the fields
     // to be in the base class table, above Table(...) is the only one used.
     // DiscriminateSubClassesOnColumn<int>("PartyTypeId", 0).AlwaysSelectWithValue();
   }
}

public class PersonMap : SubclassMap<Person>
{
    public PersonMap()
    {
        Table("Person");
        KeyColumn("PartyId");   
        // if I specify this, nhibernate expects all the fields
        // to be in the base class table, above Table(...) is ignored.      
        // DiscriminatorValue((int) PartyType.Person);
     }
}

Answer 1

Short answer: no, it is not possible. IIRC, the behavior is exactly the same even if you use a discriminator.

If too many joins are a concern (because you have lots of inheriting classes) you should consider using Table per class hierarchy, or Table per sublass with discriminator (if most classes have a similar set of properties, with only a few of them being totally different)