-
-
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
MultiConnection not usable for queries containing Selectable
or boxed queries.
#3566
Comments
I did some work on this and it seems like that the problem with pub trait CompatibleBackend<DB>: Backend {}
impl<DB> CompatibleBackend<DB> for DB where DB: Backend {} then we can provide the corresponding additional impl for the generated multibackend type and restrict the Unfortunately that will not work for the boxed select statement case, due to the fact that a boxed select statement internally stores boxed query fragment trait objects for a specific backend type and we cannot simply convert them to something else. At that point I'm not even sure if that ever can be supported :( |
This commit fixes various issues with backend dependent `QueryFragment` impls in combination with `#[derive(Multiconnection)]`. In all cases we solve these issues by not calling the concrete backend specific `QueryFragment` impl early in the query building process. Instead we call the generic `MultiBackend` specific impl, that later defer to the correct implementation specific one. In addition this commit adds some test for the fixed cases.
This commit fixes various issues with backend dependent `QueryFragment` impls in combination with `#[derive(Multiconnection)]`. In all cases we solve these issues by not calling the concrete backend specific `QueryFragment` impl early in the query building process. Instead we call the generic `MultiBackend` specific impl, that later defer to the correct implementation specific one. In addition this commit adds some test for the fixed cases.
This commit fixes various issues with backend dependent `QueryFragment` impls in combination with `#[derive(Multiconnection)]`. In all cases we solve these issues by not calling the concrete backend specific `QueryFragment` impl early in the query building process. Instead we call the generic `MultiBackend` specific impl, that later defer to the correct implementation specific one. In addition this commit adds some test for the fixed cases.
This commit fixes various issues with backend dependent `QueryFragment` impls in combination with `#[derive(Multiconnection)]`. In all cases we solve these issues by not calling the concrete backend specific `QueryFragment` impl early in the query building process. Instead we call the generic `MultiBackend` specific impl, that later defer to the correct implementation specific one. In addition this commit adds some test for the fixed cases.
This commit fixes various issues with backend dependent `QueryFragment` impls in combination with `#[derive(Multiconnection)]`. In all cases we solve these issues by not calling the concrete backend specific `QueryFragment` impl early in the query building process. Instead we call the generic `MultiBackend` specific impl, that later defer to the correct implementation specific one. In addition this commit adds some test for the fixed cases.
This commit fixes various issues with backend dependent `QueryFragment` impls in combination with `#[derive(Multiconnection)]`. In all cases we solve these issues by not calling the concrete backend specific `QueryFragment` impl early in the query building process. Instead we call the generic `MultiBackend` specific impl, that later defer to the correct implementation specific one. In addition this commit adds some test for the fixed cases.
This commit fixes various issues with backend dependent `QueryFragment` impls in combination with `#[derive(Multiconnection)]`. In all cases we solve these issues by not calling the concrete backend specific `QueryFragment` impl early in the query building process. Instead we call the generic `MultiBackend` specific impl, that later defer to the correct implementation specific one. In addition this commit adds some test for the fixed cases.
This commit fixes various issues with backend dependent `QueryFragment` impls in combination with `#[derive(Multiconnection)]`. In all cases we solve these issues by not calling the concrete backend specific `QueryFragment` impl early in the query building process. Instead we call the generic `MultiBackend` specific impl, that later defer to the correct implementation specific one. In addition this commit adds some test for the fixed cases. Acked-by: Georg Semmler <github@weiznich.de>
This commit fixes various issues with backend dependent `QueryFragment` impls in combination with `#[derive(Multiconnection)]`. In all cases we solve these issues by not calling the concrete backend specific `QueryFragment` impl early in the query building process. Instead we call the generic `MultiBackend` specific impl, that later defer to the correct implementation specific one. In addition this commit adds some test for the fixed cases. Acked-by: Georg Semmler <github@weiznich.de>
Setup
Versions
Feature Flags
Problem Description
What are you trying to accomplish?
I've tried the following code:
What is the expected output?
Code compiles
What is the actual output?
Code does not compile:
(That sounds that some queryfragment impls in diesel are to restrictive for using
selectable
and/or boxed queries with the newMultiConnection
derive.Are you seeing any additional errors?
Checklist
closed if this is not the case)
The text was updated successfully, but these errors were encountered: