-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Let's make the type mapper more pluggable. #385
Comments
I created a utility to map POCO properties to database column names using a fluent API. It uses the To accomplish this I have to add each type map using |
Agree with this. I wanted to mark all |
@NickCraver I have seen a lot of discussion surrounding the idea of bringing in the Ideally I can just change the name of the property to |
@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: which then allows for things like: |
BINARY(16) to Guid mapping would be helpful for mysql/mariadb (unless I'm missing some other way of doing this currently) |
@phillijw A similar mapping for Oracle (RAW(16) to Guid) was tried in #637, but in the end it was backed out:
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.) |
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'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:
[Column]
attribute (I'm thinking[DataMember]
)Query<T>
mapperId
columns that could possibly be worked aroundTimeSpan
mapsThis one is a more questionable example (as in questionable if this would help):
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:
and #350 by:
Posting this here for thoughts.
The text was updated successfully, but these errors were encountered: