Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    David Harrington
    @harringtondavid_twitter
    Error -- sslmode value "require" invalid when SSL support is not compiled in". Connecting to postgres 12 on google cloud. Any suggestions?
    James Kerr
    @disconsented
    Hey @weiznich sorry to bother you, but I am working on tests for PR #1846. Looking around the rest of the tests inside the workspace they seem focused (for lack of a better term). Do you have any objections with me breaking the mould and setting up an in memory sqlite database to run tests against?
    Georg Semmler
    @weiznich
    @harringtondavid_twitter Diesel accepts a valid libpq connection url. See their (Section 33.1.1) for details. I would guess that there is somewhere an example in the google cloud documentation how to connect via libpq.
    @disconsented As already mentioned there: I think a much better solution would be to make the ALL_MIGRATIONS constant part of the public API and move such a functionality to diesel_migrations itself.
    Erlend Langseth
    @Ploppz
    why can I not select non-aggregate and aggregate columns in the same select?
    ^^^^ the trait `NonAggregate` is not implemented for `aggregate_ordering::max::max<diesel::sql_types::Integer, step_idx>`
    Full query:
                m::measurement
                    .inner_join(p::plate.on(m::plate_id.eq(p::id)))
                    .inner_join(e::experiment.on(e::id.eq(p::experiment_id)))
                    .inner_join(pr::project.on(pr::id.eq(e::project_id)))
                    .inner_join(pj::pipeline_job.on(pj::measurement_id.eq(m::id)))
                    .inner_join(wj::worker_job.on(wj::id.eq(pj::job_id)))
                    .filter(wj::status.eq("Done"))
                    .select((
                        pr::default_pipeline_id,
                        e::default_pipeline_id,
                        p::default_pipeline_id,
                        max(pj::step_idx)
                    ))
                    .load::<(Option<i64>, Option<i64>, Option<i64>, i32)>(&conn)
    Georg Semmler
    @weiznich
    That's just something that is not supported on 1.4.5 yet.
    Erlend Langseth
    @Ploppz
    When will it be supported? And any ideas how I might get around this for now?
    Georg Semmler
    @weiznich
    Also I think that query misses a group by cause to do what you expect.
    Erlend Langseth
    @Ploppz
    hmm yeah you're right, need to group by m::id
    Georg Semmler
    @weiznich
    About "When will something be supported": We generally do not give any estimates when specific features are implemented.
    (Group by is the next thing that is not supported yet on any release, which is also the underlying reason why mixing aggregate and non aggregate clauses is not supported yet)
    Erlend Langseth
    @Ploppz
    Ah, ok
    Georg Semmler
    @weiznich
    Corresponding issues: diesel-rs/diesel#210 and #3
    Erlend Langseth
    @Ploppz
    Thanks.
    Is it within the scope of Diesel to support https://www.postgresqltutorial.com/postgresql-coalesce/ ?
    oh hm, I guess I should use sql_function for this
    Christopher Lee
    @Clee681
    Hello, I could use a little assistance resolving this compiler error:
    5 | #[derive(Insertable)]
      |          ^^^^^^^^^^ the trait `diesel::Expression` is not implemented for `std::string::String`
    This example (https://github.com/diesel-rs/diesel/blob/master/examples/postgres/all_about_inserts/src/lib.rs) does not seem to implement anything special for the use of String
    Georg Semmler
    @weiznich
    @Clee681 That's hard to answer without knowing your code. In general this indicates that you've some type mismatch between your schema and your strict.
    Christopher Lee
    @Clee681
    Ah, you're right. There was a type mismatch
    #[derive(Insertable)]
    #[table_name = "order_items"]
    pub struct NewOrderItem {
      pub order_num: i32,
      pub ts: chrono::NaiveDateTime,
      pub description: String,
      pub src_doc: String,
    }
    
    table! {
      order_items (id) {
          id -> Int4,
          order_num -> Int4,
          ts -> Timestamp,
          description -> Text,
          src_doc -> Jsonb,
      }
    }
    src_doc being different caused the compiler error
    If I remove the src_doc field, I just get an error for the Expression is not implemented for NaiveDateTime
    Is there any documentation or an example for how to implement that expression trait for chrono::NaiveDateTime and Jsonb?
    Christopher Lee
    @Clee681
    Re: the NaiveDateTime, diesel has a chrono feature :raised_hands:
    Christopher Lee
    @Clee681
    And looks like there's also a serde_json feature :raised_hands: http://docs.diesel.rs/diesel/pg/types/sql_types/struct.Jsonb.html
    Pavan Kumar Sunkara
    @pksunkara
    So, I found the root cause for default not being already implemented. It looks like sqlite doesn't support it.
    But Insertable code already compensates for it. So, all I have to do is implement what you suggested and then expression later on
    David Harrington
    @harringtondavid_twitter

    @harringtondavid_twitter Diesel accepts a valid libpq connection url. See their (Section 33.1.1) for details. I would guess that there is somewhere an example in the google cloud documentation how to connect via libpq.

    Thanks @weiznich. Is Diesel configured to support these file locations and/or the environment variables for SSL certificates?

    https://www.postgresql.org/docs/9.4/libpq-ssl.html
    "location of the certificate and key files can be overridden by the connection parameters sslcert and sslkey or the environment variables PGSSLCERT and PGSSLKEY"

    https://www.howtoforge.com/postgresql-ssl-certificates
    "On the client, we need three files. For Windows, these files must be in %appdata%\postgresql\ directory. For Linux ~/.postgresql/ directory.
    root.crt (trusted root certificate)
    postgresql.crt (client certificate)
    postgresql.key (private key)"

    Georg Semmler
    @weiznich
    @harringtondavid_twitter We just pass the connection string to libpq, so we do whatever libpq does internally.
    Erlend Langseth
    @Ploppz
    I have a problem adding a filter to a working diesel query, which makes it not compile anymore. The relevant filter, query and error: https://bpa.st/WFEA
    In short, I have a filter that is dyn BoxableExpression<pipeline::table, Pg, SqlType = diesel::sql_types::Bool> which I think would work if used on the pipeline table alone, but I guess it doesn't work now due to left joins, but why and how can I fix?
    Georg Semmler
    @weiznich
    By using the correct query source for your BoxableExpression. So instead of pipeline::table you need to use the type representing the join.
    Erlend Langseth
    @Ploppz
    How can I do that? The QS type parameter I guess corresponds to QuerySource which says that there are internal structs which represent joins
    Georg Semmler
    @weiznich
    @Ploppz I'm not sure if we already expose the necessary helper types via diesel::dsl. If not I'm happy to receive a PR adding those types.
    Erlend Langseth
    @Ploppz
    So (before I look into it) these types actually exist but are not exposed? There can't possible be one type for each combination of tables you want to join so how does it work?
    Georg Semmler
    @weiznich
    Those types definitively exist, but I'm not sure if they are exposed as part of the public API.
    I'm not sure what you want to know with your second question.
    Erlend Langseth
    @Ploppz
    Any hint where I can find that type?
    Georg Semmler
    @weiznich
    @Ploppz The module path is in your error message
    Erlend Langseth
    @Ploppz

    Hmm I see, the struct that needs to be exposed is JoinOn. So when defining QS for my BoxableExpression, do I understand correctly that that type is in fact

    JoinOn<diesel::query_source::joins::Join<JoinOn<diesel::query_source::joins::Join<common::db::schema::hci::pipeline::table, common::db::schema::hci::project::table, LeftOuter>, diesel::expression::operators::Eq<common::db::schema::hci::project::default_pipeline_id, diesel::expression::nullable::Nullable<common::db::schema::hci::pipeline::id>>>, common::db::schema::hci::experiment::table, LeftOuter>, diesel::expression::operators::Eq<common::db::schema::hci::experiment::default_pipeline_id, diesel::expression::nullable::Nullable<common::db::schema::hci::pipeline::id>>>

    that's a bit messy, I would hope the type would only consist of the tables in the join and not actually of the very details of the join

    Georg Semmler
    @weiznich
    That is basically what I mean by: We would need to export that via diesel::dsl. All types there are type defs which hide such details.
    Erlend Langseth
    @Ploppz
    Sorry, I don't see how we can somehow abstract away all those Eq<some column>, Nullable<some column> etc that are specific to the tables in my schema and exactly the join I'm doing in my code. If I got you correctly you are talking about exposing some Join struct under diesel::dsl which would allow me to construct a type where I only need to specify the tables?
    Erlend Langseth
    @Ploppz
    Hmm do you perhaps mean a new type diesel::dsl::Join<T> where we could let T be a tuple of tables, and then BoxableExpression<Join<T>, _> would implement AppearsOnTable<UnwieldyComplexJoinType> if the tables T corresponds to the tables in the complex join type? If that's possible... Or anything in that direction?
    Georg Semmler
    @weiznich
    Have a look at how that is done for diesel::dsl::InnerJoin
    (That type is for the complete query, not only for the query source part)
    Christopher Lee
    @Clee681
    Does diesel::insert_into batch inserts under the hood if you pass a large Vector? I think SQL Server limits the number of values in a single INSERT INTO to 1,000 tuples. I think Postgres is more lenient.
    Georg Semmler
    @weiznich
    If supported by the backend it will use a batch insert. If you pass in a to large vector (for postgres the limit is 2^16 binds) a runtime error will occur.
    Christopher Lee
    @Clee681
    Gotcha, so perhaps I should just do the batching to have more defined behavior
    use itertools::Itertools;
    
    fn main() {
        let v: Vec<i32> = (0..25).collect();
    
        for x in v.into_iter().chunks(5).into_iter() {
            diesel::insert_into(some_table).values(x).execute(conn)
        }
    }