James Gregory

Notice: The content in this post is out of date, please refer to the Auto Mapping page in the Fluent NHibernate Wiki for the latest version.

This post should be short and sweet. We want to alter our has many relationship from Shelf to Product so that it has a cascade set on it. We don’t want this to affect all one-to-many’s in our domain, so we need to do this alteration only on the Shelf entity rather than with an ITypeConvention.

Notice: The content in this post is out of date, please refer to the Auto Mapping page in the Fluent NHibernate Wiki for the latest version.

This is a continuation of my previous Auto Mapping Introduction post, and is based on the same revision of Fluent NHibernate.

Auto mappings are generated based on a set of conventions, assumptions about your environment, that mean you can map your entire domain with a miniscule amount of code. Sometimes however, the conventions we supply are not to your liking, perhaps you’re a control freak and want 100% control, or more likely you’re working against an existing database that has it’s own set of standards. You’d still like to use the auto mapper, but can’t because it maps your entities all wrong.

Luckily for you we’ve thought about that, you can customise the conventions that the auto mapper uses.

Notice: The content in this post may be out of date, please refer to the Auto Mapping page in the Fluent NHibernate Wiki for the latest version.

Note: this was written against r190 of Fluent NHibernate, so you need to be at least at that revision to follow along.

Fluent NHibernate has a concept called Auto Mapping, which is a mechanism for automatically mapping all your entities based on a set of conventions.

Auto mapping utilises the principal of convention over configuration. Using this principal, the auto mapper inspects your entities and makes assumptions of what particular properties should be. Perhaps you have a property with the name of Id and type of int, the auto mapping might (and will by default) decide that this is an auto-incrementing primary key.

Following a discussion last night between myself, several others, and Roy Osherove, which Jeremy Miller also commented on.

The problem was incorrectly stated. There isn’t a lack of OSS projects that VB programmers can use, there’s a wealth of projects out there. I’ve personally used IoC containers, ORM tools, unit testing tools, and build automation tools in VB with my most recent employer. The issue is that more recent projects are using some language features of C# that the VB team hasn’t chose to implement. This has got Roy all up in arms because he feels that should be our problem (as the OSS developers).

I’ve just committed a breaking change to Fluent NHibernate (as of r184), which I thought I’d document here for anyone interested; it’s a reworking of the subclass syntax.

Mapping multiple subclasses with the same parent wasn’t a very fluent affair, and it was pretty wordy too. You can see a comparison of the old and new syntaxes below.