Geeks With Blogs
.NET Nomad What I've learned along the way

One of the things I love about NHibernate is the vibrant community that works so hard to continually improve the library.  I’ve been using NHibernate off and on for a number of years on projects that had short development cycles and it never failed to provide me with a solid framework for my Data Access Layer.

One particularly interesting thing is that NHibernate can generate Create, Update, and Delete scripts that allow you to manage your database and keep it more or less in sync with your entity classes.  It isn’t really a secret to how this works.  You build up a configuration object and the SchemaExport or SchemaUpdate objects look through your mapping information to determine what needs to happen with the database.  The only annoying catch was that there wasn’t a clean, out-of-the-box way to integrate this code with a Continuous Integration environment.

A few solutions surfaced (like these two), but all of them were dependant on a specific CI environment, and would obviously only work in the context of a CI environment.  There was also a solution that allowed you to automatically generate schemas on SessionFactory initialization, but that is a very dangerous practice as it could easily leak into you production build.  That kind of thing only has to happen once for you to wind up on the unemployment line.

So, I’ve recently developed a general purpose command line tool and an accompanying library that should allow developers more flexibility when integrating schema generation into their continuous integration environment of choice.  Further, since it is just a command line tool you can use it outside your CI environment which is great for developers like me that are constantly prototyping on their working copy.

The tool is called NHibernate Schema Tool (nst), and is currently hosted on Codeplex

Using the tool is pretty simple:


> nst /c:hibernate.cfg.xml /a:AssemblyWithMappingsAndModels.dll


The above command will connect to the database specified in your NHibernate configuration file, and use the mapping files embedded in the AssemblyWithMappingsAndModels.dll as input to the schema generation process.

By default nst will issue a create command which will result in a DDL script that will drop all artifacts in the target database before re-creating them.  You can control the operation by using the /o switch to specify either Create, Update, or Delete.  For example, if I just added a new entity to my domain model and it maps to a new table in the database I can simply say:


> nst /c:hibernate.cfg.xml /a:AssemblyWithMappingsAndModels.dll /o:Update


This should only add the missing database artifacts and not cause any data loss.

One other thing that I thought was missing from other solutions was any sort of flexibility in where mapping information could come from.  You simply had to adhere to the standard that your mapping files where embedded in the same assembly as your domain classes.  Whether violating this convention is advisable is up to the tech lead on the project, but let’s say you have a situation where you have to store your mapping files in a directory on the file system and your domain classes are obviously in an assembly.  The NHibernate Schema Tool supports this scenario just fine:


> nst /c:hibernate.cfg.xml /d:DirectoryWithMappingFiles /m:AssemblyWithDomainClasses.dll


The /d switch allows you to specify the directory (or directories separated by ;) that contain your hbm.xml files.  You must also supply the assemblies containing the corresponding domain classes by using the /m switch.

How about one more scenario? I try my best to adhere to the POCO & Persistence Ignorance principles.  In my mind you can’t satisfy both if you are storing ORM specific data in the same assemblies as your domain classes.  So, I made nst support that scenario:


> nst /c:hibernate.cfg.xml /a:AssemblyWithOnlyMappings.dll /m:AssemblyWithOnlyModels.dll


The above command looks for embedded mapping files from AssemblyWithOnlyMappings and expects the associated domain classes to be defined in AssemblyWithOnlyModels.

If it hasn’t been made clear yet the /a, /d, and /m options are all able to take in multiple values by using a semi-color (;) to separate them.  You can also mix and match by specifying all three switches as input to nst.


I hope that the NHibernate Schema Tool makes it a little easier to integrate schema generation for NHibernate mappings with current and future Continuous Integration environments and that it can aid other developers when prototyping out new entities for the domain model.


Again, you can grab the bits from the project's page at Codeplex.

Posted on Monday, February 22, 2010 12:19 PM | Back to top

Comments on this post: NHibernate Schema Tool (SchemaExport, SchemaUpdate)

# re: NHibernate Schema Tool (SchemaExport, SchemaUpdate)
Requesting Gravatar...
I've forked this project to include an option for populating the database, and updated everything to NHibernate 3.0.0.

More info:
Left by Balena on Dec 27, 2011 10:00 AM

# Solution for fluent Nhibernate
Requesting Gravatar...
Fluent Hibibernate doesn't use hibernate.cfg.xml. Instead, it uses map classes. Do you please tell me about how to use nst for fluent Nhibernate. Thanks in advance.
Left by Tiemoon on Feb 28, 2012 8:24 PM

Your comment:
 (will show your gravatar)

Copyright © newman | Powered by: