Is there any way to Improve readability of HasQuery base_query?

[dfego]

Backend

PostgreSQL

Diesel version

2.3.7

Diesel Features

chrono postgres

Operating System Version

Arch Linux

Third party libraries

No response

What do you want to do?

I want to use HasQuery as recommended by the documentation. Because I ultimately want to extract my query into a struct, this seems to make sense to me. The expression I want to select involves multiple joins, which all gets put into the base_query attribute line above the struct, which gets fairly unwieldy. When I tried to extract the expression into a const, I can't do that because the underlying functions to do so aren't const.

I use rustfmt to format my code, but it doesn't touch what's inside of these macros, so I can technically format it however I'd like. My question is: is there a way to extract this to something neater, or do I just build it and format it manually? I have no issue with that being the answer, I just want to make sure I'm not missing anything important here!

Compile time error

No response

What code do you already have?

This is what it looks like (the struct isn't using fields from all the joins, it's just to illustrate).

#[derive(HasQuery)]
#[diesel(base_query = pieces::table.inner_join(piece_status_types::table).left_join(piece_creation_dates::table).left_join(piece_dimensions::table))]
#[diesel(table_name = pieces)]
#[diesel(check_for_backend(diesel::pg::Pg))]
pub struct PieceWithStatus {
    pub id: i64,
    pub title: String,
    #[diesel(select_expression = piece_status_types::title)]
    pub status: String,
}


I can manually make it look like this:

```rust
#[derive(HasQuery)]
#[diesel(base_query = pieces::table
    .inner_join(piece_status_types::table)
    .left_join(piece_creation_dates::table)
    .left_join(piece_dimensions::table))]
#[diesel(table_name = pieces)]
#[diesel(check_for_backend(diesel::pg::Pg))]
pub struct PieceWithStatus {
    pub id: i64,
    pub title: String,
    #[diesel(select_expression = piece_status_types::title)]
    pub status: String,
}

### Additional details

_No response_

### Checklist

- [X] I have already looked over the [issue tracker](https://github.com/diesel-rs/diesel/issues) and the [discussion forum](https://github.com/diesel-rs/diesel/discussions) for similar possible closed issues.

[weiznich]

The likely best solution here is to put your query into a separate function + use #[diesel::dsl::auto_type] there.

This would look like this here:

#[diesel::dsl::auto_type]
fn piece_with_status_base_query() -> _ {
    pieces::table
        .inner_join(piece_status_types::table)
        .left_join(piece_creation_dates::table)
        .left_join(piece_dimensions::table
}

#[derive(HasQuery)]
#[diesel(base_query = piece_with_status_base_query()))]
#[diesel(table_name = pieces)]
#[diesel(check_for_backend(diesel::pg::Pg))]
pub struct PieceWithStatus {
    pub id: i64,
    pub title: String,
    #[diesel(select_expression = piece_status_types::title)]
    pub status: String,
}

In that way rustfmt will just format that function as a normal rust function and the attribute is short enough to not cause any issues. Otherwise I believe it would be still good if rustfmt actually tried to format that attribute, although that's an issue that needs to be reported at their issue tracker.

It would be great to mention that somewhere in our documentation. Would you be open to submit a PR for that?

[dfego]

Thank you! Yeah, I'll be happy to make an addition to the docs. Do you want something in the Rust docs, website, or both?

If the Rust docs, I think it would go under HasQuery documentation. For the website, I would imagine it would go in the All About Selects page?

I'll note all the pieces for me to know how to do that were in the documentation, I just hadn't put them together. I got as far as trying a function like you did above, but got hung up on the return type and forgot about auto_type.

[weiznich]

I think both the api docs about HasQuery and the "All about selects" guide are good places to mention this. Generally its often a good idea to just add things where you would have looked for them. It's often easier for you as user to have a feeling like "I would have expected that information here or there" then for me as maintainer. I tend to just know where things belong to, which makes is hard to be sure where people will look for this.