FreeTDS & TinyTDS

[gengle]

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]

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]

I was thinking we’d eliminate TinyTDS entirely. The codebase is dating itself, references ot synbase and all the low level protocol boilderpoint code worries me. Instead, what I’d recommend is slowly swap FreeTDS out with a new middleware driver using C# - hopefully the contract between this C# driver and TinyTDS would be minimal.

Some background. I stubbled on to your project as I was trying to find a working rails sample that I could get working with a graphql service. There are plenty of ActiveRecord samples using other rdms but for some reason MSSQL isn’t very popular and the samples I did find had integration issues or was not implemented fully.

I’m a strong Java, c#, MSSQL developer… a bit green on the Ruby side but I’d like to help where I can.

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows

From: Wanderson @.> Sent: Tuesday, February 22, 2022 3:24 PM To: @.> Cc: Greg @.>; @.> Subject: Re: [rails-sqlserver/tiny_tds] FreeTDS & TinyTDS (Issue #511)

What are the 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?

— Reply to this email directly, view it on GitHubhttps://github.com/rails-sqlserver/tiny_tds/issues/511#issuecomment-1048225830, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABB2FQ4HHWURX5R2EIYFLGTU4P5KLANCNFSM5PAPOTBQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[aharpervc]

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]

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]

Exactly. Sounds like a plan to me. I’m tied up the next couple weeks but hopefully next month sometime I’ll be able to take a crack at this. Do you have a preference on IPC used? gprc is what I’d probably recommend.

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows

From: Wanderson @.> Sent: Wednesday, February 23, 2022 11:09 AM To: @.> Cc: Greg @.>; @.> Subject: Re: [rails-sqlserver/tiny_tds] FreeTDS & TinyTDS (Issue #511)

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 herehttps://github.com/rails-sqlserver/activerecord-sqlserver-adapter/blob/5decfd28a6b4dbbd9777dc6e6477eec44fa9a0a3/lib/active_record/connection_adapters/sqlserver_adapter.rb#L62-L70.

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

— Reply to this email directly, view it on GitHubhttps://github.com/rails-sqlserver/tiny_tds/issues/511#issuecomment-1049009187, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABB2FQYIZ4YCHALFYCGZCLTU4UIEHANCNFSM5PAPOTBQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[brodjustice]

Did this idea progress any further?

[gengle]

@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]

@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]

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