Good morning,

maintaining legacy DB applications is one of my jobs. Regularly I face the situation that an application supports different database plattforms but uses different schemas for each database plattform. In most cases this results from table or column names from earlier versions of the software that were regarded as reserved words on a database plattform introduced in a later version of the software. It's my job now to "refurbish" the software design and implementation, but I still have to deal with the legacy database schemas.

I already understood that I can specify different mappings in different sets of *.hbm.xml files. Then I can load the appropriate set mapping descriptions depending on the actual target database plattform, build a Configuration out of it and finally a SessionFactory. On this basement I can build my new, fancy C# / .NET application design.

But I don't like this approach. I would prefer loading the mapping from the assemblies or the embedded resources. As described in the Reference Documentation (Chapter 3.1) this approach eliminates any hardcoded filenames and allows reuse of the mapping files. In a second step I want to "patch" the "default mapping" generated from the embedded resources using additional, plattform-dependend mapping informations (e. g. Class "X" is mapped on table "Z" instead of "Y" because we use the Oracle-specific database schema now) before generating the final SessionFactory.

Can you please tell me if that is possible? Do you have hints on documentation / examples / best practices for me?

Best regards,

Gabriel Schmidt

i also prefer loading the mapping files as embedded resources in an assembly. You could put the name of the assembly containing the mappings in your application configuration file, and then let NHibernate load the assembly that you've specified in the config file

for instance:



this way, all you need to do is specify the assembly containing your database specific mappings in your config file. If you know that one deployment always uses a specific database mapping, this approach should be sufficient.

If however, you need your deployed application to switch between multiple database mappings at runtime you'll need to do something else.... perhaps specify all of the possible mapping assemblies in your config file, and then provide a way to switch between different SessionFactories... (one for legacy db1, one for legacy db2, ...). You'd still avoid hardcoding filenames in your code, they'd all be in the application configuration file. Constructing each sessionfactory is expensive though, so you'd only want to do this once... for a web application this isn't really a problem but if it's a winforms app, your users will have to get accustomed to a slow start up time :S

Thank you for your comment. After reviewing and reconsidering it for a few days I think your suggestion is the best practice.

Best regards,

Gabriel Schmidt

you're welcome :)

i'm just curious btw, which of the 2 situations are you dealing with? a specific database for each deployment, or a deployment that needs to deal with multiple databases?

Actually each deployment has to deal with one database only at the same time. The target RDBMS is configured during installation and can be one of several supported types (MS SQL, Oracle, Informix, MySQL). And the table or column names my vary depending on the target database.

So I will exactly do what you have suggested: the target RDBMS is determined during installation. I will store this information in some config file / registry / ... and load the assembly with the corresponding mapping at startup. With this solution I have abstracted from the naming anomalies and can manage the mapping information as embedded resources.

In the future I will need the szenario with one deployment dealing with multiple databases to implement data migration procedures from this legacy stuff to a new version including a solidly revised database schema.

Best regards,

Gabriel Schmidt