Dapper.Contrib does not respect SqlMapper.TypeMaps

[SwissMaWi]

The Dapper.Contrib does not use the ITypeMap instances set for mapping database table column names to POCO property names. Generated SQL statements therefore are wrong when using a POCO with property names not identical to database columns.

[SwissMaWi]

Proposal: Modify Dapper.Contrib.SqlMapperExtensions to respect any ITypeMap which have been set by using the SetTypeMap method. I understand that the ITypeMap provides only mapping from column names to POCO properties, not vice versa. In order to use these mappings in Dapper.Contrib, the reverse mapping would have to be made available in ITypeMap.

[SwissMaWi]

I am trying to implement the reverse mapping and make Dapper.Contrib use it to create correct SQL statements when an ITypeMap is present for a type. Do you have any hints for me @NickCraver I am fairly new to this. Would you be willing to review? Regards, Martin

[NickCraver]

Can you illustrate what you're trying to do with source/destination types with an example? I'm trying to determine how much this overlaps with DapperLib/Dapper#722.

[Brondahl]

What happened with this. This is causing my project some pretty painful problems?

It looks like DapperLib/Dapper#722 is about a change in DapperV2, which I doubt we'd be moving to, even if it were released tomorrow (stodgy corporate environment :( ).

Is there scope for fixing this issue in Dapper.Contrib directly?

(We could probably live with pulling in the DapperContrib source code and monkey patching it ourselves, if that's the only option - is this a reasonably accessible change to make, or does it require large restructuring?)

[Brondahl]

@SwissMaWi Did you ever resolve this? Did you identify the correct fix to apply?

[Brondahl]

@NickCraver Is my understanding correct - that DapperLib/Dapper#722 is going to be a new major version of Dapper?

[Jetski5822]

Darn - just hit this too.. :(

[eliavra]

is there plans to fix this issue? if not, is there a workaround to using the mapper ?

[rclarke2050]

could we have a beta version (pre-release) at least to go with, so we can at least move forward a little with our projects. The MyFieldName {get;set;} -->

.myfieldname is causing a big headache for me now, because even though for SqlConnection the class names are fine, for postgres its not. The TypeMap idea is good Nick, but i can see other people have posted their solutions, https://github.com/StackExchange/Dapper/pull/1396, all we need is beta around this issue for the time being until DapperV2 comes out. is that do'able?

[rclarke2050]

I found a way around this field name problem for the time being.

in my Repository Constructor i used:

DapperExtensions.DapperExtensions.SqlDialect = new DapperExtensions.Sql.PostgreSqlDialect();

and in the Insert Method: db.Insert(item); and in the Updaet Method: db.Update(item);

i did not use the SqlMapper approach, nor did I use the SqlMapperExtensions.Insert()

Ive tried on .Net Core 2.1 Lambda, and AWS Aurora 10.7.

Dapper v2.0.30 Dapper.Contrib 2.0.30 DapperExtensions.DotnetCore 1.0.1

I hope this helps others for now....in the interim.

[vincentparrett]

I've come to the conclusion that Dapper.Contrib is not currently usable for postgresql - not using the typemap is a major deal since column names are case sensitive.

[rclarke2050]

I've come to the conclusion that Dapper.Contrib is not currently usable for postgresql - not using the typemap is a major deal since column names are case sensitive.

This is not true, I have managed to get around the issue, aslong as the column name appending on the PostgresAdapter is sorted (which i believe is now), then you wont have the problem with direct class property to db column mapping out of the box.

My aws Aurora Postgres db is defaulted to case sensitive, and its working flawlessly.

my 50c

[sl-bassamtayba]

Hello, still same problem, daper with Postgresql. When calling Insert() of Dapper.Contrib the generated sql script has nothing to do with the mapping I configured

[SwissMaWi]

Sorry for not writing for a long time. I am now using Dapper and Dapper.Contrib extensively in a few projects. Since I am also using solely immutable dtos I am using only dto constructors for deserialization and no property setters. This avoids the problem reported by me in the first place and leads to a cleaner usage in my opinion.

[sl-bassamtayba]

in my case, I went back to using QuerySingle<T> in case of Insert and update