Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Hard to reproduce automapping bug in v. 1.1, 1.2, 1.3 #113

tbushell opened this Issue Dec 13, 2011 · 2 comments


None yet
2 participants

tbushell commented Dec 13, 2011

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.

Executive summary:

  • Automapping worked fine in FNH 1.0 - fails in 1.1, 1.2, 1.3
  • attempt to extract object model to separate project failed - problem was not reproduced
  • little or no help forthcoming from FNH community
  • need help to either:
    • reproduce the problem in standalone project, or
    • start debugging the FNH code - where to start?


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.


tbushell commented Dec 20, 2011

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);

            Add(new PassThroughMappingProvider(derivedMapping));

        var mapping = autoMapper.Map(typeToMap, mappingTypes);

        Add(new PassThroughMappingProvider(mapping));

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.

-Tom Bushell

tbushell added a commit to tbushell/fluent-nhibernate that referenced this issue Dec 20, 2011

tbushell added a commit to tbushell/fluent-nhibernate that referenced this issue Dec 20, 2011

chester89 added a commit that referenced this issue Apr 10, 2013

@chester89 chester89 closed this Apr 10, 2013

chester89 added a commit to chester89/fluent-nhibernate that referenced this issue Apr 11, 2013


chester89 commented Apr 11, 2013

Yep, I think I can test this particular scenario.

chester89 added a commit to chester89/fluent-nhibernate that referenced this issue Apr 13, 2013

chester89 added a commit that referenced this issue Apr 14, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment