Closed JosiahParry closed 5 months ago
I guess you stumbled over Object::<Backend>
thinking that it does wrap the Backend
. It does in fact wrap the Backend::Type
.
Pool::<Backend>::get()
returns W
(= Object<Backend>
):
Object<Backend>
implements Deref<Target=Backend::Type>
:
I guess you stumbled over Object::<Backend>
thinking that it does wrap the Backend
. It does in fact wrap the Backend::Type
.
Regarding the W
type. It's there so one can implement traits on objects returned by the pool. e.g. deadpool-redis
uses this to implement the ConnectionLike
trait:
You might be interested in the way deadpool-postgres
keeps track of the StatementCache
of the objects. That's where Pool::detach
comes into play.
I just opened an issue for tracking an idea that's been in my head for quite some time now:
@JosiahParry Did that solve your issue? If so, please close this issue.
I haven't had the ability to verify. I ended up writing my own manager-esque thing using a DashMap
to use.
FWIW I was (and still slightly am) interested in using deadpool with a pingora reverse proxy to scale backend instances.
I have a custom struct, for example we can call it
App
which has a field ofVec<Backend>
. I would like implement theManager
trait for myApp
struct but have theimpl Manager
return aBackend
that way I can track and manage other important state in theApp
struct.I was able to implement Manager for
App
and specifytype Type = Backend
but.get()
returnedApp
notBackend
ignoring theType
specification.