Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Thom Chiovoloni
    @thomcc
    and window functions are... weirder: https://sqlite.org/windowfunctions.html
    scalar functions are normal sqlite functions. i dont think the python bindings expose any way to define non-scalar functions, so it doesnt bother distinguishing
    Justin Wood
    @ankhers
    I am trying to use rusqlite::named_params! macro, but I am getting an error with compiling saying "the trait ToSql is not implemented for (&str, &dyn ToSql)", am I supposed to enable a feature for this?
    Thom Chiovoloni
    @thomcc
    can you file a bug?
    that sounds wrong but helping in a github issue seems easier
    Justin Wood
    @ankhers
    Sure thing.
    Thom Chiovoloni
    @thomcc
    thanks. if you’re using master, it might be possible... we changed some stuff and havent cut a release yet, but maybe i missed named_params somehow
    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