Custom CreateCommand method. Resolves #2127

[billrob]

This allows the user to provide their own IDbCommand to be used by Dapper internally.

[billrob]

@mgravell Can I get some movement on this one?

[RyanThomas73]

@mgravell Can you give any status updates regarding acceptance/support for this?

[mgravell]

Honestly, I'm just not sure it is a good fit, and it makes a lot of other things potentially much harder. If you're creating your own command: you probably don't need Dapper in the first place - or rather: it isn't going to do a lot for you. If what you want is to run the query API: the row materializer is already available via SqlMapper.GetTypeDeserializer. In particular, I'm concerned that baking this into the definition removes flexibility.

What is the actual core need here, that makes you want to pass in a command rather than either just use Dapper or just run your own command?

[billrob]

@mgravell He was trying to hook into the retry logic the sqlCommand ef core has baked in.

[billrob]

I actually agreed with him as I could see other use cases where you might want to have more control over the SqlCommand object. eg, working with Transactions or one time I sent the @loggedInUserId to each query so I could record all queries and who made them.

The risk looked low as the library sets the CommandType and CommandText. So if someone set their own and it was overridden that is acceptable behavior. IMO

[IlSocio]

hello everyone,
I'm already using dapper in one of my projects to insert some messages in a table.
Now, I "just" needed to set the SqlCommand.RetryLogicProvider
to leverage the out-of-the-box retry from Microsoft, but didn't find any way do it because dapper totally encapsulates the underling connection.
This PR would allow me to set the RetryLogicProvider on the connection

what's the alternative suggested solution in this scenario?
thanks, Marco.

[toreamun]

I would love to see this feature in Dapper! It enables use of the official Configurable retry logic in SqlClient for command execution.

Applications communicating with cloud services need to handle transient faults, and the current version of Dapper doesn't allow using Microsoft.Data.SqlClient's built-in retry logic for commands. This PR solves that:

// Single provider instance can be reused for multiple commands and connections
// Built-in providers retry transient faults if not in a transaction
SqlRetryLogicBaseProvider retryProvider = SqlConfigurableRetryFactory.CreateExponentialRetryProvider(new SqlRetryLogicOption());

// Can also be configured on connection level to retry operations like Open
connection.RetryLogicProvider = retryProvider;

IDbCommand CreateRetryCommand(IDbConnection connection)
{
    var command = ((SqlConnection)connection).CreateCommand();
    command.RetryLogicProvider = retryProvider;
    return command;
}

connection.Query<int>(new CommandDefinition("SELECT num FROM Numbers", CreateRetryCommand));