-
Notifications
You must be signed in to change notification settings - Fork 188
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
Raise error if client is unable to execute statement #469
Conversation
@aharpervc I'm not sure how to write a proper test case for this. I can see there is a test |
TinyTDS returns false instead of raising an exception if connection fails while executing a query. Getting around this by raising an exception ourselves while this PR rails-sqlserver/tiny_tds#469 is not released. The solution came from #717 and #818, I am just adjusting the error message to make it the same as that TinyTDS PR.
TinyTDS returns false instead of raising an exception if connection fails while executing a query. Getting around this by raising an exception ourselves while this PR rails-sqlserver/tiny_tds#469 is not released. The solution came from #717 and #818, I am just adjusting the error message to make it the same as that TinyTDS PR.
Yeah good question how can we force this behavior? What about something like this:
|
Even if this can't be cleanly tested, it's clearly better to raise an exception instead of returning false. If you look at the README, it's clear that execute is never expected to return false, as none of the code that calls execute checks for false. And apparently, none of the specs check for it returning false either. |
Just came across this from the rails sql server adapter source. Is there a blocker to merging this? cc @metaskills |
There's no real hard blockers, however it would be great if we added a test for this. You can also contribute that test @bf4 if this is a priority for you. Or I will add a test at some point later this autumn when I have more time to look at it. Basically anyone can, or we can decide that no test is needed and merge regardless. One question I currently have is the |
Should be easy for me to test given my local docker server keeps dying mid
request
…On Wed, Sep 2, 2020, 12:43 PM Andrew Harper ***@***.***> wrote:
Just came across this from the rails sql server adapter source. Is there a
blocker to merging this? cc @metaskills <https://github.com/metaskills>
There's no real hard blockers, however it would be great if we added a
test for this. You can also contribute that test @bf4
<https://github.com/bf4> if this is a priority for you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#469 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABC4QVTVUVOXCFQMM2S5D3SDZ74FANCNFSM4NBQ356Q>
.
|
@wpolicarpo @bvogelzang was able to force various timeouts in #481, so maybe something can be done here that way? Alternately if there isn't enough energy to add a test, I would be okay merging regardless. I think the value is high enough on this one to do it anyway. |
@aharpervc I'm struggling to find time to look into this and some other adapter issues these days, but I can look into adding some tests, yes. I was already following that PR to get some ideas and implement them the same way here. If you are planning on cutting a release anytime soon, we could merge this the way it is and I can open a new PR adding tests after if you're OK with that. |
@aharpervc I finally had time to look into this today. I think I will wait until #481 is merged and use the same approach to write some tests for this change. I could rebase my branch on top of that, but I would still need it to get merged first anyway. Do you have a rough idea of when that PR will be merged? |
I expect we can merge it when the CI tests pass. I don't recall off the top of my head what the blocker there was |
@bvogelzang got the tests to pass, so we're moving forward. I included this PR in the 2.1.4-pre2 for validation: #486. I still think it'd be ideal to include a test in this PR if possible. Either way, can you add a bit to the "unreleased" section of the changelog @wpolicarpo? |
Thanks @aharpervc and @bvogelzang. I'll look into adding a test using toxiproxy this week. |
@wpolicarpo I saw you added a testing commit here 1c2f56e, what do you think about adding it to this branch? Did Toxiproxy have the intended effect? |
bb03ed7
to
5b96c72
Compare
@wpolicarpo I moved your commit that added a test from #486 to here and rebased on latest master (I realize this may be slightly disruptive since I force pushed, but it can be fixed if it's a problem) |
@wpolicarpo I think changing the test so it uses the client = new_connection timeout: 2, port: 1234
assert_client_works(client)
action = lambda { client.execute("select 1").do }
# Use toxiproxy to close the TCP socket.
# We want TinyTds to fail to send the statement and raise an error immediately.
Toxiproxy[:sqlserver_test].toxic(:timeout, timeout: 0).apply do
assert_raise_tinytds_error(action) do |e|
assert_match %r{failed to execute statement}i, e.message, 'ignore if non-english test run'
end
end |
This PR would fix a bug in my web app, which would be very important for me. Thanks! |
hey @bvogelzang best regards |
I'm closing this PR because I'm unable to find time to look into it better and get it to a state that we can merge. If someone is able/wants to make it happen, please feel free to use the idea/code in here and open a new PR. |
@wpolicarpo If you have time, can you clarify what about the PR made it unable to merge? I'm not sure about the test, but the |
@jeremyevans as far as I can remember, there were a few tests failing (maybe not directly related to these changes but due to CI changes happening at the same time I opened it). I just can't find time to look into it and I don't want to hold anyone back if they wanted to make it happen and decided no to because there was already a PR for that. |
TinyTDS
returnsfalse
when you try to execute a query and for some reason it fails (dead connection, a network intermittent error, etc). This PR changes this behavior to raise an exception instead.This is particular useful for ORMs built on top of TinyTDS connection like Sequel or ActiveRecord. Note that this also breaks the public API and this might be undesired.
Fixes #451.