Allow configuring http

[ben-xD]

When using a local database, e.g. libsql://localhost:3030, this library would use https. This fails because I can't access localhost over https. Please allow me to disable https, so that I can connect to a local client over HTTP. I'm using Cloudflare Workers so it seems like I cannot use the file directly.

Error

[0] workerd/jsg/util.c++:276: error: e = kj/compat/tls.c++:74: failed: OpenSSL error; message = error:100000f7:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER
[0] stack: 1027b92ab 1027bbb1f 1027bc23b 1027bc968 1027c47f8 103760d3c 103762998 1028b3304 1028b3728 1028b2eec 1037506d0 1024495d0 1024468d4 10251c2fc 10245df10 1

The error seems very similar to https://stackoverflow.com/a/63321432/7365866

There some instructions on adding https for localhost https://web.dev/how-to-use-local-https/, but that requires turso dev to use the certificate.

[honzasp]

The libsql: scheme always implies TLS (either https: or wss:). If you want to use a plaintext protocol, then you can pass a http: or ws: URL to the client (so "http://localhost:3030" or "ws://localhost:3030" in your case). Unfortunately, there is no plaintext variant of libsql: that would allow the library to choose between http: and ws: automatically. We discussed this problem just yesterday, but we have yet to find a satisfactory solution.

[ben-xD]

Oh, I have tried http: in the past (mentioned in https://github.com/chiselstrike/turso-cli/issues/418#issuecomment-1555813513) but unfortunately I just a get a 404 error (the page returns 404 anyway if you visit http://locahost:3030 in the browser).

I'm a bit stuck on running a local database for testing.

I switched to use the http import, used DATABASE_URL=http://localhost:3030 and got:

[0] LibsqlError: SERVER_ERROR: Server returned HTTP status 404 and error: 404 page not found
[0]     at #send (index.js:33827:15)
[0]     at async HttpClient.execute (index.js:33736:24)
[0]     at async index.js:32872:22
[0]     at async resolveMiddleware (index.js:27315:22)
[0]     at async callRecursive (index.js:27348:25)
[0]     at async callRecursive (index.js:27348:25)
[0]     at async index.js:32241:18
[0]     at async callRecursive (index.js:27348:25)
[0]     at async callRecursive (index.js:27348:25)
[0]     at async index.js:32230:18 {
[0]   code: SERVER_ERROR,
[0]   name: LibsqlError,
[0]   stack: LibsqlError: SERVER_ERROR: Server returned HTTP st...index.js:27348:25)
[0]     at async index.js:32230:18,
[0]   message: SERVER_ERROR: Server returned HTTP status 404 and error: 404 page not found,
[0]   cause: undefined

[honzasp]

Ah, so you are using turso dev? That supports only a very outdated version of the HTTP API, the libsql client won't be able to talk to it. The only viable option for local development right now is to run sqld, which is the open-source part of Turso: https://github.com/libsql/sqld

[ben-xD]

Oh I didn't know that. I'll try that, thanks

[honzasp]

We decided to add a ?tls=0 query parameter to disable TLS with libsql: URLs (so http://localhost:3030?tls=0 will connect with either HTTP or WebSockets to localhost on port 3030 without TLS). I hope to implement this soon, but in the meantime, you can use http: or ws: explicitly.

[ben-xD]

I've tried sqld, connecting using ws://127.0.0.1:8080, but I get SQL_MANY_STATEMENTS.

1. I have only 1 migration file, and it has 3 SQL statements. This file is generated by drizzle-kit. Unfortunately, I get an error:

   file:///Users/zen/repos/batmark/node_modules/.pnpm/@libsql+client@0.1.6/node_modules/@libsql/client/lib-esm/hrana.js:331
       return new LibsqlError(e.message, code, e);
              ^
   LibsqlError: SQL_MANY_STATEMENTS: SQL string contains more than one statement
   at mapHranaError (file:///Users/zen/repos/batmark/node_modules/.pnpm/@libsql+client@0.1.6/node_modules/@libsql/client/lib-esm/hrana.js:331:16)
   at HranaTransaction.execute (file:///Users/zen/repos/batmark/node_modules/.pnpm/@libsql+client@0.1.6/node_modules/@libsql/client/lib-esm/hrana.js:243:19)
   at processTicksAndRejections (node:internal/process/task_queues:95:5) {
   code: 'SQL_MANY_STATEMENTS',
   [cause]: [ResponseError: SQL string contains more than one statement] {
   code: 'SQL_MANY_STATEMENTS',
   proto: {
     message: 'SQL string contains more than one statement',
     code: 'SQL_MANY_STATEMENTS'
   }
   }
   }

My migration script:

import { createClient } from "@libsql/client/web";
import { drizzle } from "drizzle-orm/libsql/index.js";
import { migrate } from 'drizzle-orm/libsql/migrator.js';
import * as dotenv from 'dotenv';
dotenv.config()

const client = createClient({
    url: process.env.DATABASE_URL!
});
const db = drizzle(client, { logger: true });

// docs: https://github.com/drizzle-team/drizzle-orm/blob/main/drizzle-orm/src/sqlite-core/README.md#-migrations
migrate(db, { migrationsFolder: './migrations' });

.sql file

CREATE TABLE `users` (
    `id` text PRIMARY KEY NOT NULL,
    `name` text NOT NULL,
    `created_at_seconds` integer NOT NULL,
    `email` text NOT NULL,
    `email_verification_token` text,
    `hashed_password` text NOT NULL,
    `updated_at_seconds` integer NOT NULL
);

CREATE TABLE `example` (
    `id` text PRIMARY KEY NOT NULL,
    `name` text,
    `owner` text NOT NULL,
    `created_at_seconds` integer NOT NULL,
    FOREIGN KEY (`owner`) REFERENCES `users`(`id`)
);

-- another statement

[CodingDoug]

@ben-xD Since you have a new issue that's unrelated to the one you originally posted, could you do us a huge favor and post that as a new issue? That will make it easier for us to track.

[ben-xD]

Sorry, I could've created a new issue for the SQL_MANY_STATEMENTS error, but I am not using Turso right now. I wouldn't want to create an issue that is outdated or not useful to any user. I just noticed one has been created: https://github.com/libsql/libsql-client-ts/issues/43 🙏

I switched to Postgres/Neon because of some rough edges with SQLite/turso, especially wrt. running things locally (which is important since I'm travelling). I can run Postgres locally without neon.

[honzasp]

Hi Ben, I am sorry about that! We are working on improving the turso dev experience, so that it spawns a full-fledged sqld instance that is fully compatible with Turso. In the meantime, you can get full local experience by running sqld directly.

[CodingDoug]

@ben-xD please don't worry about filing issues that you feel are not helpful for other users. The issues are helpful for us to track how people are using the product, and the specific cases that are problematic, even if solutions appear to be in progress. It's never a bad idea from our perspective to detail the specific steps you're taking to reproduce some unexpected behavior!

There are a number of ways to run sqld locally now (including an improved turso dev). If you have time, your feedback would be helpful on the supported options so far: https://github.com/libsql/sqld/blob/main/docs/BUILD-RUN.md

[honzasp]

Fixed in 0.2.0