Open huobazi opened 7 years ago
Well, at least the very first one (Query<T>
) has it :) - it is only the multi-type version that isn't provided.
For the rest: partly because we're human and fallable, partly because the number of overloads is getting depressing. One particular reason is because CommandDefinition
has the Pipelined
property that is only useful for *Async
and is always useful for *Async
when available.
I wonder if we can radically refactor the API in vMajorNext for the multi-type version using tuples, which would remove the need for all the generics. So instead of:
var rows = conn.Query<Foo, Bar, Foo>(..., (x,y) => x.Bar = y);
we could do:
var rows = conn.Query<(Foo x, Bar y)>(..., row => row.x.Bar= row.y);
the key point here is that we don't need 27 overloads for this - heck, we could make Action<T> rowCallback = null
optional and we don't need a single extra overload.
@NickCraver design thoughts? ^^^ I like it.
For tracking ^ this is awesome...we're working through scenarios now to see what we can do. Fun stuff is coming to a C# 7 solution near you.
cross-reference: https://github.com/StackExchange/Dapper/issues/745
One particular reason is because CommandDefinition has the Pipelined property that is only useful for Async and is always useful for Async when available.
@mgravell Would you mind explaining this a little bit more (or taking me to another post)? I would like to know how pipeline works.
The QueryAsync method have mulit mapping method overload with CommandDefinition
But the Query method has no CommandDefinition method overload. what is the purpose for this design ?
dapper version = 1.50.2