-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Selectable derive does not work with generic embed sub-fields #2950
Comments
I'm not sure if there is an easy way to fix this issue. We would need to do some simplified form of type resolution there to understand that the type To workaround this issue, you can add this bound directly to your struct definition. This should also force the bound in any generated code. |
My suggestion was to add the bound not on the generic types, but on the field types that are e.g., here: #[derive(Selectable)]
struct S<T> {
#[diesel(embed)]
a: SomeStruct,
#[diesel(embed)]
b: T,
some_field: i32,
} the where clause would be
e.g. struct S {
...
}
impl Selectable<Pg> for S { ... }
#[derive(Selectable)]
struct S2 {
#[diesel(embed)]
f: S,
}
I've considered this but the bound is relative to a |
That's a great idea and that should be really simple to add. Basically just add a loop over fields here and add the corresponding bounds to the where clause: diesel/diesel_derives/src/selectable.rs Lines 12 to 16 in b2c5889
for field in model.fields() {
if field.has_flag("embed") {
let where_clause = generics.where_clause.get_or_insert(parse_quote!(where));
let embed_ty = &field.ty;
where_clause
.predicates
.push(parse_quote!(#embed_ty: Selectable<__DB>));
}
} Feel free to open a PR with this + a test case showing that it works as expected. |
Resolves diesel-rs#2950 Previously, fields had `embed`, the `Selectable` derive supposed that they implemented `Selectable<DB>` for every `DB: Backend`. If that wasn't the case (generic subfield or backend-specific impl) the derive would fail. This commit fixes this issue by introducing the appropriate additional `where` bounds.
Resolves diesel-rs#2950 Previously, fields had `embed`, the `Selectable` derive supposed that they implemented `Selectable<DB>` for every `DB: Backend`. If that wasn't the case (generic subfield or backend-specific impl) the derive would fail. This commit fixes this issue by introducing the appropriate additional `where` bounds.
Resolves diesel-rs#2950 Previously, if fields had `embed`, the `Selectable` derive supposed that they implemented `Selectable<DB>` for every `DB: Backend`. If that wasn't the case (generic subfield or backend-specific impl) the derive would fail. This commit fixes this issue by introducing the appropriate additional `where` bounds.
Setup
Versions
What are you trying to accomplish?
What is the expected output?
What is the actual output?
-> fails to compile with "the trait bound
T: diesel::Selectable<__DB>
is not satisfied".Solving
Looks like if a field has
embed
, theSelectable
derive should add boundsFieldType: diesel::Selectable<__DB>
, regardless of whether the type is generic or not.This would also allow the
Selectable
derive to interact as expected with manual implementations ofSelectable
on a single backend (non-generic).The text was updated successfully, but these errors were encountered: