query! that scale on a real application, idiomatic approach?

[kimbuba]

Hello, i've been spending quite time in trying to make basic examples to work, quite unsuccessfully (I'm a seasoned programmer but rust n00b).

I was able to make query_as! macro to work in a 1:1 relation.
Unfortunately because of #1031 it won't scale as it is necessary to have most of my structs to implement Type in order to be useful.

For example

#[derive(Debug, Type)]
pub struct House {
    pub id: i64,
    pub address: Address,
}

#[derive(Debug, Type)]
pub struct Address {
    pub id: i64,
}

gives

implementation of sqlx::Decode is not general enough

That requires me to go to query! macro approach instead.

For example

let row = query!(
        r#"
            SELECT
                home.id AS "home_id",
                
                address.id AS "address_id",
                
            FROM home
            JOIN address ON home.address_id = address.id
            WHERE home.id = $1
    "#,
        home_id
    )
    .fetch_optional(pool)
    .await?;

    let result = row.map(|e| Home {
        id: e.home_id,
        address: Some(Address {
            id: e.address_id,
        }),
    });

So far so good, however if i have more than 1 query to avoid lots of code duplication i want to:

1. Reuse the row.map between queries. Since it is an anonymous record, there is no type i can use and pass to functions. So the only way i know is to use my own macros to reuse code mapping.
2. Reuse query parts between queries. For example SELECT address.* code should come from another select in the address query mod. Because of "expected string literal" from the macro, i cannot format the macro and pass select fragments. (Prob there is a way to do this as it is all static code, but i cannot find how).
3. Conditional queries. To avoid to create 10 different query functions because of orderby permutations i will need to dynamically generate queries as it has been done here for query_as sqlx-conditional-queries. This actually would solve point 2 as well but afaik this is not for the query macro only

Workaround

1. use the query() function (as i'm doing now) and forget about compile time verification (the big plus of this library, imo).
2. make sqlx-conditional-queries to work forquery!`

I think every project more than a trivial TODO application will encounter pretty early the issues i mentioned above.
I'm sure you guys know a more idiomatic approach to this?

Note: i considered using tokio-postgres instead, but found out sqlx to be 30% faster in a stress test.