Replies: 1 comment 5 replies
-
|
I'm generally open to share the relevant code, but that might not be as straightforward as you believe. In the best case it would be possible to share the whole backend implementation, so that you only need to provide a custom connection implementation. That would mean that everything else would "just" work, as you could write The What might be possible is to somehow store all the ffi functions used internally as function pointers in the value type, so that diesel itself could register the libsqlite3 functions there and your wasm connection could register the wasm functions there. That also would require some additional work to store the value pointer itself, although we could maybe just do that as void pointer and cast it later in some shim to the right type? |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, after writing this I realized that the SQLite backend was unique in that it held these ffi-specific types around so I closed this. I'm also not sure how wise it is to make large changes if a working I like this function pointer approach, and I'd be happy to give it a stab and see if anything comes of it.
Are there benchmarks i'd be able to compare a preliminary implementation against in diesel which already exist? |
Beta Was this translation helpful? Give feedback.
-
|
Given that this should be the only location that would need changes, I'm open to that even if the wasm-c-abi fixes are stable in the next year or so. For the other backends it's already possible to write out of tree connections, so it is desirable to have that here as well. There are benchmarks in the diesel-bench folder. They use criterion, so it should be easy to record a baseline via |
Beta Was this translation helpful? Give feedback.
-
|
Just for future reference: Here is the last update I've found for |
Beta Was this translation helpful? Give feedback.
-
|
Did you mean to throw a link in there? i'd be interested in it 😅 |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I somehow managed to not copy the link in here: rust-lang/rust#129534 |
Beta Was this translation helpful? Give feedback.
-
Hello All!
For the past ~month, I've been working on an alternative WASM SQLite backend for diesel crate
Interacting with external Clibs from WASM code is tricky. Compiling to
wasm32-unknown-emscriptenand linking with SQLite is possible, but then allwasm-bindgensupport is lost.diesel-wasm-sqliteimplements an alternative solution, where the SQLite WASM module is loaded separately and called from the backend. This can be a temporary solution until compiling the C SQLite dependency withwasm-c-abiis possible and no longer 'unstable'.(if someone can already do that, please let me know :)
Currently lots of code in the wasm backend is copy-pasted from the diesel-backend and specialized for the
WasmSqlitebackend type. It would be great to share code with the main diesel library in order to avoid duplicating all code in the backend.I propose creating a new feature flag
sqlite-backend(or whatever name works) that exposes theSqlitebackend type, but does not import thelibsqlite3-syslibrary. This would allow my backend to access all commonQueryBuilderfunctions, but specialize theWasmSqliteConnectionfor a SQLite WASM module in the browser.Another potential solution could be to split the sqlite feature flags into
sqlite-backendandsqlite, enablingsqlite-backendin thesqlitefeature, along with thelibsqlite3-sysdependency. This has the advantage of lessfeature = ""declarations on items.Signatures of common code in the backend (some of these are still private):
Essentially anything QueryBuilder-related that isn't tied to the ffi:
all of
insert_with_default_sqlite.rsimpl<Col, Expr> InsertValues<WasmSqlite, Col::Table> for DefaultableColumnInsertValue<ColumnInsertValue<Col, Expr>>impl QueryFragment<WasmSqlite> for InsertOrIgnoreimpl QueryFragment<WasmSqlite> for Replaceimpl<T: QueryFragment<Sqlite>> QueryFragment<Sqlite> for ParenthesisWrapper<T>impl QueryBuilder<WasmSqlite> for SqliteQueryBuilderimpl<Expr> QueryFragment<WasmSqlite, SqliteReturningClause> for ReturningClause<Expr>impl QueryFragment<WasmSqlite> for LimitOffsetClause<NoLimitClause, NoOffsetClause>impl<L> QueryFragment<WasmSqlite> for LimitOffsetClause<LimitClause<L>, NoOffsetClause>impl<O> QueryFragment<WasmSqlite> for LimitOffsetClause<NoLimitClause, OffsetClause<O>>impl<L, O> QueryFragment<WasmSqlite> for LimitOffsetClause<LimitClause<L>, OffsetClause<O>>impl<'a> QueryFragment<WasmSqlite> for BoxedLimitOffsetClause<'a, WasmSqlite>impl<'a> IntoBoxedClause<'a, WasmSqlite> for LimitOffsetClause<NoLimitClause, NoOffsetClause>impl<'a, L> IntoBoxedClause<'a, WasmSqlite> for LimitOffsetClause<LimitClause<L>, NoOffsetClause>impl<'a, O> IntoBoxedClause<'a, WasmSqlite> for LimitOffsetClause<NoLimitClause, OffsetClause<O>>impl<'a, L, O> IntoBoxedClause<'a, WasmSqlite> for LimitOffsetClause<LimitClause<L>, OffsetClause<O>>All
impl ToSql<$SqlType, Sqlite> for $typeI'd be happy to submit a PR implementing this feature flag, but wanted a go-ahead/discussion from maintainers before then, especially if there's a better way.
Beta Was this translation helpful? Give feedback.
All reactions