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
I'm writing a web app and noticed that, under the very specific conditions that I tried to isolate in the snippet below, a SELECT query ran with #execute would return nothing.
If I run this snippet and navigate to 0.0.0.0:8080/test, the first query using the string from rack's env will always fail, while the second one using a string literal will succeed.
Calling .dup or .clone on the string from rack's env won't work either, the only way is to construct another string entirely.
I ran the tests and they all pass.
SQLite version 3.17.0
gem version 1.3.13
Ruby version 2.4.0p0 (2016-12-24 revision 57164) [amd64-freebsd11]
The text was updated successfully, but these errors were encountered:
I can't tell for sure because the gist is deleted, but I think this is similar to #391. Database object can be shared among threads, but prepared statements cannot. I will write some documentation and guidance for threaded programming with SQLite3.
I'm writing a web app and noticed that, under the very specific conditions that I tried to isolate in the snippet below, a SELECT query ran with #execute would return nothing.
https://gist.github.com/steinuil/bf5ffcc1b78fa62b4f3b1a11fdb98998
If I run this snippet and navigate to 0.0.0.0:8080/test, the first query using the string from rack's env will always fail, while the second one using a string literal will succeed.
Calling .dup or .clone on the string from rack's env won't work either, the only way is to construct another string entirely.
I ran the tests and they all pass.
SQLite version 3.17.0
gem version 1.3.13
Ruby version 2.4.0p0 (2016-12-24 revision 57164) [amd64-freebsd11]
The text was updated successfully, but these errors were encountered: