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
When creating a new instance of a TinyTds::Client, it immediately tries to connect to the database. It might be a better pattern to separate the connect part to a new method that needs to be called separately.
For one, you could call escape on the Client without requiring a live connection to the server.
Second, we could investigate to hand off the GVL when calling dbopen and dbuse. Both of these functions communicate with the server. In case the connection is slow / bad, it blocks the current Ruby thread. I personally would feel more comfortable handing off the GVL within a method instead of when we initialize a new object in Ruby space.
Technically, the connect method on the client is already public. It would be more about removing it from initialize.
The text was updated successfully, but these errors were encountered:
For one, you could call escape on the Client without requiring a live connection to the server.
Yup, completely agree. This has always been a massive pain point for me. Another approach would be to make escape a class method, so it doesn't even need an instance to be called.
Additionally... does it even need to be in C space? This seems extremely peculiar and not nearly as robust as you'd hope/assume. What if escape was just pure Ruby?
I was wondering the same - I think it can be pure Ruby since it does not call anything that requires it to be in C space. And class method would also make sense. It could even be it's own separate small class (TinyTds::Encoder?)
(this is just an idea for now)
When creating a new instance of a
TinyTds::Client
, it immediately tries to connect to the database. It might be a better pattern to separate theconnect
part to a new method that needs to be called separately.For one, you could call
escape
on theClient
without requiring a live connection to the server.Second, we could investigate to hand off the GVL when calling
dbopen
anddbuse
. Both of these functions communicate with the server. In case the connection is slow / bad, it blocks the current Ruby thread. I personally would feel more comfortable handing off the GVL within a method instead of when we initialize a new object in Ruby space.Technically, the
connect
method on the client is already public. It would be more about removing it frominitialize
.The text was updated successfully, but these errors were encountered: