Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Hoang Tran
    @hoangtranwork
    Ok, it’s indeed in the source code of r2d2, I mistake it with diesel-r2d2. Thank you.
    James Kerr
    @disconsented

    I am trying to recover from a migration that was killed as it was being run.
    (Sqlite)
    The issue I am running into now is that I cannot conditionally ALTER TABLE RENAME TO or I cannot swallow the errors from trying to do that.

    Any ideas on what I can do?

    2 replies
    EclipsedSolari
    @EclipsedSolari

    I'm trying to build a MySQL query like this:

    SELECT value_1, value_2
    FROM my_table
    WHERE ((value_1 = ? AND value_2 >= ?)
    OR (value_1 = ? AND value_2 IS NULL)
    OR (value_1 IS NULL AND value_2 >= ?))

    If I build it out in Diesel like this:

    let test_query = my_table.filter(value_1.eq(test_value_1).and(value_2.ge(test_value_2)))
            .or_filter(value_1.eq(test_value_2).and(value_2.is_null()))
            .or_filter(value_1.is_null().and(value_2.ge(test_value_2)));
    
    let debug_query = debug_query::<Mysql, _>(&test_query);
    println!("{:?}", debug_query);

    I get this (note the lack of parentheses around the first AND subclause):

    SELECT `my_table`.`id`, `my_table`.`value_1`, `my_table`.`value_2`
    FROM `my_table`
    WHERE ((`my_table`.`value_1` = ? AND `my_table`.`value_2` >= ? OR `my_table`.`value_1` = ? AND `my_table`.`value_2` IS NULL)
    OR `my_table`.`value_1` IS NULL AND `my_table`.`value_2` >= ?)

    It looks like filter/or_filter doesn't start wrapping subclauses in parentheses right away, but waits until there's an OR expression involved. Is there a way I can override or work around this behavior so all my OR subclauses are parentheses-wrapped? (I did consider starting with a sacrificial .filter(1.eq(&0)) or .filter(true.eq(&false)) clause, so the real subclauses could all go in .or_filter expressions, but it doesn't look like that's valid Diesel syntax.)

    Georg Semmler
    @weiznich
    @EclipsedSolari I think and has a higher priority that or in sql, so your query should be fine. Nerveless #2520 (will be part of the next release) automatically inserts the parentheses in the expected way here.
    William King
    @quentusrex
    Anyone know what should be done to work around an error trying to use the postgres inet type?
    error[E0277]: the trait bound `diesel::sql_types::Inet: diesel::Expression` is not satisfied
      --> src/models.rs:11:21
       |
    11 | #[derive(Queryable, Insertable)]
       |                     ^^^^^^^^^^ the trait `diesel::Expression` is not implemented for `diesel::sql_types::Inet`
       |
       = note: required because of the requirements on the impl of `diesel::Expression` for `&diesel::sql_types::Inet`
       = note: required because of the requirements on the impl of `AsExpression<diesel::sql_types::Nullable<diesel::sql_types::Inet>>` for `&diesel::sql_types::Inet`
       = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)
    I'm trying to understand why it's looking for the Expression trait instead of the AsExpression trait which is implemented here: https://docs.diesel.rs/src/diesel/pg/types/network_address.rs.html#33
    William King
    @quentusrex
    Found the issue: https://gitter.im/diesel-rs/diesel?at=5d9e23e03220922ffb5956d3
    Diesel uses ipnetwork 0.16.0 and my application had pulled in 0.17.0
    Mark Hildreth
    @markhildreth
    I have found some >1yr old issues/PRs about Diesel/R2D2 and correctly handling connections that shouldn't be put back into the pool because of things like a thread panicking while a connection is mid-transaction. diesel-rs/diesel#2020 has a note, "trying to fix this on the R2D2 side", but the comments in the PRs linked to on the R2D2 side (sfackler/r2d2#31 and sfackler/r2d2#70) seem to suggest that it's an issue that Diesel should resolve. Was there ever any resolution made on this?
    Georg Semmler
    @weiznich
    @quentusrex We would be happy to receive a PR increasing the supported version range.
    @markhildreth Seems like nobody worked on that any further. I would be definitively open to some fix there, as long as the already given constrains are considered.
    zonzepp
    @zonzepp

    Hi

    I am trying to run cargo install diesel_cli --no-default-features --features sqlite on windows 10

    error: failed to run custom build command for num-integer v0.1.44

    Caused by:
    process didn't exit successfully: C:\Users\user\AppData\Local\Temp\cargo-installJLtuy7\release\build\num-integer-72bce275e7f35cb2\build-script-build (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)
    --- stderr

    thread '<unknown>' has overflowed its stack
    warning: build failed, waiting for other jobs to finish...
    error: failed to compile diesel_cli v1.4.1, intermediate artifacts can be found at C:\Users\user\AppData\Local\Temp\cargo-installJLtuy7

    Caused by:
    build failed

    4 replies
    James Kerr
    @disconsented

    So here is a bit of a weird one that I'd appreciate some input on:

    • Migrations via the application I am working on can take 25 minutes plus.
    • Running those same migrations via my IDE or via diesel CLI it takes 7 seconds.
    • It specifically seems to be anything involving ALTER TABLE or DROP TABLE causing the issue.
    • ~= 100MB Sqlite database with customer data

    Reasonably fast machine:
    (i7-9750H, 16GB of RAM and w/ever SSD the MBP 2019 ships with)

    1 reply
    Johann Hemmann
    @Urhengulas

    I am using a global database connection pool:

    use diesel::{PgConnection, r2d2::{ConnectionManager, Pool}};
    use once_cell::sync::OnceCell;
    
    static DB: OnceCell<Pool<ConnectionManager<PgConnection>>> = OnceCell::new();

    This works perfectly for my application and is very convenient to access.

    I started to add some tests using #[tokio::test], which all should run against a fresh and separate dummy database. Here I hit a problem. All of the tests share the same global database connection, which makes sense if you think about it, but makes it impossible to run tests in parallel, cause they global connection will always be connected to one database.

    And here comes my question: Does anyone know a good way to work around this without sacrificing the global connection, cause it's very convenient in the application code?
    My first idea were test-local statics, but I couldn't find sth like that. Another idea was using #[cfg(test)]and #[cfg(not(test))] to replace the pool in the tests, but I couldn't find sth good.

    Appreciate any idea :D

    Georg Semmler
    @weiznich
    @Urhengulas I would probably just try to call Connection::begin_test_connection() for each connection on pool creation via the r2d2::CustomizeConnection trait.
    Generally speaking: I think a guide how to write tests involving diesel is certainly something that would be a welcome addition for our web page.
    Andrew Wheeler(Genusis)
    @genusistimelord
    so im having a issue selecting data into a Structure with diesel
    https://pastebin.run/2D72QmJrgG
    the error is at the bottom of the text there i included the many areas that might be the issue
    i am using diesel 1.45
    Johann Hemmann
    @Urhengulas

    @Urhengulas I would probably just try to call Connection::begin_test_connection() for each connection on pool creation via the r2d2::CustomizeConnection trait.
    Generally speaking: I think a guide how to write tests involving diesel is certainly something that would be a welcome addition for our web page.

    @weiznich Thanks. That sounds like an idea. If I come up with a good pattern I might send a description PR for the website :)

    Andrew Wheeler(Genusis)
    @genusistimelord
    Never mind i managed to figure out the issue. It is due to the Table Schema not having the variables in the same order as the struct OR the struct missing variables that exist within the table schema. Would be nice if it could use the struct to make the connection and mappings instead of the schema.
    Georg Semmler
    @weiznich
    @genusistimelord Can you describe a bit more in detail what you exactly mean by "Would be nice if it could use the struct to make the connection and mappings instead of the schema."?
    Erlend Langseth
    @Ploppz
                p::plate
                    .select(m::measurement.select(count_star()).filter(m::plate_id.eq(p::id)))
                    .load::<i64>(&conn)
    is this supported? I get some errors https://bpa.st/YP3A
    2 replies
    btw this is only the start of a query, I would still inner join plate with other tables and select several more columns
    Andrew Wheeler(Genusis)
    @genusistimelord
    Well what i mean @weiznich is instead of having to use the schema like this example
    diesel::table! {
        use crate::gametypes;
        use diesel::sql_types::*;
        players (uid) {
            uid -> BigInt,
            name -> Text,
            address -> Text,
            pos -> gametypes::PosType,
            vital -> Array<Integer>,
            indeath -> Bool,
        }
    }
    
    #[derive(Debug, PartialEq, Queryable, Insertable, Associations, Identifiable)]
    #[table_name = "players"]
    #[primary_key(uid)]
    pub struct PGPlayerWithID {
        uid: i64,
        name: String,
        address: String,
        pos: Position,
        vital: Vec<i32>,
        indeath: bool,
    }
    
    let pgplayer = players::table.filter(players::uid.eq(user.accid)).first::<PGPlayerWithID>(conn)?;
    that you could either have it map the table Select based on the components in the structure and use the structure directly to do the SQL Query. like this.
    diesel::table! {
        use crate::gametypes;
        use diesel::sql_types::*;
        players (uid) {
            uid -> BigInt,
            name -> Text,
            address -> Text,
            pos -> gametypes::PosType,
            vital -> Array<Integer>,
            indeath -> Bool,
        }
    }
    
    #[derive(Debug, PartialEq, Queryable, Insertable, Associations, Identifiable)]
    #[table_name = "players"]
    #[primary_key(uid)]
    pub struct PGPlayerWithID {
        uid: i64,
        name: String,
    }
    
    let pgplayer = PGPlayerWithID::select.filter(players::uid.eq(user.accid)).first::<PGPlayerWithID>(conn)?;
    Andrew Wheeler(Genusis)
    @genusistimelord
    which would be similar to
    players::table.select((players.uid, players.name)).filter(players::uid.eq(user.accid)).first::<PGPlayerWithID>(conn)?;
    Georg Semmler
    @weiznich
    @genusistimelord How would you support more complex select clauses in your example? It's important to support queries that do not only "just" select some fields as part of the select clause, but have more complex expressions there. For example such queries as in the example above your current post. (There is #2367 which implements something like that, but that's nothing that's on top of my priority list.)
    Andrew Wheeler(Genusis)
    @genusistimelord
    Yeah i was mostly just offering my Idea's on this. The main thing would be to support a single Schema with additional structs that could return different amounts of data based on the struct compared to the schema. for more advanced i would still recommend using the schema directly. just thinking of this as writing less code for a large project.
    but its not important.
    Georg Semmler
    @weiznich
    That shouldn't mean that this wouldn't be something that can be useful for anyone. I'm just not sure if this should be really part of diesel itself, or should there be some kind of "high-level" crate that uses diesel internally and provides an interface that matches more classical ORM 's. If someone steps up to write such an crate I would definitively try to over some advice and help for implementation there.
    Andrew Wheeler(Genusis)
    @genusistimelord
    @weiznich I would step up but I lack experience in Rust macros. I find them very hard to use right now as i really don't fully understand them.
    Georg Semmler
    @weiznich
    I think you doesn't need that much macros for such a project. More likely that you need to define a whole lot of traits and write some generic code + maybe one or two "simple" derive macros (but they are really simple, just take some rust code and generate some rust code, that's not any more complex than writing normal rust code)
    I think the more complex part is to decide how the "public" API of such a crate should look like and how to avoid common ORM problems like N+1 queries in such an API.
    I think @pksunkara Is working on something like that as well, so maybe you could ask them on their approach and join forces there?
    Andrew Wheeler(Genusis)
    @genusistimelord
    the n+1 issue is very hard to avoid XD
    Georg Semmler
    @weiznich
    At least diesel provides some API's that allow you to write queries without running in such issues. (See diesel::associations for example :wink:)
    Andrew Wheeler(Genusis)
    @genusistimelord
    I think maybe for something like this rather that relying on a full blown query hierarchy it be better to just add a derive that builds a players::table.select((players.uid, players.name)) that the end user could simply just use the rest of regular diesel along with it
    so you could do
    PGPlayerWithID::select() and the rest would be regular diesel commands
    Georg Semmler
    @weiznich
    For that see #2367. As written before: It's not a priority for myself, but I would be happy to accept a complete PR there.
    Andrew Wheeler(Genusis)
    @genusistimelord
    @weiznich Looking over that PR and i don't see anything wrong with why it hasn't been pushed yet?
    Georg Semmler
    @weiznich
    Because the CI is failing and something seems to be wrong with some type mapping there. As written there: I do currently not have the time or capacity to work on that. So if someone figures out what's wrong I will try to find some time to do a final review.
    Andrew Wheeler(Genusis)
    @genusistimelord
    ok i can probably look into it and see.
    Pavan Kumar Sunkara
    @pksunkara

    I think maybe for something like this rather that relying on a full blown query hierarchy it be better to just add a derive that builds a players::table.select((players.uid, players.name)) that the end user could simply just use the rest of regular diesel along with it

    I have actually finished implementing support for the above in my ORM lib (on top of diesel) using rust macros. I am currently working on solving this issue for INSERT and UPDATE. And then will move on to associations (I have a vague idea on how to solve the n+1 problem)

    Andrew Wheeler(Genusis)
    @genusistimelord
    @pksunkara have you posted this anywhere yet?
    Pavan Kumar Sunkara
    @pksunkara
    It uses diesel master
    Andrew Wheeler(Genusis)
    @genusistimelord
    looks really clean.
    1 reply
    Shao Chenyang
    @tzsword
    how to re-export diesel macros in workspace crate?
    Shao Chenyang
    @tzsword
    I implemented paging in the utils workspace, so I want to export diesel in utils to avoid version conflicts.
    The current solution is to add diesel to the dependencies in each workspace used