DapperLib
Custom CreateCommand method. Resolves #2127
This allows the user to provide their own IDbCommand to be used by Dapper internally.
@mgravell Can you give any status updates regarding acceptance/support for this?
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?
@mgravell He was trying to hook into the retry logic the sqlCommand ef core has baked in.
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
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.
