sqld
sqld copied to clipboard
libsql
sqld http connection wrong error response sometimes
Inconsistent error return using http connection
When sending an invalid statement as request:
{
"statements": [
{
"q": "select"
}
]
}
sqld returns an object with the error:
{"error":"unexpected end of input at (1, 7)"}
But there are cases where it returns an array of objects
First case
Given a table created with following commands:
→ create table foo (id primary key);
→ create table bar (id integer, foreign key(id) references foo(id));
→ insert into foo (id) values (0);
→
→ insert into bar (id) values (0)
When doing a drop table request:
{
"statements": [
{
"q": "drop table foo;"
}
]
}
sqld returns (an array of objects)
[ { "error": "FOREIGN KEY constraint failed" } ]
Second case
Creating an table that already exists. Request:
{
"statements": [
{
"q": "CREATE TABLE users (email TEXT);"
}
]
}
returned error:
[ { "error": "table users already exists in CREATE TABLE users (email TEXT); at offset 13" }]
This raises the question: how long are we going to support the old v0 HTTP API that we really aren't going to use in the future for client SDKs? At some point it will become a maintenance drag, and add very little to the value of the product.
@CodingDoug Good point!
New information about this: The requests that are with wrong responses is returning 200 status code. So the inconsistency is with the way we return error on valid request. libsql-client-go is expecting an success body to be like this:
httpResults:
- results: resultSet
- error:
- message: string
But sqld is returning this:
httpResults:
- results: resultSet
- error: string
I think we can get rid of the legacy HTTP endpoint
Looks like it's still in use here: https://github.com/libsql/libsql-client-java
Don't know if anyone is using it. @penberg @MarinPostma
@penberg is is worth migrating the java client to the new API?
I think we should migrate the java client. FYI @penberg
