You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've found it useful to have a wrapper around a Pool, to distinguish between specific kinds of database connections (e.g. a user DB vs a global DB). I'd find my wrappers even more convenient to use if they implemented Executor. However, delegating Executor correctly requires implementing many methods with complex signatures (including a hidden method).
Prefered solution
I'd love to have some convenient way to delegate Executor to a field. I can see two straightforward ways to do this:
A derive(Executor) macro, which has an #[executor] attribute identifying the field to delegate to.
Something like an IntoExecutor trait, to be accepted by methods like execute instead of Executor, which has a single method that returns the trait. This would be simpler in some ways, but requires changing the signature of those methods. That should be a compatible change and shouldn't break any existing code.
Is this a breaking change? Why or why not?
The derive(Executor) approach is not breaking.
The IntoExecutor approach requires an API change but that API change should be compatible with existing code, and is unlikely to be breaking.
The text was updated successfully, but these errors were encountered:
I have found these related issues/pull requests
(none)
Description
I've found it useful to have a wrapper around a
Pool
, to distinguish between specific kinds of database connections (e.g. a user DB vs a global DB). I'd find my wrappers even more convenient to use if they implementedExecutor
. However, delegatingExecutor
correctly requires implementing many methods with complex signatures (including a hidden method).Prefered solution
I'd love to have some convenient way to delegate
Executor
to a field. I can see two straightforward ways to do this:derive(Executor)
macro, which has an#[executor]
attribute identifying the field to delegate to.IntoExecutor
trait, to be accepted by methods likeexecute
instead ofExecutor
, which has a single method that returns the trait. This would be simpler in some ways, but requires changing the signature of those methods. That should be a compatible change and shouldn't break any existing code.Is this a breaking change? Why or why not?
The
derive(Executor)
approach is not breaking.The
IntoExecutor
approach requires an API change but that API change should be compatible with existing code, and is unlikely to be breaking.The text was updated successfully, but these errors were encountered: