-
Notifications
You must be signed in to change notification settings - Fork 7
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
Support multi-statement, multi-line transactions #163
Comments
avinassh
added a commit
to avinassh/turso-cli
that referenced
this issue
Feb 23, 2024
This patch uses websocket connections instead of HTTP for the shell. In HTTP mode, we use a connection pool. So, at every invocation in shell, can use a different connection. While this is okay for most cases, but this doesn't work for operations involving stateful connections viz. transactions, ATTACH statements and a few PRAGMA statements. closes: tursodatabase#784 tursodatabase/libsql-shell-go#163
haaawk
pushed a commit
to tursodatabase/turso-cli
that referenced
this issue
Feb 26, 2024
This patch uses websocket connections instead of HTTP for the shell. In HTTP mode, we use a connection pool. So, at every invocation in shell, can use a different connection. While this is okay for most cases, but this doesn't work for operations involving stateful connections viz. transactions, ATTACH statements and a few PRAGMA statements. closes: #784 tursodatabase/libsql-shell-go#163
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now, if I execute the following lines in the shell connected with a remote host (e.g. Turso):
, each of those statements are sent in a separate connection, so
COMMIT
does not match any transaction and errors out withSQLite error: cannot commit - no transaction is active
.That happens because every single statement is sent in a separate connection. What we should consider instead is to establish a long-living connection when the shell is launched, and send all statements within that single connection (possibly reconnecting if it got closed for any reason). That would allow people to send multi-line interactive transactions, without getting unexpected errors.
The example above is benign, because it just reads from the database, but we can also imagine the following:
. When user sends those statements, he assumes
BEGIN IMMEDIATE
started a transaction, and both inserts happen within that transaction. In reality,BEGIN IMMEDIATE
was sent in a separate connection that got disconnected later, and both inserts will be sent in separate connections as well, so they don't happen atomically, and if the first succeeds, and the second one fails, the user might get very surprised.The text was updated successfully, but these errors were encountered: