1

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);
     }
}
Jim
  • 14,952
  • 15
  • 80
  • 167

1 Answers1

2

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)

Diego Mijelshon
  • 52,548
  • 16
  • 116
  • 154
  • Thanks, I have come to that conclusion myself. I think with correctly specified indexes it should be o.k. I am used to hand coding sql, so these join inefficiencies worry me. I should probably relax and let the technology do it's work and worry about the inefficiencies when they really present a problem. – Jim Apr 19 '12 at 04:38
  • It's not bad to have concerns about code efficiency, as long as they are backed by profiling data. ORMs are leaky abstractions anyway. But your approach is correct IMO. – Diego Mijelshon Apr 19 '12 at 12:20