Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    bent
    @bent:kde.org
    [m]
    Right, but isn't there some work before and after the db operation that can be done whilst the program is currently waiting for the db?
    oh I didn't saw that you added smth
    that makes sense
    Georg Semmler
    @weiznich
    Basically those impls are restricting the parallel execution of anything: https://docs.rs/sqlx/0.5.10/sqlx/trait.Executor.html#implementors
    The only way around would be using a database pool, but at that point the benchmark would compare apples to oranges (one connection to using a pool), so that's just not meaningful.
    To be clear here: I genuinely believe that there are some missing optimizations there in the sqlx implementation. There is just no reason why it cannot be as fast as diesel or rust-postgres. I likely would look for that inside of the deserialization code, so that part that's responsible for mapping database values to rust value.
    Сергей
    @MvSergey_twitter

    @weiznich
    My friend, Could you please help me with binding vector of strings (Vec<String>) into SQL query (Postgres):

    sql_query(r###"SELECT * FROM users WHERE users.name in ($1)"###)
    .bind::<diesel::sql_types::Array<VarChar>, _>(addresses)

    This is doesn't work. Message DatabaseError(__Unknown, "operator does not exist: character varying = text[]")

    Georg Semmler
    @weiznich
    That's because IN expects one bind per element in your vector.
    As far as I can say you cannot represent that query using diesel::sql_query and the 1.4.8 release.
    (BTW: There is no need to ping me for asking questions. Either I'm here and answer questions or not. Pinging me will not change anything, but exclude anyone else that may be able to answer your question…)
    Luuk Wester
    @ThouCheese
    Oh weiznich, I don't know if you'll find this interesting, but in order to drive experimentation with diesel-async (both by doing it myself and getting other people to do it) I implemented it as a database option for Rocket last night :) PR is here if you're interested: SergioBenitez/Rocket#2086.
    Georg Semmler
    @weiznich
    I would prefer to wait with integrating diesel_async anywhere till a official release is done.
    Luuk Wester
    @ThouCheese
    Right, I fully expect it to break overnight, and it says WIP WIP everywhere
    I added "diesel-async is very much in pre-alpha" to the PR to make it more clear
    Georg Semmler
    @weiznich
    Instead of seeing people work on integrating unreleased WIP crates in other crates I would prefer finishing the diesel 2.0 release first, as this is the main requirement for releasing an initial version of diesel_async. Every time some starts something about diesel and/or diesel_async and I need to response to that that takes valuable time away from my already limited time budget, that I would rather like spending on finishing the release...
    Luuk Wester
    @ThouCheese
    Right okay
    Rasmus Kaj
    @kaj:stacken.kth.se
    [m]
    Any way I (a diesel user, but not really an expert) can help with diesel 2.0? Should I try updating (experimental branches of) my projects to diesel git master too see what works?
    Georg Semmler
    @weiznich
    The largest missing piece for a 2.0 prerelease is updating/improving our documentation. With diesel-rs/diesel#2996 there is already a WIP PR for that, but that requires some time from my side to fix some outstanding issue. What you all can do there is going over the linked documentation and try spotting issue or misscategorized items.
    After that I will likely try to cut a rc-release, that's the point where we would be interested in people trying out the new release.
    Starting from there we would try to address any unexpected issues coming up there + updating the guides on the webpage + writing an migration guide. Help there would be definitively welcome.
    Rasmus Kaj
    @kaj:stacken.kth.se
    [m]
    👍
    Сергей
    @MvSergey_twitter

    That's because IN expects one bind per element in your vector.

    could you explain how to do it with sql_query("SQL") ?

    Georg Semmler
    @weiznich
    You would need to construct a query that contains a bind per element in your vector. After that you would need to call bind for each element in your vector. As I've already written above: It's not possible with any released diesel version yet, those do not support a variable number of bind parameters yet.
    Сергей
    @MvSergey_twitter

    You would need to construct a query that contains a bind per element in your vector. After that you would need to call bind for each element in your vector. As I've already written above: It's not possible with any released diesel version yet, those do not support a variable number of bind parameters yet.

    What kind of wrap I should use, to wrap strings from vector and which method of SqlQuery can append this wrapped value into query?

    Georg Semmler
    @weiznich
    What part of: That's not possible using any released diesel version did you miss?
    (Or better: Use the dsl for such use cases, that's much easier.)
    Сергей
    @MvSergey_twitter
    DSL hasn't functionality
    In my case, I have hard SQL queries based on join lateral
    Georg Semmler
    @weiznich
    Ok, in that case you have the option to extend the dsl on your own (which is definitively not a topic for beginner, and no I won't give any other examples as given in the guide).
    Сергей
    @MvSergey_twitter
    Ohh, where is my holy Hibernate..
    Georg Semmler
    @weiznich
    Or you're fine with using a version based on the unreleased master branch, which allows a variable number of binds via boxing SqlQuery. See https://docs.diesel.rs/master/diesel/query_builder/struct.SqlQuery.html#method.into_boxed for that method (again no example, as this is not released yet)
    BTW: Nobody forces you to use diesel, I will likly just stop to answer now. Have better things to do than reading your complaints and reiterating stuff that's writing the documentation multiple times.
    Georg Semmler
    @weiznich
    @MvSergey_twitter That won't work as sql does not provide the correct type to be used inside of a inner_join.
    You could either implement a fully custom query ast (see the extending diesel guide about pagination for general details)
    Or you could try to change your query, by for example using = ANY($1) instead of IN($1, … $n) to have a fixed amount of binds.
    Jeffery Utter
    @jeffutter
    I've got a query using the sql_query macro and some .bind methods. It seems fairly slow and doesn't seem to be using a prepared statement (I'm running postgres with log_statements = 'all'). Is that expected or am I missing something to use prepared statements?
    It also seems to run select 1 before every query. Is that also expected?
    Rasmus Kaj
    @kaj:stacken.kth.se
    [m]
    For the select 1; are you using r2d2? I think it defaults to testing each connection before letting the caller borrow it, but that can be turned off using the pool builder.
    Rasmus Kaj
    @kaj:stacken.kth.se
    [m]
    Pool::builder().test_on_check_out(false).build(manager)
    Georg Semmler
    @weiznich
    Yes, the select 1 is coming from the r2d2 pool and is used to check if connections are still alive. It's currently just using a plain query for that, but it might be useful to cache the corresponding statement. The corresponding code is here: https://github.com/diesel-rs/diesel/blob/0e49ce0e22803c3b8f4141e4abe10d8b73a2c31f/diesel/src/pg/connection/mod.rs#L181 (similar location for the other connection implementations). Pr's improving that are welcome.
    About sql_query: That uses prepared statements internally, but we don't cache them as it's not meaningful for some possible "queries" to be cached at all (Think of statements altering the schema, or other similar things). What we may want to do is introducing an API that marks a SqlQuery as safe to cache, by letting the user call a corresponding function. Again that's something I'm open for contributions, but that's not on my priority list yet.
    Jeffery Utter
    @jeffutter

    Ahh, thanks for the details about the select 1. I'll try turning that off.

    So, currently, there's no way to have cached prepared statements with sql_query, right?

    Georg Semmler
    @weiznich
    Yes, that's correct.
    Jeffery Utter
    @jeffutter
    Another question (which is why I'm using sql_query in the first place) : I have a database with incorrect schema that I can't change. Ex: cars.id is int and passengers.car_id is bigint. When I try to join them I have issues. If I change the type in the model for cars.id to i64 (rather than i32) I get errors about not receiving enough bytes. Is there any way to work around this?
    Georg Semmler
    @weiznich
    So you issue is especially about joining?
    Jeffery Utter
    @jeffutter
    Yeah, I'm trying to roll back my sql_query approach to find the query builder code that had the issue so I can get the exact error
    Georg Semmler
    @weiznich
    If that turns out to be the issue: You can use constructs like this: https://github.com/diesel-rs/diesel/blob/1.4.x/diesel/src/expression/coerce.rs to "cast" sql side types of expressions. That's not public API of diesel, but the same code should work fine in a third party crate (modulo the imports…)
    Jeffery Utter
    @jeffutter
    I think the first error I ran into was with joinable:
    58 | joinable!(passengers  -> cars (car_id));
       | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `Integer`, found struct `BigInt`
    Georg Semmler
    @weiznich
    Yes that won't work. You need to use an explicit .on() clause in your case instead using the joinable! macro.
    Jeffery Utter
    @jeffutter
    I'll try that

    Now i've got:

    error[E0271]: type mismatch resolving `<diesel::expression::nullable::Nullable<schema::cars::columns::id> as diesel::Expression>::SqlType == diesel::sql_types::Nullable<BigInt>`
       --> data/src/lib.rs:101:22
        |
    101 |                     .eq(schema::cars::dsl::id.nullable())),
        |                      ^^ expected struct `Integer`, found struct `BigInt`
        |
        = note: expected struct `diesel::sql_types::Nullable<Integer>`
                   found struct `diesel::sql_types::Nullable<BigInt>`

    So this is where the coercion thing you linked comes in?

    Georg Semmler
    @weiznich
    Yes
    Occuros
    @Occuros
    Greetings, I just started using rust/diesel, and was wondering if its possible to have multiple migration variations to support different database backends (like postgres, mysql, sqllite)
    Georg Semmler
    @weiznich
    Yes that's supported, by just having different migration directories for different backends. After this you just set the right dir via the corresponding command line flag.
    Occuros
    @Occuros
    Thank you @weiznich