Passing diesel_async to tonic service - the trait bound is not satisfied

[mpiorowski]

So as the title said, i am trying to pass the pool create using diesel_async and deadpool to the service, but i got an error:

The funny thing is, that if i change the type to the deadpool ones, everything works, but that require me to install deadpool crate separately.

pub struct MyService {
    // pool: diesel_async::pooled_connection::deadpool::Pool<
    //     diesel_async::pooled_connection::AsyncDieselConnectionManager<
    //         diesel_async::AsyncPgConnection,
    //     >,
    // >,
    pool: deadpool::managed::Pool<
        diesel_async::pooled_connection::AsyncDieselConnectionManager<
            diesel_async::AsyncPgConnection,
        >,
    >,
}

Link to working example:
https://github.com/mpiorowski/rusve/blob/diesel/service-notes/src/main.rs

Overview of the whole main.rs:

mod models;
mod notes_service;
mod proto;
mod schema;

use anyhow::{Context, Result};
use proto::notes_service_server::NotesServiceServer;
use rusve_notes::establish_connection;
use tonic::transport::Server;

pub struct MyService {
    // pool: diesel_async::pooled_connection::deadpool::Pool<
    //     diesel_async::pooled_connection::AsyncDieselConnectionManager<
    //         diesel_async::AsyncPgConnection,
    //     >,
    // >,
    pool: deadpool::managed::Pool<
        diesel_async::pooled_connection::AsyncDieselConnectionManager<
            diesel_async::AsyncPgConnection,
        >,
    >,
}

#[tokio::main]
async fn main() -> Result<()> {
    println!("Starting server...");

    let port = std::env::var("PORT").context("PORT not set")?;
    let database_url = std::env::var("DATABASE_URL").context("DATABASE_URL not set")?;

    // Create a connection pool without tls
    let pool = establish_connection(&database_url)?;

    // Create a connection pool with tls
    // let mgr = AsyncDieselConnectionManager::<AsyncPgConnection>::new_with_setup(
    //     database_url,
    //     establish_connection_tls,
    // );
    // let pool = diesel_async::pooled_connection::deadpool::Pool::builder(mgr).build()?;

    let addr = ("[::]:".to_owned() + &port).parse()?;
    println!("Server started on port: {}", port);

    let server = MyService { pool };
    let svc = NotesServiceServer::new(server);
    Server::builder().add_service(svc).serve(addr).await?;

    Ok(())
}

[weiznich]

Well there is not much to say here other than that the types obviously need to match. If the compiler complains about some type mismatch you managed to mix things up by for example:

• Using an incompatible deadpool version
• Mixing deadpool::Pool and diesel_async::poolable_connection::deadpool::Pool (these are not the same, as explicit shown in the documentation and as it should be generated for crates implementing poolable support via deadpool)

[mpiorowski]

Firs of all wanted to thank You for Your work, i tried every sql solution for rust, and Yours the best ;)

So i am not an expert in Rust, trying to understand all the concepts. So here my question is, does it mean that i need to install deadpool crate separately and use its type?

The thing is that i cannot use the diesel_async Pool in any struct, nowhere, cos it will always throw the same error. Is that correct or am i missing something?

pub struct AnyStruct {
    pool: diesel_async::pooled_connection::deadpool::Pool<
        diesel_async::pooled_connection::AsyncDieselConnectionManager<
            diesel_async::AsyncPgConnection,
        >,
    >,
}

Thank for the help @weiznich .

[weiznich]

To repeat what I've written above again:

diesel_async::pooled_connection::deadpool::Pool and deadpool::Pool are differente incompatible types. You cannot use the in exactly the same position. By looking at the documentation of the diesel_async provided type you can see that this type is a custom type def of the deadpool type with some changes. Most importantly it already includes the AsyncConnectionManager part, so if you include that again if you use that type it is expected that it produces compiler error.

[mpiorowski]

@weiznich Yes, that one additional already included type was my problem. Thanks again for the help :)