5 ms·
The API for this is currently the only thing I wish I could grok a bit better. It seems like it would be hard to make it work with existing libraries that can a
by lucasyvas 4y ago
The API for this is currently the only thing I wish I could grok a bit better. It seems like it would be hard to make it work with existing libraries that can access SQLite, which is kind of a shame.
I'm thinking of sqlx in Rust (or any other language binding / ORM for that matter), which has compile time schema safety. This is a nice capability, and because this interface seems non-standard (possibly for good reason), I guess we are being asked to give some of those things up.
I am getting a bit ahead of myself on the Rust part (presumably that will eventually be supported as part of workers-rs), but I think the feelings still stand if you consider the JS ecosystem.
Edit: I may actually be wrong, but presumably the entire surface isn't covered because there's no file opening, etc.
- mritchie712 4y agoThere might be a `env.DB.url` (e.g. the jdbc URL) which you could pass into an existing library.
- lucasyvas 4y agoInteresting thought! Would love to see more details.
- yencabulator 4y agoI'm kinda willing to make a bet that this rides on top of what looks like HTTP to the Javascript engine. That's how their worker-to-worker and worker-to-durable-object protocols are. (It's not really HTTP as in it might never cross a TCP socket, just get shuffled from one V8 isolate to another, but it looks like a `fetch` call to the Javascript.) It's also worth remembering that SQLite itself has no wire protocol, it's a library. And there is no such thing as a "SQL wire protocol". It sure isn't gonna be Postgres wire protocol either. From the article: > D1’s API includes batching: anywhere you can send a single SQL statement you can also provide an array of them, meaning you only need a single HTTP round-trip to perform multiple operations. This is perfect for transactions that need to execute and commit atomically: