You can clone with
HTTPS or Subversion.
Note: Originally posted on Stack Overflow http://stackoverflow.com/questions/8345523/need-help-reproducing-fluent-nhibernate-automapping-bug-in-v-1-1-1-2-1-3, and the FNH mailing list.
After working very happily with FNH v. 1.0 for the past couple of years, I recently tried to upgrade our Automapped project to v. 1.3. I then tried v. 1.1 and v. 1.2.
Our object model no longer Automaps properly with v. 1.1, 1.2, or 1.3. Most of the classes seem to still map fine, but a few of them no longer do.
All of the classes that now fail to map are those deepest in the inheritance hierarchy - those that have 2 or more levels of inheritance.
Also, one thing I noticed - the classes that are not being automapped are all sub-classed by 2 or more levels. For example, I have a the following classes:
public abstract class OfeEntity
public class OfeMeasurementBase : OfeEntity
public class OfeDlsMeasurement : OfeMeasurementBase
OfeDlsMeasurement is not being mapped properly. OfeMeasurementBase, as well as several other classes that inherit from OfeEntity, are being persisted properly. In addition, there are also some other classes that have 2 levels, that are being automapped properly! So it's not as simple as how deep in the hierarchy they are.
I've turned on FNH diagnostics, and FNH is detecting all the classes as candidates for mapping. SQL is being generated to drop the associated DB tables, but no SQL is being generated to create the tables.
My attempts to narrow down the problem have been futile. I pulled out some of the classes that were failing into a separate test project, but then automapping worked again. (Perhaps because I had to comment out some dependencies with the actual project).
Started to trace into the FNH source, and verified that the missing classes are not being added to the Configuration.ClassMappings property that is passed to the NH's SchemaExport method, so I'm pretty sure it's an FNH bug. But I quickly got lost in the unfamiliar (to me) FNH code when I attempted to backtrack further.
I'm looking for suggestions on how to either find the bug myself, or generate some failing test that someone else can use to reproduce it.
If someone could point me in the right direction in the FNH code base, that would be very helpful. Something like "set a breakpoint in the ABC method in class DEF, and look at the XYZ variable - you should see this...", or equally specific.
Or suggest a series of tests to perform - or unit tests to write - that might help narrow down the problem.
Problem is in AutoPersistanceModel.AddMapping.
It calls GetTypeToMap, which returns the root base class. The base class gets mapped multiple times - but the type that was passed in never gets mapped.
Here's the fixed code (but see my comments below):
private void AddMapping(Type type)
Type typeToMap = GetTypeToMap(type);
// Fixes https://github.com/jagregory/fluent-nhibernate/issues/113,
// where 'type' would not be mapped if 'GetTypeToMap' returned the
// base type
if (typeToMap != type)
var derivedMapping = autoMapper.Map(type, mappingTypes);
var mapping = autoMapper.Map(typeToMap, mappingTypes);
This fixes my problem, and all the unit tests still pass. But I'm somewhat suspicious about the GetTypeToMap method, which always (as far as I can tell) returns the root base class, no matter how many levels of inheritance are in between.
But I have multiple levels of inheritance, and all the classes are now being mapped, so I obviously don't understand how it all works. Might be worth a look, though.
Also, I looked at the unit tests, and did not see any that checked for more than one or two levels of inheritance. Tried to create some, but without success.
Anyway, please review and add to the trunk.
Fix for issue #113
basic tests for #113 - mapping simple properties in inheritance hiera…
Yep, I think I can test this particular scenario.
more tests for automapping inheritance hierarchies #113