[sql] Call from Rust side

[LetrixZ]

I wanted to know if it's possible to make queries from the Rust side, or if should be using other library if I don't plan to use the frontend side.

Currently, with the store plugin I do this:

with_store(app.app_handle(), stores, path, |store| {
  Ok(serde_json::from_value::<Credentials>(
    store.get("credentials").unwrap().clone(),
  )?)
})
.map_err(|_| "Error getting credentials".to_string())

I checked the code and it doesn't seem to be any method to call from the Rust side.

[FabianLars]

I wanted to know if it's possible to make queries from the Rust side

Nope. I couldn't come up with a nice enough api (without spending too much time on it), so it's on hold for now, meaning you'd have to use some rust crate to connect to the db.

It's still planned though so i'll leave this issue open.

or if should be using other library if I don't plan to use the frontend side.

Honestly, you should do that either way if your frontend don't need access to it directly or if it's only a few requests you can better provide via tauri commands. Way more secure to not expose the db in your frontend and if that matters, rust may be able to optimize the code a bit more if it's more specific 🤷

[Xstoudi]

Could we consider exposing the database instance as a compromise between exposing a nice and polished api and having to reinvent the wheel?

Right now I'm literally copying code from the plugin to connect another pool to my sqlite file using sqlx. :/

[Xstoudi]

To continue the conversation that briefly took place in #509.

@thulasi-ram thanks for your instructive write-up, didn't know about Greenspun and Hyrums.

1. It feels wrong to me as most of the other Tauri plugins I used allow calls from both Rust and frontend sides. Right know I'm just somehow copy-pasting the sqlx init code from sql plugin to recreate an other connection that I can use Rust-side.
2. I had the opportunity to see people maintaining this kind of APIs in other contexts and it seems to always be a real pain and time consuming task. I totally agree with @FabianLars on this point.
3. sqlx has currently not any major release beside v0 and I think the feature-flag approach may just do the job tbh. I'm really not a fan of the "Major changes in minor releases" policy, even if stated as such tho.
4. In my case, I'm happy with sqlx and I like the comfort zone offered by the "Tauri official" thing, so I'd prefer to apply proposal 3 rather than re-creating a 3rd party dependency.

To summarize, I'm in favor of making DbInstance public and let query builders and ORM to the 3rd parties. I'm

[FabianLars]

3. sqlx has currently not any major release beside v0 and I think the feature-flag approach may just do the job tbh. I'm really not a fan of the "Major changes in minor releases" policy, even if stated as such tho.

In that case, every 0.x release counts as a major (breaking) release so we may have to start with this fairly early on, but so far sqlx had a pretty slow release cycle so that may not be too bad. Either way, i agree, i'm not the biggest fan of these policies either, but i think we will have to use some kind of policy even with the feature flags to dictate when the default sqlx version changes.

[sjfkai]

What is currently the best solution to this problem? I have recently started working with Rust and Tauri, and I would like some examples. I want the app to continue querying the database in the background even after the window is closed. I have seen the example at https://github.com/RandomEngy/tauri-sqlite, and I'm not sure if it is a good method.

Thanks

[martpie]

Any news on that? It's a little weird to only provide a JS API for SQL. I think only exposing load / execute would solve most of the problems people are facing, but I may be missing a piece of the puzzle here.

[roniemartinez]

I have the same issue with data coming from Rust side and needs to go directly to the database. Sadly the solution is to pass it to the frontend and then save to database from JS side.

https://discord.com/channels/616186924390023171/1358904998494208242

I think the solution for now is to make the functions public, at least for load() and execute().