search

brucezhang80 / dapper-dot-net

Automatically exported from code.google.com/p/dapper-dot-net
Other
0 stars 0 forks source link

Typemap Extensibility #24

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Create a db table with a DATETIMEOFFSET NULL column.
2. Create a POCO with a DateTime?
3. Trying to select will throw InvalidCastException.

I'm using RIA services to serialize over the wire, and they don't support 
DateTimeOffset, so I'm forced to use DatTime. 

If I could plug in and provide a Cast helper function or something, 
Func<TSource,TResult>.

Original issue reported on code.google.com by pettij...@gmail.com on 17 May 2011 at 8:49

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
I'd like to be able to have a custom attribute that can be applied to the 
target object that lets you define custom converters and also override the 
mapping of column names.

[DataColumn(Converter = typeof(DateTimeOffsetConverter), Name = 
"NarlySqlColumnName")]
DateTime LastUpdated { get; set; }

Overriding the mapping of column names for me is useful when there is a column 
name that is the same as the name of the class, which isn't allowed in .NET.

Original comment by james.ne...@gmail.com on 27 May 2011 at 3:26

GoogleCodeExporter commented 9 years ago 
One problem I see with attributes is that you always have to check for them, 
each time you reflect over a new type, even if they most of the time aren’t 
present.

AutoMapper has an opt-in model for custom “mappings/serializations” which I 
think is elegant.
Basically you register the members that should have special handling, 
simplified sample below:

.ForMember<short?, CustomerType>(
  Destination => Destination.CustomerType,
  Option => Option.MapFrom(
                Source => Source.CustomerType.HasValue
                         ? (CustomerType)(Source.CustomerType)
                         : CustomerType.Choose)
                )
)

In dappers case I could be easier as the source type could always be DataReader 
and all responsibility could be given to the API user on how a specific 
property value is assign / deserialized.

Original comment by mattias%...@gtempaccount.com on 1 Jun 2011 at 12:21

GoogleCodeExporter commented 9 years ago 
another issue with attributes is that they are "sticky" you may want one 
convertor for mysql vs another for sqlite.

Original comment by sam.saff...@gmail.com on 20 Sep 2011 at 1:12

GoogleCodeExporter commented 9 years ago 
When using BLOBs with more than 8000 bytes of data, you need to specifically 
set Parameter.SqlDbType = SqlDbType.Image to make it work (as explained 
here:http://connect.microsoft.com/SQLServer/feedback/details/311412/sqlceparamet
er-limits-dbtype-binary-to-8000-characters-ssce3-5).

Dapper, when it sees a byte[] field, defaults to a SqlDbType.Binary, which 
means for larger blobs, the inserts and updates will fail with a data 
truncation error.

A method to override byte[] => SqlDbType.Binary mapping would really be useful 
in this scenario.

Original comment by www.same...@gmail.com on 12 Mar 2012 at 3:43

GoogleCodeExporter commented 9 years ago 
I like the idea of fluent mapping at query-time (like mattias...'s example). 
The entire need to map is rooted in the way data is stored in the DB, which to 
me says it belongs at the DB layer and not as part of the POCO definition.

Original comment by gro...@gmail.com on 2 Apr 2012 at 6:25

GoogleCodeExporter commented 9 years ago 
Does the new ITypeMap functionality satisfy this?
http://stackoverflow.com/a/12615036/444917

Original comment by superson...@gmail.com on 17 Dec 2012 at 11:45

GoogleCodeExporter commented 9 years ago 
I believe this conversation may be related to 
https://code.google.com/p/dapper-dot-net/issues/detail?id=140

Original comment by richard....@gmail.com on 21 Aug 2013 at 1:42