You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a couple of ideas for a potential v3 release of tiny_tds. However, I did not work that much on code so far and also not sure if this is the direction that the project wants to take, so consider this issue a proposal.
Potential content of the release:
Drop support for older Ruby versions
I personally would drop everything until Ruby 3.1 (v3 wouldn't be released before end of March anyhow, and Ruby 3.0 is EOL after March 2024)
Otherwise, Rails 6.1 is still supported, which requires Ruby 2.5 at least, so dropping support for all versions below 2.5 could also be an option.
Drop the 32-bit Windows build.
It is currently untested on CI, which is a potential risk.
v2.1.6 had 150 downloads for it (1200 for the 64-bit version), v2.1.7 95 so far (415 for the 64-bit version), so I would say demand for it is quite low.
Bump the dependencies for the precompiled Windows version.
If possible, we could move to OpenSSL v3 when updating FreeTDS.
Drop support for older MSSQL versions
Microsoft has two support models: Mainstream and Extended.
I think we should drop support for versions where extended support has been discontinued.
Instead of returning false when something went wrong with the query, throw an exception.
Throwing an error is much more clear than false and v3 is the best time to do so.
Again, these are just a couple of ideas. I also read through #511 which suggest a new implementation based on the .NET client, but I personally would not like installing a .NET runtime for my Ruby project.
Sounds good, especially changing the return false thing... absurd. I'd also like to consider refactoring how escape is called, so that a live connection object isn't required (maybe a class method, or maybe decoupling init & connect).
I have a couple of ideas for a potential v3 release of
tiny_tds
. However, I did not work that much on code so far and also not sure if this is the direction that the project wants to take, so consider this issue a proposal.Potential content of the release:
false
when something went wrong with the query, throw an exception.false
and v3 is the best time to do so.Again, these are just a couple of ideas. I also read through #511 which suggest a new implementation based on the .NET client, but I personally would not like installing a .NET runtime for my Ruby project.
What do you think @aharpervc?
The text was updated successfully, but these errors were encountered: