Automapper: Incorrect mapping in case of multiple interfaces

[avgur]

Automapper version 4.2.1
In case when source implements more than one interface and we do not have mapping configuration for the source but have it for interfaces it will be impossible to use mapping configured for second (third, fourth...) interface

        public interface IChildA
        {
            string PropertyA { get; set; }
        }

        public interface IChildB
        {
            string PropertyB { get; set; }
        }

        public class Source : IChildA, IChildB
        {
            public string PropertyA { get; set; }

            public string PropertyB { get; set; }
        }

        public class Destination
        {
            public string PropertyA { get; set; }

            public string PropertyB { get; set; }
        }
...

        public void MappingTest()
        {
            var conf = new MapperConfiguration(
                config =>
                {
                    config.CreateMap<IChildA, Destination>();
                    config.CreateMap<IChildB, Destination>();
                });
            var mapper = conf.CreateMapper();

            var src = new Source { PropertyA = "A", PropertyB = "B" };
            var dest = new Destination();
            mapper.Map<IChildA, Destination>(src, dest); // will map PropertyA
            mapper.Map<IChildB, Destination>(src, dest); // will NOT map PropertyB

            Trace.WriteLine(dest.PropertyA == src.PropertyA); // true
            Trace.WriteLine(dest.PropertyB == src.PropertyB); // false !!!
        }

The code above will not fill PropertyB (It will in case we will change order of interfaces in the Source class declaration)

The reason is MapperConfiguration.ResolveTypeMap method:

        public TypeMap ResolveTypeMap(object source, object destination, Type sourceType, Type destinationType)
        {
            return ResolveTypeMap(source?.GetType() ?? sourceType, destination?.GetType() ?? destinationType);
        }

It will call source.GetType() and then will look for the first known mapping (it will be IChildA in our case), so "sourceType" (IChildB in our case) will be ignored and we will got invalid mapping.

[lbargaoanu]

You didn't call AssertConfigurationIsValid. Both your maps are invalid.

[avgur]

I was trying to provide as less code as possible, but specially for lbargaoanu i will be more verbouse:

Domain:

    public interface IChildA
    {
        string PropertyA { get; set; }
    }

    public interface IChildB
    {
        string PropertyB { get; set; }
    }

    public class Source : IChildA, IChildB
    {
        public string PropertyA { get; set; }

        public string PropertyB { get; set; }
    }

    public class Destination
    {
        public string PropertyA { get; set; }

        public string PropertyB { get; set; }
    }

Test:

            var conf = new MapperConfiguration(
                config =>
                {
                    config.CreateMap<IChildA, Destination>()
                        .ForMember(d => d.PropertyA, opt => opt.MapFrom(s => s.PropertyA))
                        .ForMember(d => d.PropertyB, opt => opt.Ignore());

                    config.CreateMap<IChildB, Destination>()
                        .ForMember(d => d.PropertyB, opt => opt.MapFrom(s => s.PropertyB))
                        .ForMember(d => d.PropertyA, opt => opt.Ignore());
                });
            conf.AssertConfigurationIsValid();

            var mapper = conf.CreateMapper();

            var src = new Source { PropertyA = "A", PropertyB = "B" };
            var dest = new Destination();
            mapper.Map<IChildA, Destination>(src, dest); // will map PropertyA
            mapper.Map<IChildB, Destination>(src, dest); // will NOT map PropertyB

            Console.WriteLine(dest.PropertyA == src.PropertyA); // true
            Console.WriteLine(dest.PropertyB == src.PropertyB); // false !!!

[lbargaoanu]

Those two map calls do exactly the same thing. You don't get to choose the type map to use this way. It is possible, but you don't want to go there. I don't know if that's an option, but you could create a map from Source to Destination and include the interface maps. Or something else with Include/IncludeBase.

[avgur]

I am sorry i cannot understand your point of view.
Each interface has own Property to map, so it is not the same mapping. It is not an option to create mapping from Source to Destination in my case.
I just found a bug inside AutoMapper and pointing to an error inside MapperConfiguration class which does not respect generic parameter TSource which comes from method mapper.Map
It looks like it is an easy task to fix that issue.

[jbogard]

Have you tried the 5.0 beta? A _lot_ of this stuff was re-done.

[avgur]

I will definitely check 5.0, i just a little bit scared about "beta" )

[lbargaoanu]

@jbogard This is the same old discussion. Nothing changed here.

[avgur]

I will add one more example

Domain:

    public interface IChildA
    {
        string PropertyA { get; set; }
    }

    public interface IChildB
    {
        string PropertyB { get; set; }
    }

    public class Source_A_B : IChildA, IChildB
    {
        public string PropertyA { get; set; }

        public string PropertyB { get; set; }
    }

    public class Source_B_A : IChildB, IChildA // changed order of interfaces
    {
        public string PropertyA { get; set; }

        public string PropertyB { get; set; }
    }    

    public class Destination
    {
        public string PropertyA { get; set; }

        public string PropertyB { get; set; }
    }

Test:

    var conf = new MapperConfiguration(
        config =>
        {
            config.CreateMap<IChildA, Destination>()
                .ForMember(d => d.PropertyA, opt => opt.MapFrom(s => s.PropertyA))
                .ForMember(d => d.PropertyB, opt => opt.Ignore());

            config.CreateMap<IChildB, Destination>()
                .ForMember(d => d.PropertyB, opt => opt.MapFrom(s => s.PropertyB))
                .ForMember(d => d.PropertyA, opt => opt.Ignore());
        });
    conf.AssertConfigurationIsValid();

    var mapper = conf.CreateMapper();

    var srcAB = new Source_A_B { PropertyA = "A", PropertyB = "B" };
    var dest1 = new Destination();
    mapper.Map<IChildA, Destination>(srcAB, dest1); // will map PropertyA
    mapper.Map<IChildB, Destination>(srcAB, dest1); // will NOT map PropertyB !!!

    Console.WriteLine(dest1.PropertyA == srcAB.PropertyA); // true
    Console.WriteLine(dest1.PropertyB == srcAB.PropertyB); // false !!!


    var srcBA = new Source_B_A { PropertyA = "A", PropertyB = "B" };
    var dest2 = new Destination();
    mapper.Map<IChildA, Destination>(srcBA, dest2); // will NOT map PropertyA !!!
    mapper.Map<IChildB, Destination>(srcBA, dest2); // will map PropertyB

    Console.WriteLine(dest2.PropertyA == srcBA.PropertyA); // false !!!
    Console.WriteLine(dest2.PropertyB == srcBA.PropertyB); // true

So mapping strategy depends from order of interfaces (!!!). Source_A_B mapped one way while Source_B_A mapped another. From my point of view it is a mistake to have a code dependent from interface ordering.

[jbogard]

Well, you have two competing mappings, so there has to be SOME way to decide.

What you're running into here is that AutoMapper takes into account the runtime type of the object when determining how to map. The generic arguments do NOT "select" a map, they merely do some casting underneath the covers for convenience. The runtime types trump all.

The reason for this is that very often people want the behavior of checking runtime types. I'm mapping subtypes and because I have derived types, I should check for those.

I'm happy to entertain other options, in a pull request, provided it doesn't break those other scenarios.

[jbogard]

So I tried an experiment to have mappings based off of the passed in type and not the runtime type, and sure enough, several tests failed. And basically it came down people wanting the opposite behavior of what you're describing - always go off of the runtime type.

I think this can be augmented though, to consider both the runtime type and the requested type for "preferred" type map to match up. I'll give this a shot.

[TylerCarlson1]

Maybe a settings that can be set in MapRequest class, so can say which mapping is perfered and then expose it in mapping options perhaps?

[jbogard]

Man, this is ugly to try and handle both scenarios. Changing the rules to fit the above scenario make about a dozen other tests fail. This one is a good example:

public class Container
{
    public BaseA Item { get; set; }
}

public class Container2
{
    public BaseB Item { get; set; }
}
public class BaseA
{
    public string Name { get; set; }
}

public class BaseB
{
    public string Name { get; set; }
}

public class ProxyOfSubA : SubA
{
}
public class SubA : BaseA
{
    public string Description { get; set; }
}

public class SubB : BaseB
{
    public string Description { get; set; }
}

            var config = new MapperConfiguration(cfg =>
            {
                cfg.CreateMap<BaseA, BaseB>().Include<SubA, SubB>();
                cfg.CreateMap<SubA, SubB>();
                cfg.CreateMap<Container, Container2>();
            });

            var mapped = config.CreateMapper().Map<Container, Container2>(new Container() { Item = new ProxyOfSubA() { Name = "Martin", Description = "Hello" } });
            Assert.IsType<SubB>(mapped.Item);

AutoMapper sees properties of BaseA -> BaseB. But the runtime value is a subtype of SubA, ProxyOfSubA. The runtime mapping is ProxyOfSubA -> BaseB, but we want to pick SubA -> SubB mapping. Instead, BaseB is chosen.

Basically, I can't get both behaviors to work without doing some multiple matching and doing a ranking. And that makes my head hurt.

[lbargaoanu]

If you feel like you must do something, I think an option like IgnoreRuntimeTypes is preferable to even more complexity in that code.

[jbogard]

I'm going to close this one. It's too confusing for me either way.

[oddbear]

Given this any more thoughts?

We have the same type of issues.

There is so much strange behavior on this scenario. Interface order on the class picks the mapping profile, and this might change based on the source object type.

The only workaround I have found is to use mapping to a Proxy in between. That is, not map A to B, but A to proxy of interface, to instance of B:

//Automapper 7.0.1
void Main()
{
    Mapper.Initialize(config =>
    {
        //Ordering has no impact here:
        config.CreateMap<IFly, IFly>();
        config.CreateMap<ISwim, ISwim>();
        config.CreateMap<IWalk, IWalk>();
    });

    //Does not throw any exception.
    Mapper.AssertConfigurationIsValid();

    var input = new Message {
        FinLenght = 1,
        WingLength = 2,
        LegLenght = 3,
        DoNotMap = 4
    };

    DoWork(input)
        .Dump("Using Workaround Methods");
    //WingLength: 2 
    //FinLenght: 1
    //LegLenght: 3
    //DoNotMap: -1
}

MyAnimal DoWork(object input)
{
    var output = new MyAnimal
    {
        FinLenght = -1,
        DoNotMap = -1,
        LegLenght = -1,
        WingLength = -1
    };

    void Hack<T>(T iface)
    {
        //Creates Proxy class of interface (must have CreateMap of all, or DoNotMap is also mapped).
        var hack = Mapper.Map<T>(iface);
        Mapper.Map(hack, output);
    }

    if (input is IFly fly)
    {
        Hack(fly);
    }

    if (input is ISwim swim)
    {
        Hack(swim); //Maps IFly
    }

    //No CreateMap for this one still picks IFly:
    if (input is IWalk walk)
    {
        Hack(walk); //Maps IFly
    }

    return output;
}

//If MemberList.Source, then ISwim will be used instead of IFly (source vs destination order)
public class Message : ISwim, IFly, IWalk
{
    public int WingLength { get; set; }
    public int FinLenght { get; set; }
    public int LegLenght { get; set; }
    public int DoNotMap { get; set; }
}

//Order of interfaces on destination chooses mapping profile used.
// - if we switch the placement, the result will be different.
// - if we remove CreateMap, of first interface, mapping will be different.
public class MyAnimal : IFly, IWalk, ISwim
{
    public int WingLength { get; set; }
    public int FinLenght { get; set; }
    public int LegLenght { get; set; }
    public int DoNotMap { get; set; }
}

public interface IFly
{
    int WingLength { get; set; }
}

public interface ISwim
{
    int FinLenght { get; set; }
}

public interface IWalk
{
    int LegLenght { get; set; }
}

[dimi3tron]

I've run in this issue several times over the past years so I'd love to see this issue reopened.

I believe this is a very valid and common use case. Many times we'll have classes pulling properties from multiple interfaces. We want to be able to create separate maps for each interface, as not all classes will inherit all interfaces. (for example a Company and a Contact will both have an Id and a Name, but only Company will have a VatNumber)

I'm not going to provide a code sample, as the examples provided by @avgur and @oddbear describe the issue perfectly.

Thank you for reconsidering.

[dimi3tron]

Quick thought on a workaround.
@oddbear 's idea about proxies got me thinking.

I don't want to create a proxy for every possible interface combo, so I wondered: can this be fixed using generics?
Turns out this is easily achieved using the magic of ValueTuple.

Consider the following map:

CreateMap<ValueTuple<IHasId, IHasEntityType>, Entity>()
    .ForMember(
        dest => dest.id,
        src => src.MapFrom(x => x.Item1.id)
    )
    .ForMember(
        dest => dest.type,
        src => src.MapFrom(x => x.Item2.GetEntityType());
    )

I can now easily map my model as such:

mapper.Map<Entity>(
    (model as IHasId, model as IHasEntityType)
);

Of course you'll still need to specify the different mapping combo's, but at least you won't have a bunch of singular-use proxies cluttering up your project.

[jbogard]

With something like this, where it's not a bug but a feature request, I'm open to PRs. I wouldn't use this functionality on my projects, which means for me its priority is zero. If someone can get it to work without breaking existing functionality, I'm happy to entertain a PR.

[oddbear]

I think it's strange that we can explicit ask for mapping of interfaces, and AutoMapper just ignores this. Map<TInterface, TEntity>(sourceModel, destination) or Map(sourceModel, destination, typeof(sourceInterface), typeof(destination)).

@dimi3tron now you will be limited by the order in the ValueTuple. But by using generics, you could just wrap it in a single type anyway? I would think something like this is simpler then:

//Linqpad script
void Main()
{
    //https://github.com/AutoMapper/AutoMapper/issues/1295
    var config = new MapperConfiguration(cfg =>
    {
        cfg.CreateMap<ValueTuple<IHasId, IHasEntityType>, Entity>()
            .ForMember(
                dest => dest.id,
                src => src.MapFrom(x => x.Item1.id)
            )
            .ForMember(
                dest => dest.type,
                src => src.MapFrom(x => x.Item2.GetEntityType())
            );

        cfg.CreateMap<InterfaceMap<IHasId>, Entity>()
            .ForMember(dest => dest.id, src => src.MapFrom(x => x.Value.id));

        cfg.CreateMap<InterfaceMap<IHasEntityType>, Entity>()
            .ForMember(dest => dest.type, src => src.MapFrom(x => x.Value.GetEntityType()));
    });

    var mapper = config.CreateMapper();

    var model = new TestModel
    {
        id = 321,
        name1 = 1,
        name2 = 2
    };

    //id: 321, type: 123, name1: 0, name2: 0
    mapper.Map<Entity>(
        (model as IHasId, model as IHasEntityType)
    ).Dump("map ValueTuple");

//  mapper.Map<Entity>(
//    (model as IHasEntityType, model as IHasId)
//  ).Dump("does not compute");

    //id: 321, type: 0, name1: 0, name2: 0
    var result_IHasId = mapper.MapInterface<IHasId, Entity>(model).Dump("map IHasId");

    //id: 0, type: 123, name1: 0, name2: 0
    mapper.MapInterface<IHasEntityType, Entity>(model).Dump("map IHasEntityType");

    //id: 321, type: 123, name1: 0, name2: 0
    mapper.MapInterface<IHasEntityType, Entity>(model, result_IHasId).Dump("map over");

    //Test that we don't have any new proxies:
    var proxyAssembly = AutoMapper.Execution.ProxyGenerator.GetProxyType(typeof(IDummy)).Assembly;
    proxyAssembly.GetTypes().Dump();
}

public static class MapperExtensions
{
    public static TDestination MapInterface<TSourceInterface, TDestination>(this IMapper mapper, TSourceInterface source)
    {
        return mapper.Map<TDestination>(new InterfaceMap<TSourceInterface>(source));
    }

    public static TDestination MapInterface<TSourceInterface, TDestination>(this IMapper mapper, TSourceInterface source, TDestination destination)
    {
        return mapper.Map<InterfaceMap<TSourceInterface>, TDestination>(new InterfaceMap<TSourceInterface>(source), destination);
    }
}

public class InterfaceMap<T>
{
    public T Value;

    public InterfaceMap(T value)
    {
        Value = value;
    }
}

public interface IDummy { }

public interface IHasId
{
    int id { get; set; }
}

public interface IHasEntityType
{
    int GetEntityType();
}

public class Entity
{
    public int id { get; set; }
    public int type { get; set; }
    public int name1 { get; set; }
    public int name2 { get; set; }
}

public class TestModel : IHasId, IHasEntityType
{
    public int id { get; set; }
    public int name1 { get; set; }
    public int name2 { get; set; }

    public int GetEntityType()
    {
        return 123;
    }
}

[jbogard]

Just as many people think it’s strange you can tell AutoMapper to ignore
the runtime types. Because I can’t tell when you call the method that you
want the type parameter or the runtime type just because they don’t exactly
match.

On Mon, Jan 21, 2019 at 10:27 AM Oddbjørn Bakke [e-mail]
wrote:

I think it's strange that we can explicit ask for mapping of interfaces,
and AutoMapper just ignores this. Map(sourceModel,
destination) or Map(sourceModel, destination, typeof(sourceInterface),
typeof(destination)).

@dimi3tron https://github.com/dimi3tron now you will be limited by the
order in the ValueTuple. But by using generics, you could just wrap it in a
single type anyway? I would think something like this is simpler then:

//Linqpad scriptvoid Main()
{
//https://github.com/AutoMapper/AutoMapper/issues/1295
var config = new MapperConfiguration(cfg =>
{
cfg.CreateMap, Entity>()
.ForMember(
dest => dest.id,
src => src.MapFrom(x => x.Item1.id)
)
.ForMember(
dest => dest.type,
src => src.MapFrom(x => x.Item2.GetEntityType())
);

    cfg.CreateMap<InterfaceMap<IHasId>, Entity>()
        .ForMember(dest => dest.id, src => src.MapFrom(x => x.Value.id));

    cfg.CreateMap<InterfaceMap<IHasEntityType>, Entity>()
        .ForMember(dest => dest.type, src => src.MapFrom(x => x.Value.GetEntityType()));
});

var mapper = config.CreateMapper();

var model = new TestModel
{
    id = 321,
    name1 = 1,
    name2 = 2
};

//id: 321, type: 123, name1: 0, name2: 0
mapper.Map<Entity>(
    (model as IHasId, model as IHasEntityType)
).Dump("map ValueTuple");

// mapper.Map(// (model as IHasEntityType, model as IHasId)// ).Dump("does not compute");

//id: 321, type: 0, name1: 0, name2: 0
var result_IHasId = mapper.MapInterface<IHasId, Entity>(model).Dump("map IHasId");

//id: 0, type: 123, name1: 0, name2: 0
mapper.MapInterface<IHasEntityType, Entity>(model).Dump("map IHasEntityType");

//id: 321, type: 123, name1: 0, name2: 0
mapper.MapInterface<IHasEntityType, Entity>(model, result_IHasId).Dump("map over");

//Test that we don't have any new proxies:
var proxyAssembly = AutoMapper.Execution.ProxyGenerator.GetProxyType(typeof(IDummy)).Assembly;
proxyAssembly.GetTypes().Dump();

}
public static class MapperExtensions
{
public static TDestination MapInterface(this IMapper mapper, TSourceInterface source)
{
return mapper.Map(new InterfaceMap(source));
}

public static TDestination MapInterface<TSourceInterface, TDestination>(this IMapper mapper, TSourceInterface source, TDestination destination)
{
    return mapper.Map<InterfaceMap<TSourceInterface>, TDestination>(new InterfaceMap<TSourceInterface>(source), destination);
}

}
public class InterfaceMap
{
public T Value;

public InterfaceMap(T value)
{
    Value = value;
}

}
public interface IDummy { }
public interface IHasId
{
int id { get; set; }
}
public interface IHasEntityType
{
int GetEntityType();
}
public class Entity
{
public int id { get; set; }
public int type { get; set; }
public int name1 { get; set; }
public int name2 { get; set; }
}
public class TestModel : IHasId, IHasEntityType
{
public int id { get; set; }
public int name1 { get; set; }
public int name2 { get; set; }

public int GetEntityType()
{
    return 123;
}

}

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/AutoMapper/AutoMapper/issues/1295#issuecomment-456130357,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGYMpnPPRTqpLunaFIbhSf_6aDIxMfFks5vFepdgaJpZM4IjySZ
.

[oddbear]

@jbogard Hope I didn't sound rude there or anything like that.
I do understand that in most cases, you will want to map the type of source.GetType(), and not the Parent type or an interface to the destination.

However. I would like to have seen some overload, MapExplicit, or similar.
Do you think there is any technical reason that could make this not be possible?

Something like suggestion 3, 4 or 5 _(see code bellow)_ would probably be preferred _(a Wrapper class like the example over is probably cleaner than suggestion 1, and preferred behaviour might change at different places in the code)_.

I guess with the example in my previous post, it should be possible to extend AutoMapper _(with a seperate NuGet and no code changes even)_ using suggestion 5. That could also work with both the Static and Instance API.

//Linqpad script
void Main()
{
    var config = new MapperConfiguration(cfg =>
    {
        cfg.CreateMap<Child, Entity>();
        cfg.CreateMap<IHaveName, Entity>().ForAllOtherMembers(x => x.Ignore());
        //cfg.CreateMap<IHaveName, Entity>(MemberList.Explicit); //Suggestion 1: Explicit override, if the type is of this type.
    });

    config.AssertConfigurationIsValid();

    var mapper = config.CreateMapper();


    var model = new Child
    {
        Id = 1,
        Name = 2
    };

    DoWork(mapper, model);
    DoWorkInterface(mapper, model);

    //Suggestion 2:
    //Some type of override:
//    mapper.Map<IHaveName, Entity>(model, mapping => {
//        mapping.ExplicitMapping() //Expected to map IHaveName, not Child to Entity
//    })

    //Suggestion 3:
//    mapper.Map<IHaveName, Entity>(model, explicit: true) //Expected to map IHaveName, not Child to Entity

    //Suggestion 4:
    //mapper.MapExplicit<IHaveName, Entity>(model); //Expected to map IHaveName, not Child to Entity

    //Suggestion 5:
//    IExplicitMapper, ExplicitMapper or similar?
//    explicitMapper.Map<IHaveName, Entity>(model);
}

void DoWork(IMapper mapper, Parent model)
{
    //Type is Child:
    model.GetType().Dump();

    //Mapping profiles does exist as Child.
    //Model is Child, not Parent. Child to Entity mapping is expected:
    mapper.Map<Parent, Entity>(model).Dump();
    mapper.Map(model, typeof(Parent), typeof(Entity)).Dump();
}

void DoWorkInterface(IMapper mapper, IHaveName model)
{
    //Type is Child:
    model.GetType().Dump();

    //Mapping profiles does exist as Child.
    //Model is Child, not IHaveName. Child to Entity mapping is expected:
    mapper.Map<IHaveName, Entity>(model).Dump();
    mapper.Map(model, typeof(IHaveName), typeof(Entity)).Dump();
}

public class Entity
{
    public int Id { get; set; }
    public int Name { get; set; }
}

public class Parent
{
    public int Id { get; set; }
}

public class Child : Parent, IHaveName
{
    public int Name { get; set; }
}

public interface IHaveName
{
    int Name { get; set; }
}

[jbogard]

I don't really want to add more overloads, but what about something on the mapping options passed in? Or is this something you'd want configuration-wide? Would you want this behavior per-map, or global?

[dimi3tron]

A lot of stuff went on here while I was sleeping :-)

@oddbear you're right about the order of interfaces, as I said, it was just a quick thought. I like your approach as it eliminates the dependency on ValueTuple.

I have some thoughts on this issue, or at least some ways I'd like to see it implemented. I think I might be able to conceive most of it through some extension methods, but I'd really have to bunker down and hammer out the code to be sure. Without changing the core it might have some uglyish parts.

I was thinking of having something like a MapAs method taking one or more type parameters to use explicitly. Having a separate method should enhance readability.
@jbogard, what do you mean with a global config? That doesn't sound very useful, as in some case one might still want to use the default behaviour.

Anyways, more on this when I got down with some code. I don't think I'll have much time for it today, but maybe I could put together a little POC by tomorrow or thursday.

[oddbear]

@dimi3tron I think you are right that a behavior per map would be better.

MapAs would be a great approach and a nice place to take a decision like this.
This would be something like suggestion 4 (just with better naming) from code above. However with only the Instance API supported _(the Static API could be added as a different Static class also)_.

Would have liked to see something like this native, as extension methods would be a lot of work to look perfect with configuration.
Wrapping the type as InterfaceMap<T> in an extension MapAs, and CreateMapAs should be feasible. The higher amount of work would be to rewrite the src.MapFrom(x => x.Value.GetEntityType()) to have the format src.MapFrom(x => x.GetEntityType()) as an extension.
Looking forward to see the PoC.

I guess _mapping options passed in_ would be something like suggestion 2 _(using IMappingOperationOptions)_?

[dimi3tron]

Just a heads up that I'm still on this thing, just havn't found any time to actually write the code

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.