Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Thom Chiovoloni
    @thomcc
    what part of the documentation makes you think that wouldnt be
    perhaps the docs should be improved
    Cédric Bellegarde
    @gnumdk_gitlab
    English is not my language, so maybe a confusion around the word scalar, will try to implement, if there is really something confusing, will report the an issue
    Thom Chiovoloni
    @thomcc
    oh
    scalar just means the function takes 1 argument
    err
    one rows worth
    aggregate functions are like SUM(...)
    which take many rows as arguments
    https://sqlite.org/lang_aggfunc.html
    Cédric Bellegarde
    @gnumdk_gitlab
    Thanks, so it's me :D
    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