Description of the change
BoxedSelectStatement and BoxedWhereClause are now Send.
Why is this needed?
I’d like to enable the following API (from actix-diesel):
let results = await!(users::table.load_async(&state.db))?;
Where load_async sends the Query to a futures-aware thread pool, executes
it, and sends the result back.
This requires Query to implement Send. In a large API, all queries I interact with do implement Send. But the Boxed variants do not. The Boxed variants are required when conditionally filtering or conditionally joining in query building.
Why can’t this have a deprecation cycle?
Adding + Send bounds to the internal Box fields in the Boxed query variants isn’t something we could easily introduce in a backwards-compat way. I supose we could make SendBoxed___ types and .send_boxed() and deprecate the current types for a few cycles then deprecate SendBoxed___ to name it back to just Boxed___. That sounds more painful to me (two deprecation cycles) then just making the switch now.
Expected user impact
-
If you have generic methods that operate on a diesel query and wan to call
.boxed()on it you’ll need to add aSendbound to your type parameters. I don’t know how often this is done in practice. I don’t do this. -
If you have any sql types that themselves do not implement
Sendthen you’d be blocked with no quick work-around. All of the sql types indieselareSendthough.
Migration strategy
- The only breakage I would expect is in the generic bound on on a query type that then has
.boxed()called on it. That should be a quick+ Sendbound added and all fixed.