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