Question

I have a generic Repository class that wrap an Nhibernate session:

public class Repository<T>{

public IQueryable<T> GetAll(){

    return this.Session.Query<T>();
}

}

Despite the fact that I had data in the underlying DB table mapped to entity Foo, calling Repository.GetAll<Foo>() returned an empty enumerable. After much consternation, I found the issue to be that I had forgotten to load my class mapping into the SessionFactory.

I was floored that NHibernate does not throw an exception when attempting to load an entity type for which it has no mapping. This feels like exactly the kind of scenario that should cause NH to fail early and loudly.

Here’s the code that bootstraps NH. Notice the two lines loading the mapping were commented out

 private static Configuration BuildNHibernateConfig(Action<IDbIntegrationConfigurationProperties> dbIntegration)
        {
            var configuration = new Configuration();

            configuration
                .Proxy(p => p.ProxyFactoryFactory<DefaultProxyFactoryFactory>())
                .DataBaseIntegration(db =>
                {

                    db.ConnectionString = connectionString.Value;
                    db.Dialect<MsSql2008Dialect>();

                })
                .AddAssembly(typeof(ActionConfirmation<>).Assembly)
                .SetProperty("show_sql", "true")

                .CurrentSessionContext<LazySessionContext>();

         //   var mappings = GetMappings();
         //   configuration.AddDeserializedMapping(mappings, "Hydra");

            return configuration;
        }

        private static HbmMapping GetMappings()
        {
            var mapper = new ModelMapper();
            mapper.AddMapping<FacilityMap>();
            return mapper.CompileMappingForAllExplicitlyAddedEntities();

        }

Is this normal behavior or I have somehow misconfigured NH? Is there a way to override this behavior?

Answer 1

The LINQ implementation is a wrapper of the Criteria API and this issue has been reported and marked as “won’t fix”. The comment from Fabio Maulo indicates that verifying that the class is mapped was too much of a performance hit.

This was news to me as well and I at first assumed it was due to LINQ deferred execution.