Make Grouped (and other such query structs) available with feature "i-implement-a-third-party-backend-and-opt-into-breaking-changes"

[LucaCappelletti94]

At the time of writing, structs like:

• Grouped
• Eq
• And
• SelectBy
• Bound

are pub within their own module, but then the modules are generally imported as pub(crate), with some of these modules being made public only under the feature flag "i-implement-a-third-party-backend-and-opt-into-breaking-changes".

I need these structs to be public to be able to write a where constraint that allows me to define that a certain query statement implements LoadQuery with a generic connection type, which in my own use case means using sqlite in the frontend and postgres in the backend.

Would a PR exposing all of these modules under the "i-implement-a-third-party-backend-and-opt-into-breaking-changes" analogously to the following be acceptable?

#[cfg(not(feature = "i-implement-a-third-party-backend-and-opt-into-breaking-changes"))]
pub(crate) mod array_comparison;
#[cfg(feature = "i-implement-a-third-party-backend-and-opt-into-breaking-changes")]
pub mod array_comparison;

More specifically, I would make a small macro to avoid re-writing the same logic several times.

[weiznich]

It's not required to make any of these types public. Diesel exposes helper types via the diesel::dsl module that can be used in their place in any location. These helper types are usually much easier to use as they make a few really helpful transformations to the underlying generic types. So for example instead of having to write Grouped<Eq<A:, <B as AsExpression<A::SqlType>>::Expression>> you can just write diesel::dsl::Eq<A, B> for a call to a.eq(b) where A and B are the corresponding types of the a and b values. These return types are named exactly like the function in almost all cases. If such a type is missing that's considered a bug in diesel and something that should be fixed.

I need these structs to be public to be able to write a where constraint that allows me to define that a certain query statement implements LoadQuery with a generic connection type, which in my own use case means using sqlite in the frontend and postgres in the backend.

It's certainly possible to do that, but I advice you to not do that as you run into nasty generic clauses soon. You likely want to use the #[derive(MultiConnection)] macro instead: https://docs.diesel.rs/2.2.x/diesel/derive.MultiConnection.html

More specifically, I would make a small macro to avoid re-writing the same logic several times.

That already exists:

diesel/diesel/src/query_builder/mod.rs

Lines 80 to 82 in 116e868

	#[diesel_derives::__diesel_public_if(
	feature = "i-implement-a-third-party-backend-and-opt-into-breaking-changes"
	)]

[LucaCappelletti94]

That multi-connection thing seems very nice, I wasn't aware of it. I will try to use that instead of a generic.