Skip to content
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

Allow defining user-defined functions and procedures in Wasm #1

Closed
psarna opened this issue Oct 1, 2022 · 2 comments
Closed

Allow defining user-defined functions and procedures in Wasm #1

psarna opened this issue Oct 1, 2022 · 2 comments

Comments

@psarna
Copy link
Collaborator

psarna commented Oct 1, 2022

SQLite allows creating application-defined SQL functions by implementing and registering them in C: https://www.sqlite.org/appfunc.html

With WebAssembly emerging as the default, secure, and fast way of implementing user-defined functions, we should consider making this interface as Wasm-friendly as possible.

The first iteration could simply extend the existing C API with helper functions, which facilitate creating new functions in Wasm.

Later, we should consider extending SQLite's dialect with CREATE FUNCTION, widely known in the SQL world. This is not strictly necessary, because all kinds of functions can be registered directly via the C API, but it might be much more developer-friendly to provide a way of creating functions from SQL level, without having to recompile the database. Also, not everyone is fluent in C.

Important note 1: runtime

WebAssembly programs need to be run on a virtual machine. Candidates (feel free to post more suggestions):

  1. Wasmtime - my personal runtime of choice - I already have experience in using it, it's straightforward, fast, and quite feature-complete.
  • Wasmtime comes with C/C++ bindings in the form of libwasmtime.a library, which is convenient for binding with C; using it is a good candidate for a proof-of-concept implementation, because it's just a single header and a library you link with.
  • ... but in the long term we should consider implementing everything in Rust, Wasmtime's native language, and only then bind it to the existing C codebase; The original code has features that C bindings lack - the most important one being async support, but also some configuration options and tuning.
    Sample code using libwasmtime.a to register a hardcoded wasm function into sqlite: https://gist.github.com/psarna/93cdc1c2b4de36c98db8af5bc77b1351
  1. Wasmer - haven't tried it yet, but it has gained considerable traction and is reportedly faster than Wasmtime. I'm pretty sure it lacks async support, but maybe we don't need it for the time being.

Important note 2: ABI

WebAssembly programs are usually not written by hand, but instead coded in other languages, like Rust, C++, AssemblyScript, etc. WebAssembly standard specifies a very concise list of supported types, so in order to be able to run Wasm-based user-defined functions in sqlite3, we need to be able to translate between sqlite's types and WebAssembly. The most dev-friendly way of doing so is by defining an ABI (e.g. here's one for C: https://github.com/WebAssembly/tool-conventions/blob/main/BasicCABI.md). We could, for instance, decide that each sqlite type should be passed in its serialized form (sqlite3_value). Then, people coding functions in WebAssembly should either deserialize and serialize by hand, or by using our helper library which automatically takes care of type translation. Customarily, this library for Rust language can be called bindgen, and for lack of better example, here's one from the crypto world: https://docs.near.org/sdk/rust/contract-structure/near-bindgen . Since sqlite types are very well defined, we could create a mini-SDK for implementing Wasm user-defined functions in Rust, by exposing a #[libsql_bindgen] macro that automatically sprinkles vanilla Rust code with type serialization/deserialization.

Given that a fair part of sqlite userbase is Web developers, we should also consider providing a mini SDK with helper functions for AssemblyScript - a language designed specifically for compiling it into WebAssembly and integrating the resulting code with TypeScript/javascript.

@tantaman
Copy link
Contributor

tantaman commented Oct 7, 2022

Seems related to your goals -- https://github.com/mycelial/sqlite_wasm

psarna pushed a commit to psarna/libsql that referenced this issue Oct 17, 2022
…epFinalize().

FossilOrigin-Name: e37dddc1dd9c0530e4b1c6cb0ca7cba7451caa37734d383c9b47f378d7222242
psarna pushed a commit to psarna/libsql that referenced this issue Oct 17, 2022
…and make a few minor additions to that API.

FossilOrigin-Name: d6d79b661a1c6137d4693393e02416da4858d58dc84d144081a48d523655b483
psarna pushed a commit to psarna/libsql that referenced this issue Oct 17, 2022
FossilOrigin-Name: b9cdcc06a8f70694d10ee5b1a0fd9f08f4c705ce576e5103bbafb36fc9cc2122
psarna pushed a commit to psarna/libsql that referenced this issue Oct 17, 2022
…nse object structures to improve readability and clarity.

FossilOrigin-Name: 03b9db9b98cb36faa7de5a8a64d2e13c4aeaadfefb33ac92bb41056f6be3f121
psarna pushed a commit to psarna/libsql that referenced this issue Oct 17, 2022
… API. Still requires considerable cleanup, testing, and a solution for the exec-callback-via-event-type-name problem.

FossilOrigin-Name: 1e447849fb65887e806e3348a8a68f70ea6802bc0a1e56c385a279f27cc0cdda
psarna pushed a commit to psarna/libsql that referenced this issue Oct 17, 2022
…s from higher-level code. Initial version of sqlite3-worker1-promiser, a Promise-based proxy for the Worker API tursodatabase#1.

FossilOrigin-Name: b030f321bd5a38cdd5d6f6735f201afa62d30d2b0ba02e67f055b4895553a878
psarna pushed a commit to psarna/libsql that referenced this issue Oct 17, 2022
…d. Rename some vars for clarity. Increase wasm-side memory in order to be able to load the speedtest1 output.

FossilOrigin-Name: b5058f14fadbc8a1886f27cff08593dd2c8e2b2cb6d7bed3b8733a55f031989f
psarna pushed a commit to psarna/libsql that referenced this issue Oct 17, 2022
…ursodatabase#1 API.

FossilOrigin-Name: 24b82b9504db3d8e1335c2300b133f897dc1a541026dc24be5b0ffd8be66d977
psarna pushed a commit to psarna/libsql that referenced this issue Oct 17, 2022
…ner.js's list.

FossilOrigin-Name: 4488cb5798f34cbba14eb8e2aa5da8420c14a85d37d278d357406aedd5c3a9e5
psarna pushed a commit to psarna/libsql that referenced this issue Oct 17, 2022
 config-get response, including sqlite3.version.

FossilOrigin-Name: 711f458d188a0dbe6612069c856ade29323ab426dfa4f80e7b82757ccc474cb8
psarna pushed a commit to psarna/libsql that referenced this issue Jan 5, 2023
… changes.

FossilOrigin-Name: d797e183e96e04520636865204c02307b751fdc2949a04587de9259a1733e37b
@psarna psarna closed this as completed Jan 26, 2023
penberg added a commit that referenced this issue May 9, 2023
Push OP_MVCCOpenWrite emission to sqlite3OpenTable()
penberg added a commit that referenced this issue Jul 2, 2023
MarinPostma pushed a commit that referenced this issue Oct 17, 2023
Based on https://www.sqlite.org/lang_transaction.html
it is pretty easy to recognise all statements that
begin and end the transaction.

Fixes #1

Signed-off-by: Piotr Jastrzebski <piotr@chiselstrike.com>
MarinPostma pushed a commit that referenced this issue Oct 17, 2023
…bski

"""
Based on https://www.sqlite.org/lang_transaction.html
it is pretty easy to recognise all statements that
begin and end the transaction.

Fixes #1
"""

* 'main' of github.com:haaawk/iku-turso:
  Add tests for transaction boundaries
  Add rstest crate
  Make Message derive from Debug
  Improve transaction boundaries recognition
  Extract is_transaction_start/end
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants