Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify type of diesel::row::NamedRow::get in QueryableByName macro. #4132

Merged

Conversation

fiadliel
Copy link
Contributor

Resolves #4131

diesel::row::NamedRow::get has the signature

fn get<ST, T>(&self, column_name: &str) -> Result<T>
where
    T: FromSql<ST, DB>

This can be inferred from the resulting value, if there is only one ST type in scope for FromSql<ST, DB>.

But if multiple types are in scope, e.g.

impl<__DB: diesel::backend::Backend> QueryableByName<__DB>
for StructWithTextAndCitext
where
    String: diesel::deserialize::FromSql<sql_types::Text, __DB>,
    String: diesel::deserialize::FromSql<sql_types::Citext, __DB>,
{

then ST cannot be inferred.

@fiadliel fiadliel force-pushed the same_rust_type_multiple_db_types branch from be82672 to 30a5d33 Compare July 26, 2024 09:34
@fiadliel fiadliel marked this pull request as draft July 26, 2024 09:47
@fiadliel
Copy link
Contributor Author

This looks like an issue, I'll look into it a bit more:

select_expression = (users::id + 45),
                    ^^^^^^^^^^^^^^^^ expected `id`, found `Add<id, Bound<Integer, i32>>

@weiznich
Copy link
Member

weiznich commented Jul 26, 2024

That's related to the rust release yesterday. See https://github.com/diesel-rs/diesel/pull/4130/files for the fixes for CI.

Otherwise I would appreciate an added test for this case.

This has the signature
```
fn get<ST, T>(&self, column_name: &str) -> Result<T>
where
    T: FromSql<ST, DB>
```

This can be inferred from the resulting value, if there is only one
`ST` type in scope for `FromSql<ST, DB>`.

But if multiple types are in scope, e.g. 
```
impl<__DB: diesel::backend::Backend> QueryableByName<__DB>
for StructWithTextAndCitext
where
    String: diesel::deserialize::FromSql<sql_types::Text, __DB>,
    String: diesel::deserialize::FromSql<sql_types::Citext, __DB>,
{
```

then `ST` cannot be inferred.
@fiadliel fiadliel force-pushed the same_rust_type_multiple_db_types branch from a5b305e to 049fb23 Compare July 26, 2024 11:49
These tests are still failing for the correctly reported reason.
The shorter error messages seem to be because this change reduces
the inference that's happening; this reduces some noise when
the compilation fails for other reasons.
@fiadliel fiadliel force-pushed the same_rust_type_multiple_db_types branch 2 times, most recently from 4ab8a66 to 2bcdd5d Compare July 26, 2024 12:26
…for one output type.

This tests that `QueryableByName` compiles, and outputs some data, for one example
where the types are pulled from a `table!` macro; and another example where the
values are specified as annotations in the struct.

It's difficult to find a type that has the required properties across all three
databases; these tests are compiled only for Postgres. To do something similar for
the other databases would probably require compiling with one of the time libraries.
@fiadliel fiadliel force-pushed the same_rust_type_multiple_db_types branch from 2bcdd5d to 99546fd Compare July 26, 2024 12:54
@fiadliel fiadliel marked this pull request as ready for review July 26, 2024 13:30
@fiadliel
Copy link
Contributor Author

@weiznich Added two tests.

They use citext, which is Postgres-only, but it's the only example of the issue that doesn't need any extra features compiled.
Also, let me know if you have a better idea for how to install the citext extension. It appears that CREATE EXTENSION IF NOT EXISTS is racy when run on the different connections at around the same time, so I'm doing it in the tests rather than at connection setup.

@weiznich weiznich requested a review from a team July 27, 2024 07:52
Copy link
Member

@weiznich weiznich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks 👍

I changed the test case to not depend on citext anymore. This solves the parallel initialization issue. I verified that it still produces the issue without fix.

@weiznich weiznich enabled auto-merge July 31, 2024 19:19
@weiznich weiznich added the maybe backport Maybe backport this pr to the latest diesel release label Jul 31, 2024
@weiznich weiznich force-pushed the same_rust_type_multiple_db_types branch from 6940a68 to 8ec670b Compare August 2, 2024 05:22
@weiznich weiznich force-pushed the same_rust_type_multiple_db_types branch from 8ec670b to 302fcd2 Compare August 2, 2024 05:42
@weiznich weiznich added this pull request to the merge queue Aug 2, 2024
Merged via the queue into diesel-rs:master with commit e21dfb9 Aug 2, 2024
49 checks passed
@fiadliel fiadliel deleted the same_rust_type_multiple_db_types branch August 3, 2024 13:45
@fiadliel
Copy link
Contributor Author

fiadliel commented Aug 3, 2024

Thanks!

weiznich added a commit to weiznich/diesel that referenced this pull request Aug 23, 2024
…le_db_types

Specify type of diesel::row::NamedRow::get in QueryableByName macro.
@weiznich weiznich mentioned this pull request Aug 23, 2024
weiznich added a commit to weiznich/diesel that referenced this pull request Aug 23, 2024
…le_db_types

Specify type of diesel::row::NamedRow::get in QueryableByName macro.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maybe backport Maybe backport this pr to the latest diesel release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Ambiguous traits in QueryableByName derivation when two fields have same concrete type but different SQL types
2 participants