Skip to content
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

tiny_tds v3 #552

Open
andyundso opened this issue Feb 18, 2024 · 1 comment
Open

tiny_tds v3 #552

andyundso opened this issue Feb 18, 2024 · 1 comment

Comments

@andyundso
Copy link
Contributor

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.

What do you think @aharpervc?

@aharpervc
Copy link
Contributor

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants