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 aSend
bound 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
Send
then you’d be blocked with no quick work-around. All of the sql types indiesel
areSend
though.
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+ Send
bound added and all fixed.