jagregory/fluent-nhibernate — Issue #113: Hard to reproduce automapping bug in v. 1.1, 1.2, 1.3
Author: tbushell
Created: 2011-12-13 17:01:02+00:00
State: open

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.