Make auto reconnect duration configurable

[dchelimsky]

Reconnect is set up to try every 2 seconds 5 times. This is fine for network blips, etc, but not for a system failover that can take far longer.

Please add a configuration option that allows us to tell the adapter to keep trying for any arbitrary length of time.

[metaskills]

I could not remember if I added one or not. I did a quick look at the code and saw there is a config we have for auto_connect. You should be able to set this up in a config/initializer if you want like the other configs we offer up?

[metaskills]

Ah, your talking about the duration. Sure, we can do that, care to offer up a patch?

[dchelimsky]

I tried to patch it before I submitted the request, but after 30 minutes of fail trying to get the dev environment set up I gave up.

[metaskills]

Is there something that we can do to make that easier?

[dchelimsky]

BTW - one of my projects (rspec-rails) has the same problem - complex dev env due to need to support multiple environments creates barrier to contribution. I've thought of having a "light" version of the dev env that only depends on the most recent versions of everything to make it easier to submit patches, afterwhich I could run specs against the full set of environments and either address failures myself or push them back to the contributor. WDYT? (I'm asking in principle here - not whether you or I should do this)

[metaskills]

You could also post some pseudo code and/or diffs so I can get an idea of what number you want to configure, how, etc.

[dchelimsky]

Happy to do that! Will do shortly.

[metaskills]

I have thought of a few ideas of making the testing a bit easier.

1. Moving active record to the Gemfile and changing the test load paths to leverage the installed gem vs a rails checkout.

2. Switching the ACTIVERECORD_UNITTEST_SKIP environment variable to default to true in our Rake file https://github.com/rails-sqlserver/activerecord-sqlserver-adapter/blob/master/Rakefile#L13 so that it would only run our tests first by default.

[dchelimsky]

dchelimsky@26d2406

[metaskills]

OK, got that in. BTW, I changed the testing setup a bit and it should be easier. The instructions should be a bit easier and verbose when needed. Feedback welcome.

FYI, there seems to be a bug in FreeTDS's DBLIB for 0.82 api where errors in stored procedures like sp_exectuesql will not fail gracefully. This means, that if you use TinyTDS with the master branch (to released 3.1 version) then you must FreeTDS 0.91. If you don't want to install that on your system, you can easily locally compile a version of TinyTDS that statically includes FreeTDS 0.91RC2. See the project README for details.