Dapper: Why only QueryAsync method have mulit mapping method overload with CommandDefinition

Created on 18 Apr 2017  路  4Comments  路  Source: StackExchange/Dapper

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 ?

image

dapper version = 1.50.2

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Dapper" version="1.50.2" targetFramework="net461" />
</packages>
api

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 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.

All 4 comments

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.

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.

Was this page helpful?
0 / 5 - 0 ratings