- Dortmund
- https://igalic.co/
-
Infrastructure & Open Source
(Homoiconic Ops Witch)
- Joined on
2020-06-26
gonna have to ask somebody how the heck this is happening
that means we won't know exactly why the pool didn't give us a connection
you're not trying to convert the original diesel::r2d2::Error?
can you briefly explain why?
we use .unwrap() in all other lines.
Some observations, which lead to the confidence with which we've started on #807:
DbPool is an Arc, it can be easily shared via .clone().
This would allow us to create a wrapper object around Searcher which can then have its own DbConn instead of passing one from a — hopefully — short-lived Request, potentially infinitely blocking on it.
The general framework lends itself nicely to be solved with an actor framework, but if that doesn't pan out, we can use any old object, and send it any old message! We've already done good work there in extracting the essence.
It bears repeating why the refactoring to break up PlumeRocket is so important:
We pass PlumeRocket around as ref.
It's a giant struct with lots of maybe-related data, giving access to different parts of the system.
Passing it, by ref thru Rocket will become an issue as soon as we try to go async, because then we have a borrowed object sitting somewhere, waiting to be .awaited.
This is all a big mess, and best of all avoided, but it's also a good opportunity to see which parts of the system we can tear apart from there tight coupling so they will work better.
here's what I've found out in an experiment attempting to extract Searcher into an actor:
- Searcher is intimately bundled with Post
- despite that, Searcher is also intimately bundled with DbConn, because Post doesn't actually have all the info Searcher needs
given this asymmetry, i thought it's best to only pass Post.id
but we still have to give it access to a DbConn
perhaps on creation of a Searcher Actor, we could give it its own DbConn?