search

tursodatabase / libsql

libSQL is a fork of SQLite that is both Open Source, and Open Contributions.
https://turso.tech/libsql
MIT License
9.54k stars 252 forks source link

libsql-sys: Removed unused import and fixed path. #1605

Closed haaawk closed 2 months ago

haaawk commented 2 months ago

@spigaz Please explain why there's a problem with the path and how does the fix work.

spigaz commented 2 months ago

@spigaz Please explain why there's a problem with the path and how does the fix work.

To be honest I don't remember, I was trying to get this example running: https://github.com/spigaz/workers-rs-axum-tursodb

Normally it should be something obvious, otherwise I would have commented it.

I can try to figure that out latter today with the example, but if you try and you just can't, I believe you can simply ignore it.

haaawk commented 2 months ago

@spigaz Please explain why there's a problem with the path and how does the fix work.

To be honest I don't remember, I was trying to get this example running: https://github.com/spigaz/workers-rs-axum-tursodb

Normally it should be something obvious, otherwise I would have commented it.

I can try to figure that out latter today with the example, but if you try and you just can't, I believe you can simply ignore it.

It would be great if you could try to figure out why this was needed. I probably won't find time today to setup wrangler and try it myself. Thank you!

spigaz commented 2 months ago

It would be great if you could try to figure out why this was needed. I probably won't find time today to setup wrangler and try it myself. Thank you!

@haaawk I started remembering some of the details...

Initially I tried to use libsql to connect to tursodb from a worker, but I couldn't get it to compile fully, so I'm guessing that was a compilation error, probably because of wasm.

Right now, I updated it to depend on workers 0.3.0 and I'm not having any compilation issues, only warnings, so I don't think its relevant, at least anymore.

Looking back to my turso discord history https://discord.com/channels/933071162680958986/1236707797605810196

IdkWhatever69 — 05/05/2024 4:58 PM
wasm was experimental until very recently.
the mio might be an artifact of that.
for pushing to production right now, i suggest making http requests using https://github.com/tursodatabase/libsql/blob/main/docs/HTTP_V2_SPEC.md
[4:59 PM]
i myself have found more stability that way
[5:01 PM]
@Alexander btw did you follow this tho? https://github.com/tursodatabase/libsql-client-rs?tab=readme-ov-file#cloudflare-workers

This client wasn't compiling for me, because apparently I need to use hrana and it had an dependency on mio that didn't compiled for wasm, if I recall correctly.

So I had to use lib-client-rs.

This was just a test case for turso, I'm not using it, but if its relevant for you I can try to port my example back to libsql, but I can only do it latter today.

haaawk commented 2 months ago

Cool. Thanks @spigaz. If I understand correctly we can close this PR then. Let me know if I misunderstood you.

spigaz commented 2 months ago

@haaawk Yes, that's the best option.

If I end getting the example running with libsql, I'll let you know.

spigaz commented 2 months ago

@haaawk I updated my example to use libsql, it seems to compile fine, if I don't enable the remote flag. But remote is required to open a remote connection.

Remote requires hrana that requires tokio that requires mio. Mio doesn't compile to wasm yet AFAIK. There might be a workaround, I don't know.

But in practice, as is, libsql doesn't support wasm for remote databases. Its not cloudflare worker specific.

Only using the old deprecated libsql-client-rs https://github.com/tursodatabase/libsql-client-rs?tab=readme-ov-file#cloudflare-workers

So I don't think there is a point to worry with keeping the worker dependency updated.

Thanks!