Let's make the type mapper more pluggable.

[NickCraver]

I'm seeing a big picture of a lot of issues solved in a single way here. People want to slightly adjust how the type mapping works in various ways - and I think we can do a better job of allowing this.

Here are some examples:

• Added Column attribute - to alias column names #376 Changing the mapping using a [Column] attribute (I'm thinking [DataMember])
• create overload Query<T> to customize the mapper #360 Customizing the Query<T> mapper
• Automatic multi mapping : would this be possible ? #350 More automated multi-mapping
• Dapper isn't mapping correctly #326 An Azure-side issue with Id columns that could possibly be worked around
• Mapping of TimeSpan to DbType.Time is too restrictive #319 Changing how TimeSpan maps
• option to throw when result set has unmapped columns #254 Option to throw with unmapped columns (use cases for both directions)
• advice about Colmap #251 Colmaps for Oracle
• Please add support for Nodatime #198 Supporting Nodatime

This one is a more questionable example (as in questionable if this would help):

• Querying abstract types #262 Query abstract types

There may be a few I missed, but you get the idea. You can replace the DefaultTypeMap since #110 was merged a few weeks ago. However, we can do better here by allowing DefaultTypeMap to be plugged a bit rather than clipboard inherited all over. We'd also need to look at what functionality could move down into it to be pluggable (such as column names).

I'm not arguing for this to all be in core - I honestly think it'd be a bad idea if all of it was. I think making it pluggable makes some of the odder cases, if common, appear as mappers you could easily plug in from contrib. For example, what if #376 could be fixed by:

SqlMapper.TypeMapProvider = t => Dapper.Contrib.DataMemberMapper;

and #350 by:

SqlMapper.TypeMapProvider = t => MyCustomMultiMapper;

Posting this here for thoughts.

[henkmollema]

I created a utility to map POCO properties to database column names using a fluent API. It uses the CustomPropertyTypeMap: https://github.com/henkmollema/Dapper-FluentMap (and specifically FluentTypeMap).

To accomplish this I have to add each type map using SqlMapper.SetTypeMap(), which is a bit clumsy. Perhaps creating and configuring custom type maps could more 'pluggable' as you call it.

[megakid]

Agree with this. I wanted to mark all DateTime coming via Dapper as DateTimeKind.Utc as the MySql.Data ADO Connector marks them as DateTimeKind.Unspecified. This proved virtually impossible and had to do it as a post step by reflecting over all properties and marking DateTime properties as UTC.

[mperrenoud]

@NickCraver I have seen a lot of discussion surrounding the idea of bringing in the Column attribute. Did this happen by chance? Right now I have a table I'm trying to work with named BillingLocation, but the creator of the table added a column named BillingLocation as well.

Ideally I can just change the name of the property to Name and then use the Column attribute to set its field behind being BillingLocation.

[mitchcapper]

@mperrenoud no this is not yet in code this issue is tracking a more dynamic way to do column name mapping. I did find this feature useful however so you can find the latest dapper with the [Column] support that was created by @mjashanks here: https://github.com/mitchcapper/dapper-dot-net/tree/column_attribute_support .

In addition, when this does finally get implemented I would recommend adding some helper methods for making non-standard crud operations easier. I wrote this code on top of @mjashanks updated code:
mitchcapper@477e58a?w=1

which then allows for things like:
db.ExecuteScalarAsync<string>("SELECT COUNT(*) FROM " + db.GetTableName<MyTable>() + " WHERE test=1");
or:
await db.QueryFirstOrDefaultAsync<Message>(db.GetSelectSql<MyTable>() + " WHERE test=1 ORDER BY sortable LIMIT 1");

[phillijw]

BINARY(16) to Guid mapping would be helpful for mysql/mariadb (unless I'm missing some other way of doing this currently)

[cdonnellytx]

@phillijw A similar mapping for Oracle (RAW(16) to Guid) was tried in #637, but in the end it was backed out:

Reverted; sorry, closing this down since we can't support it natively in the lib due to the incompatibility between backends

Unfortunately I didn't find any further details on why this was backed out. (I speculate it would break compatibility with drivers that support Guids natively, like SQL Server, but I don't fully understand the reasons.)

[christophano]

I would love to see support for #350, but I'm not sure it's possible via the type map, without a lot of changes.
I know your previous objections to including this in the base library are related to the "magical" nature of automatic conventions, particularly where they could affect previously working queries, but is it something you would consider if it was disabled by default and, of course, didn't have a significant impact on performance?