views:

40

answers:

2

Background

We have several projects / applications running off the same model. They all have their own unique entities / tables, but also share 1 specific, common entity / table. I.e. Entities required by application A, will never be required by application B, except for the common table, and vice versa. Now the common table has relationships to application A's tables, as well as to application B's tables. Things get rather slow when loading large numbers of HBMs, so we implemented a system that only loads the HBMs required by the application that is currently running.

The problem

In application A, when we now access the common table / entity, like this:

session.Linq<CommonEntity> ().Where (...);

We get the following exception

NHibernate.MappingException: Association references unmapped class: (application B's entity)

I was hoping NHibernate would only break if we explicitly tried to access application B's tables via the relationships from the common entity, and that as a result, it wouldn't break because we never do that from application A. But alas.

Question

Is there a way to configure NHibernate to delay the validation of a relationship mapping until it is accessed?

We do use lazy loading.

+2  A: 

Configuration is a one-time operation, and the configuration must be 100% consistent when you build the SessionFactory.

If it's still too slow for you, the configuration can be serialized. See http://github.com/ayende/Effectus/blob/master/Effectus/Infrastructure/BootStrapper.cs

Diego Mijelshon
@Diego: Yes I know the configuration is a one time operation, but was hoping a partial model could be mapped. However, your serialization tip is the answer to our problem. I have implemented serialization, and preliminary tests show that the SessionFactory is now built in 10% to 20% of the original time. Thanx!
Jacques Bosch
+1  A: 

I do not know of a way to delay the validation, but I do not think so.

However maybe there is another option. You could try to use a separate set of mapping files for each of the applications. Each set containing only the entities needed for that application and the common table.

The mapping file for the common table must not include the columns that create the relations to tables belonging to the other applications.

So each application has its own consistent set of entities and would just ignore the unmapped columns.

Wolfgang
@Wolfgang: Yes, I did think of that. However, we will potentially have a large number of plug-in applications running on the same DB, sharing some tables, and it would become a maintenance pain to update all the separate models when there is a DB schema change on the common tables. Also we are using LLBLGen to generate the NHibernate entities and mappings and, not being very familiar with it, I don't know if it supports the generating of multiple sets. It might well.
Jacques Bosch