Most-generic way to refer to AsyncConnection

[shutton]

This is likely more of a Rust typing question than a diesel-async question, but I think it's probably worth covering here.

I've been struggling with coming up with a way to wrap queries that take a connection handle, whether obtained directly or from a pool. The goal is to continue to use a [generic] handle without passing a pool handle (or even requiring a pool) into the wrapper function.

Here's a code sample that demonstrates the most generic way I was able to do this. I still end up having to refer to the database backend in the functions, and the problem I'm trying to solve (mostly out of principle, since I don't really want to use other databases) is how to not refer to the backend.

This is a complete example (I included the schema/model so that it will compile, even though it won't run without extra effort).

use deadpool::managed::Object;
use diesel::{pg::Pg, prelude::*};
use diesel_async::{
    pooled_connection::AsyncDieselConnectionManager, AsyncConnection, AsyncPgConnection,
    RunQueryDsl,
};

table! {
    demotable {
        id -> Integer
    }
}

#[derive(Debug, Queryable, Selectable, Identifiable)]
#[diesel(table_name = demotable)]
struct DemoTableRecord {
    id: i32,
}

const DBURL: &str = "postgres://postgres@localhost/template1";

type MyPool = diesel_async::pooled_connection::deadpool::Pool<AsyncPgConnection>;

async fn build_pool() -> MyPool {
    let manager = AsyncDieselConnectionManager::<AsyncPgConnection>::new(DBURL);
    deadpool::managed::Pool::builder(manager)
        .build()
        .expect("build pool")
}

async fn simple_cxn() -> AsyncPgConnection {
    AsyncPgConnection::establish(DBURL)
        .await
        .expect("connect to dbms")
}

async fn do_query_less_generic(cxn: &mut AsyncPgConnection, id: i32) {
    let result = demotable::table;
    let result = result
        .find(id)
        .select(DemoTableRecord::as_select())
        .first::<DemoTableRecord>(cxn)
        .await
        .expect("query");
    eprintln!("{result:?}")
}

async fn do_query_generic<'conn, Conn>(cxn: &mut Conn, id: i32)
where
    Conn: AsyncConnection<Backend = Pg>,
{
    let result = demotable::table;
    let result = result
        .find(id)
        .select(DemoTableRecord::as_select())
        .first::<DemoTableRecord>(cxn)
        .await
        .expect("query");
    eprintln!("{result:?}")
}

#[tokio::main]
async fn main() {
    try_cxn().await;
    try_pool().await;
}

async fn try_pool() {
    let pool = build_pool().await;

    let mut cxn: Object<AsyncDieselConnectionManager<AsyncPgConnection>> =
        pool.get().await.expect("get connection");
    do_query_generic(&mut *cxn, 1).await;
}

async fn try_cxn() {
    let mut cxn = simple_cxn().await;
    do_query_generic(&mut cxn, 1).await;
    do_query_less_generic(&mut cxn, 1).await;
}

So, the question there is: how does one write do_query_generic() there, referencing a generic backend?

[weiznich]

There is no need to use a generic parameter there, as all of the pooled connection types implement DerefMut. That means you can just use something like that:

async fn do_query_generic(cxn: &mut AsyncPgConnection, id: i32) {}

let mut cxn: Object<AsyncDieselConnectionManager<AsyncPgConnection>> =
        pool.get().await.expect("get connection");
    do_query_generic(&mut *cxn, 1).await;

Otherwise it's a choice between either referring to the backend type or specifying a whole bunch of query specific trait bounds so that rustc can proof that you can call that function for all possible backends. (The later one is complicated and should be avoided)

[shutton]

Oh, the reason I'd gone generic for Conn was to get around having to specify either &mut *cxn for a connection obtained from a pool, or &mut cxn for a "bare" one. I realize I accidentally left'conn in there from earlier experimentation.

Again, that's mainly to keep the caller from having to figure out whether cxn needs to be dereferenced.

[shutton]

Understood (and I had that much working using AsyncPgConnection). But I was curious about how to create the function "for all possible backends" (even if it's pretty ugly).

The use case I'm considering is migration projects, where one is trying to seamlessly transition from one database backend to another while preserving an API that has a number of helper functions that perform simple filters on queries, or a light transform on a key type before performing the query.

For my specific case, I'm looking at a Mysql-to-Postgres migration project, so it seems relevant (and interesting!).

[weiznich]

Even for such a use-case I wouldn't go for a generic approach there as that really requires a lot of generic trait bounds (for that example something like 5 relatively complex bounds). I think the better approach there is to provide something like #[derive(MultiConnection)] for async connections as well. That's not simple to implement as well, but it wraps the complexity at a single location.