-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dapper throws an error when operating on IDbCommand that is not DbCommand #757
Comments
Yep - but we have to do this, as Can you elaborate on why you're calling async methods on something that doesn't implement async? |
I just want to log all the SQL that gets sent to the database. A wrapper around May I ask a question in return: Why is Dapper defined against the IDbConnection interface if it actually requires DbConnection to operate? That seems to go against all kinds of best practices. |
This is only true in If you want to log all SQL that gets sent, I'd wrap your actual connection to log things as they pass. If you want an example of this, look at MiniProfiler where we do exactly that: here's where to start. |
I hoped for a more elegant solution... Oh well, I'll work around it. But I do think that the way the async methods work is a big no-no. It breaks all kinds of encapsulation. I only caught this breakage when moving to Dapper with async during integration tests, whereas the wrapper used to work just fine before. |
@VictorGavrish let me approach it from this way: how else would you do it? Is the argument that we should move the extension methods to If so, @mgravell - thoughts? |
@NickCraver You mentioned that that had some problems, but I can't think of any really big ones. Maybe I'm missing something? |
Actually, there is another way to solve the breakage, at least. You can still define the methods against |
Actually, the very least thing you can do is detect whether the |
Any updates on how to solve this? |
"don't do it"? I mean, we can improve the error message, but I'm loathe to implement async-over-sync - it is basically a lie to the caller. If we can't support it properly, I'd rather the caller knows that and simply: uses the sync API if their chosen provider or wrapper type only exposes that. |
Just ran into the If there's a legitimate reason to accept |
Perhaps in v2 we move these to DbConnection itself ratherr than IDbConnection for the extensions to eliminate the case, but that's breaking...for now we can at least throw a better error. See #757 for details.
I agree the error message should be better here until we can even possibly move the methods in a breaking change. Can people here please take a look at #986 and see if the error there is clear or suggest what would be clearer? |
I think that message is fine if the intent is to discourage use of anything but Also, for Edit: I think I see why you were checking for DbConnection in the command setup method too, because the connection is what creates the command. I guess there could be a scenario where someone implemented an IDbConnection that produces DbCommands... would be weird but how about something like: #987 |
They had a similar issue here: madelson/DistributedLock#3. It's a good discussion because it points out that MS can't add new methods to the interface for backwards compat, so the library author was using DbConnection and DbCommand as Dapper currently does. But the issue was raised to achieve testability with the interfaces. So we're stuck between a rock and a hard place it would seem. I tend to think that the error message may be enough but you guys are the experts 😄 They ended up going with the interfaces and wrapping the synchronous calls in async wrappers, which is what @mgravell was loathing haha. |
@benmccallum I didn't see your PR before sitting down and adjusting based on email - please see #986 for updated error messages and a bit more allowance on the DbCommand side. |
Haha, no worries. Would've been sweet to be on the contributors list for such a great library but all good! You've nailed it! |
@benmccallum You're the one calling out these things! Just yanked what I could from your PR into the fold - welcome, contributor :) |
Haha legend! PS. You're both legends. Read both of your blogs. The stuff on StackOverflow's architecture is always super interesting. Thanks for sharing with the community. cc: @mgravell |
…#986) * Better error messages for .*Async methods when not using DbConnection Perhaps in v2 we move these to DbConnection itself ratherr than IDbConnection for the extensions to eliminate the case, but that's breaking...for now we can at least throw a better error. See #757 for details. * Tweak errors to allow open IDbConnections and those generating DbCommands Same checks but a bit more lenient with more specific messaging. * Tweaking error messages and supporting IDbConnection implementations … (#987)
But isn't already a lie to the caller? I mean, we don't call |
@jstafford5380 the reality is that nothing is async if you're using the interface; frankly, it was a mistake to make those methods take the interface, so yes: that part is a lie. My vote is: next time we do a break (probably when adding |
Most of Dapper uses Looks like this issue can be closed? |
The reality is that as more and more emphasis goes on I think ultimately that any change here is going to further solidify that |
I have a wrapper implementation of
IDbCommand
for logging purposes. When I use it, Dapper throws an error during mapping. I believe this piece of code is at fault:https://github.com/StackExchange/Dapper/blob/61e965eed900355e0dbd27771d6469248d798293/Dapper/SqlMapper.Async.cs#L480
Here my wrapper (which implements
IDbCommand
rather than inheriting fromDbCommand
) gets cast directly toDbCommand
, producing anInvalidCastException
:The text was updated successfully, but these errors were encountered: