-
Notifications
You must be signed in to change notification settings - Fork 37
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
Add an MSSQL driver #12
Comments
There's still a lot to do:
|
One approach I've used when a C binding needs to have all operations run in the same thread under You could also look at Mwt which hasn't been released formally but could be if there is a use for it. |
Hmm I'm having trouble getting the driver to load. If I do it the same way as the other drivers I get errors like:
https://circleci.com/gh/brendanlong/ocaml-caqti/26 It seems like jbuilder has a different way of linking dynamic libraries which looks like this:
but if I do that, I get:
|
With debugging:
I wonder if the FreeTDS module is missing something? |
It looks like |
Thanks for doing this! Do you have a reference to the documentation which require everything to run in one thread? For the month-related issue, I suggest running a query on when establishing an new connection, and caching the result. See |
Two request:
|
This is a tricky one, and the main reason I haven't added an ODBC driver. The issue with ODBC is there there are multiple databases behind it having different quoting conventions, and a mismatch of quoting algorithms comes with a high risk of causing an SQL injection vulnerability. Preferably we should rely on algorithms implemented by vendor. If the vendor has precise documentation of something which can be used across versions, that would suffice too. |
@brendanlong the buggy META file that @paurkedal pointed out suggests that you should switch FreeTDS to dune. Writing META by hand isn't wise - it's best to let dune do it for you. |
Ok, I'll open a pull request with freetds. Thanks for helping me find out where the problem was! @paurkedal Sorry about the semi-messy code right now. ocp-indent is doing weird things to the code and I didn't feel like manually fixing formatting until I was done (since ocp-indent would just break it again every time I save..). I'll definitely clean it up to match your coding style before opening a real pull request. Maybe I imagined the single-thread thing? The FAQ says FreeTDS isn't threadsafe but it looks like it doesn't particularly care which thread you run each function on, as long as you never do multiple at the same time. |
From the FreeTDS doc:
The anti-thesis of the second statement suggests to me we should be good, since access to the connection will be serialized though the main thread. That is, presuming Lwt/Async communication between threads include the needed memory barriers, but how could it not? See also the second MT case for sqlite3 for comparison, where I assumed sequential access from different worker threads would be fine. |
Yeah my remaining concern is that we still need to serialize usage if we're not using the same thread every time. For example, if someone runs this:
We don't want both requests to be executed concurrently on different threads using the same connection. |
That's not safe for other databases either, since results are attached to the DB connection. To do queries in parallel, one can pull multiple connections from a pool:
I better take a note about it in the documentation. |
I wonder if there's a way to make the API handle that case properly without being too complicated. It seems really bad that a straightforward use of the Async API will segfault your program. :\ |
Yes, at |
I had a look at the issue with concurrent usage. I had already added a check in P.S. I didn't mean to take this issue myself. |
I got the changes I needed into |
Good. And yes, the parameters will be tricky, and I think it's more than the need to rewrite the query string: My main concern is to deliver the strings in a way that is guaranteed secure for any database and version supported by FreeTDS. E.g. In standard SQL It may be simpler if the database is known to be MSSQL. I am not familiar with it myself, but if it has some generic escape mechanism like BASE64 or hexadecimal, that should be a safe option. (Added: Consider |
Once we decide a suitable way of passing strings, the FreeTDS case should not be fundamentally different from the other drivers. Note that queries strings are delivered in parsed form ( |
Just creating this to document a work-in progress driver using the FreeTDS module. Unfortunately FreeTDS doesn't seem to have an async interface so we'll have to just run everything in background threads.
Also, FreeTDS requires that everything run in the same background thread, which I'm not sure the current Preemptive module does?
WIP here: https://github.com/brendanlong/ocaml-caqti/commits/mssql
The text was updated successfully, but these errors were encountered: