rusqlite/community

Gitter channel for `rusqlite` project

Thom Chiovoloni

@thomcc

(well be deprecating the _named versions, but they'll still be there for a while probably as to not break all the code out there using the "old" way)

hutchisr

@hutchisr

Is there a way to generate a variable set of named parameters at runtime? I have a situation where I need to generate a query and query parameters based on user input and then run it across multiple databases and I can't figure out how to generate/store the parameters in a form methods like query_named will accept

Justin Wood

@ankhers

The second parameter to query_named is a list of tuples. A literal would be [(":foo", foo), (":bar", bar)]. You might need to write foo as &dyn ToSql.

Sorry, it should be &foo, not just foo.

Take a look at the documentation, it includes an example https://docs.rs/rusqlite/0.24.2/rusqlite/struct.Connection.html#method.execute_named

hutchisr

@hutchisr

I think my problem is I'm unclear how to construct an owned type I can store that can be passed as a &[(&str, &dyn ToSql)]. My first thought was Vec<(&'static str, Box<dyn ToSql>)> but that doesn't seem to work

Thom Chiovoloni

@thomcc

should work if you do &the_vec

if it doesnt try &the_vec[..], which will definitely work

ah yeah i see

well

so strictly speaking it should be fine to transmute from from &'a [(&'static str, Box<dyn ToSql>)] to &'a [(&'static str, &'a dyn ToSql)]

it's a bit odd that you're generating a dynamic list of parameters that are named

@hutchisr if you can use positional that would be better

(oh sorry for the ping, i just realized this convo is only a minute old so you're probably still around)

hutchisr

@hutchisr

passing the vec by reference or using as_slice, etc. still gets a type mismatch. That does work if I'm just using an unnamed &Vec<Box<dyn ToSql>> but not for the named variant. I was trying to avoid that, however, since the complexity of the query and user input means I can't used numbered parameters and just using ? parameters results in numerous copies of several parameters that get used multiple times in the query

Thom Chiovoloni

@thomcc

right, you'd have to transmute actually

like, unsafe

it should be sound but

yeah

hmm

let me check if coherence would allow me to fix this for you with the way we reworked params on the master branch

hutchisr

@hutchisr

@thomcc thanks for your assistance, not too big of a deal for me to use ordered parameters for the moment but if this does become more straightforward in a future version that will be great

Thom Chiovoloni

@thomcc

@hutchisr ah

well

i just wrote a patch fixing your issue for the master branch

😅

Thom Chiovoloni

@thomcc

if this does become more straightforward in a future version that will be great

The main question is whether or not this causes people to get wierd type inference errors when using named params directly

right now the code on master is a big (mostly compatible, or at least with small changes) change from the current API design, mostly intended to get rid of NO_PARAMS and the duplication of _named vs non-_named functionality

but it relies on type inference a lot

Scott Bronson

@bronson

I'm trying to recognize when there's a constraint violation or a missing table error... but the code I'm ending up with is large duplication: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=a8b93f8e39f0716b61ae07d02285c001

Is this the right way to match 2 errors? Or am I making this harder than it needs to be?

    let rows = match result {
        Ok(rows) => rows,

        Err(e @
            rusqlite::Error::SqliteFailure(
                libsqlite3_sys::Error { extended_code: 2067, .. },
                _,
            ),
        ) => panic!("constraint violation: {:#?}", e),

        Err(
            rusqlite::Error::SqliteFailure(
                libsqlite3_sys::Error { extended_code: 1, .. },
                msg,
            ),
        ) => panic!("no such table: {:#?}", msg.unwrap()),

        _ => panic!("some other error: {:#?}", result)
    };

Scott Bronson

@bronson

(That's mostly cribbed from rusqlite/rusqlite#760 )

Thom Chiovoloni

@thomcc

seems fine. someday i’d like to improve the error type since its a bit wonky, but yeah what you have now is likely best

you might be able to use constants instead of the integer literals though

Scott Bronson

@bronson

Hah, yes, it doesn't seem very ergonomic.

I've been having difficulty getting the constants to work. I'll try again.

Thanks!

Thom Chiovoloni

@thomcc

either

        Err(e @
            rusqlite::Error::SqliteFailure(
                libsqlite3_sys::Error { extended_code: SOME_CONSTANT, .. },
                _,
            ),
        ) => ...

        Err(e @
            rusqlite::Error::SqliteFailure(
                libsqlite3_sys::Error { extended_code: libsqlite3_sys::SOME_CONSTANT, .. },
                _,
            ),
        ) => ...

should work

in general rust doesn't have the best erogonomics with matching complex types. you see this here but also when working with certain libraries — event handling with winit requires very complex match statements like this too

i don't know a great solution honestly

i think most of my goals for improving the error type wouldn't really mke this problem go away

Scott Bronson

@bronson

I can use libsqlite3_sys all day on the Rust playground... but when I try to do it locally, I get

26 |                 libsqlite3_sys::Error { extended_code: libsqlite3_sys::SQLITE_ERROR, .. },
   |                 ^^^^^^^^^^^^^^ use of undeclared crate or module `libsqlite3_sys`

Scott Bronson

@bronson

Just did this:

cargo new /tmp/rusqtest
echo 'rusqlite = "0.25"' >> /tmp/rusqtest/Cargo.toml
echo 'fn main() { libsqlite3_sys::SQLITE_CONSTRAINT_UNIQUE }' > /tmp/rusqtest/src/main.rs

cd /tmp/rusqtest; cargo build And I get that error.

Is there something weird about my system?

Where communities thrive

People

Repo info

Activity