Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Closed
tbushell opened this Issue · 2 comments

2 participants

tbushell Gleb Chermennov
tbushell

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?

Details:

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

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)
        {
            log.BeginAutomappingType(type);
            var derivedMapping = autoMapper.Map(type, mappingTypes);

            Add(new PassThroughMappingProvider(derivedMapping));
        }

        log.BeginAutomappingType(typeToMap);
        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 tbushell referenced this issue from a commit in tbushell/fluent-nhibernate
tbushell tbushell Fix for issue #113 7453968
tbushell tbushell referenced this issue from a commit in tbushell/fluent-nhibernate
tbushell tbushell Fix for issue #113 d01cf18
Gleb Chermennov chester89 closed this
Gleb Chermennov chester89 referenced this issue from a commit in chester89/fluent-nhibernate
Gleb Chermennov chester89 basic tests for #113 - mapping simple properties in inheritance hiera…
…rchy
f5cde37
Gleb Chermennov
Collaborator

Yep, I think I can test this particular scenario.

Gleb Chermennov chester89 referenced this issue from a commit in chester89/fluent-nhibernate
Gleb Chermennov chester89 more tests for automapping inheritance hierarchies #113 d5d9f91
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.