Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Thom Chiovoloni
    @thomcc
    @ankhers FYI in the next release (and on the master branch) we support using named_params! with normal execute/query functions
    (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
    oh
    ah yeah i see
    well
    hm
    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, .. },
                    _,
                ),
            ) => ...

    or

            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
    image.png
    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?