No quantifier design

[Virgiel]

Currently, every query has to declare a quantifier but we could do without it. The idea is for queries to return a query struct that defer execution.

This code:

--! authors()
SELECT * FROM Author;

Generate this function:

pub fn authors<'a, C: GenericClient>(client: &'a C) -> Query<'a, C, (i32, String, String)> {
    Query {
        query: "SELECT * FROM Author;",
        client,
        params: &[],
        mapper: |res| {
            let return_value_0: i32 = res.get(0);
            let return_value_1: String = res.get(1);
            let return_value_2: String = res.get(2);
            (return_value_0, return_value_1, return_value_2)
        },
    }
}

With this client code:

pub struct Query<'a, C: GenericClient, T> {
    query: &'static str,
    client: &'a C,
    params: &'a [&'a (dyn tokio_postgres::types::ToSql + Sync)],
    mapper: fn(Row) -> T,
}

impl<'a, C, T: 'static> Query<'a, C, T>
where
    C: GenericClient,
{
    pub async fn stmt(&self) -> Result<Statement, Error> {
        self.client.prepare(self.query).await
    }

    pub async fn one(self) -> Result<T, Error> {
        let stmt = self.stmt().await?;
        let row = self.client.query_one(&stmt, self.params).await?;
        Ok((self.mapper)(row))
    }

    pub async fn opt(self) -> Result<Option<T>, Error> {
        let stmt = self.stmt().await?;
        Ok(self
            .client
            .query_opt(&stmt, self.params)
            .await?
            .map(self.mapper))
    }

    pub async fn list(self) -> Result<Vec<T>, Error> {
        self.raw().await?.try_collect().await
    }

    pub async fn raw(self) -> Result<impl Stream<Item = Result<T, Error>>, Error> {
        let stmt = self.stmt().await?;
        let stream = self
            .client
            .query_raw(&stmt, slice_iter(self.params))
            .await?
            .map(move |res| res.map(self.mapper));
        Ok(stream.into_stream())
    }
}

// https://github.com/sfackler/rust-postgres/blob/765395f288861209a644c621bf72172acd482515/tokio-postgres/src/lib.rs
fn slice_iter<'a>(
    s: &'a [&'a (dyn ToSql + Sync)],
) -> impl ExactSizeIterator<Item = &'a dyn ToSql> + 'a {
    s.iter().map(|s| *s as _)
}

Used like that:

pub async fn usage<T: GenericClient>(client: &T) -> Result<(), CustomError> {
    let one = authors(client).one().await?;
    let opt: Option<_> = authors(client).opt().await?;
    let list: Vec<_> = authors(client).list().await?;
    let custom: Vec<usize> = authors(client)
        .raw()
        .await?
        .map(|row| row.map(|(a, b, c)| a as usize + b.len() + c.len()))
        .try_collect()
        .await?;
    Ok(())
}

Advantages

• Smaller API
• Less complexity in the code generator
• Reuse of queries for different usage

Drawbacks

• More verbosity when using queries
• Do we really often reuse the same query to return one, many, optional or mapped rows?

Conclusion

I am not convinced that this is better, which is why I opened a discussion and not an issue. Do you find this solution better? Do you have any ideas to improve it?

[LouisGariepy]

Hi @Virgiel, thanks for your contribution 😄 🚀. I like the implementation (struct-per-query), and also the fact that it'd simplify the codegen, but I'm not sure if it's worth it.

My reasoning is that for most intents and purposes, your SQL already determines the number of rows to be returned. If I have to specify a quantifier, I'd rather do it once in an annotation near the query, rather than at each call site. Ultimately my concern is to keep the boilerplate at a minimum.

Personally I never felt the need to be generic over the number of returned rows, but if this is a problem for you (or anyone else), I'd like to know. I'll keep the discussion open because I'd like to see if other users have opinions on this.

[LouisGariepy]

@Virgiel If we go forward with your proposal, I think I'd go with an implementation in the vein of the original post.

I thought a bit more about the boilerplate aspect, and I now realize that most users will probably only call the query in a small number of places (most likely once in a web server handler or something). So adding .one() once or twice maybe is not a big deal. It is a significant breaking change though, so I'll probably have to add a changelog or a migration guide for existing users.

With regards to how this proposal improves the internals, and the potential integration with https://github.com/LouisGariepy/cornucopia/issues/41, I think I might go forward with it. Not committed to anything yet, but I will test this proposal together with the other issue and decide with how that goes. It's quite a significant refactor though, so I'll probably a bit of time to implement everything :)

Cheers, and thanks again for all your contributions, sound stuff.

[Virgiel]

I started experimenting with it in my fork. There are some good and some bad. The good part is that it works and simplifies codegen and SQL files. The bad part is that I had to use const generic to prevent allocation, and we need double references for borrowing parameters such as &&str and &&[u8].

[LouisGariepy]

@Virgiel 👍 Took a look at your fork, I'll take inspiration from it, thanks! I'll be going for a "deeper" refactor to really set Cornucopia for the future, but its a solid groundwork.

had to use const generics...

That is A-OK in my book. After all, they are a nifty feature of Rust, and the MSRV for this crate allows it.

we need double references for borrowing parameters such as &&str and &&[u8]

will have to experiment with it, but its not a deal-breaker in any case.

[LouisGariepy]

@Virgiel By the way, I'm going to open the project to contributions as soon as the interface and internals have somewhat stabilized. I believe you're familiar enough with the codebase, so when that happens, I'd like to add you as a contributor. Is that something you'd be interested in?

[Virgiel]

@LouisGariepy I am looking forward to this redesign. I would be interested in being a contributor to this project!
After using SQLDelight in an Android application, I was eager to find something similar for Rust. After not finding any, I never dared to start anything. Thank you for writing this library!