The QueryAsync method have mulit mapping method overload with CommandDefinition
public static Task<IEnumerable<TReturn>> QueryAsync<TFirst,..., TReturn>(this IDbConnection cnn, CommandDefinition command, Func<TFirst,...TReturn> map, string splitOn = "Id");
But the Query method has no CommandDefinition method overload. what is the purpose for this design ?
dapper version = 1.50.2
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Dapper" version="1.50.2" targetFramework="net461" />
</packages>
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.
Most helpful comment
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 thePipelined
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:
we could do:
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.