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

FreeTDS & TinyTDS #511

Open
gengle opened this issue Feb 22, 2022 · 9 comments
Open

FreeTDS & TinyTDS #511

gengle opened this issue Feb 22, 2022 · 9 comments

Comments

@gengle
Copy link

gengle commented Feb 22, 2022

There has been many changes with SQL Server lately with the System.Data.SqlClient rewrite. I recommend that we replace the FreeTDS, TinyTDS and design a new facade using .NET running on windows and linux. marshalling between .NET & Ruby won't be too difficult - we can use uds, sockets, or grpc, etc.

Let me know if you'd like help with any of this.

@wpolicarpo
Copy link
Member

wpolicarpo commented Feb 22, 2022

What are the advantages of what you are proposing over FreeTDS? Also, wouldn't it make more sense to write a new binding for that implementation rather than rewriting TinyTDS?

@gengle
Copy link
Author

gengle commented Feb 23, 2022 via email

@aharpervc
Copy link
Contributor

I've speculated about this exact concept myself. I think it's interesting. But I agree with @wpolicarpo, it'd probably just need to be a new from-scratch project. I think that designing a new gem is a much better use of time than trying to retrofit a new driver backend into TinyTDS itself.

There's not much ruby code in here anyway even if you did want to preserve it. client.rb is only 136 lines and the majority is version mapping.

@wpolicarpo
Copy link
Member

If the idea is to have a new interface to interact with SQL Server AND use it with the ActiveRecord adapter, we could easily expand the idea already implemented there (not fully yet, I know) and use different modes. See here.

It doesn't make sense to rewrite tiny_tds to use another backend, but it does make sense to have another client that could be used with the adapter.

If you feel like you could build a PoC gem that implements a new interface with SQL Server, I'm more than happy to try to integrate with the adapter if there's a good reason for that (being faster, easier to maintain/extend/understand, etc).

@gengle
Copy link
Author

gengle commented Feb 24, 2022 via email

@brodjustice
Copy link

Did this idea progress any further?

@gengle
Copy link
Author

gengle commented Oct 24, 2022

@brodjustice apologies as with my schedule I wasn't able to focus any time on this. I might consider exploring this again if there is an interest.

@aae42
Copy link

aae42 commented Jan 3, 2023

@brodjustice apologies as with my schedule I wasn't able to focus any time on this. I might consider exploring this again if there is an interest.

consider this interest

if i were to solve the problem tiny_tds solves today, i would use your design... c# sql client is basically the gold standard, c#/ruby interface of grpc seems logical

it would require .net runtimes as a dependency but i think that's reasonable

the other option is using go sql client to compile c stuff to use with ffi gem, but the go sql clients aren't as nice

@Michoels
Copy link

This would be great, but it sounds like a massive undertaking.

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

6 participants