Deleting a branch is permanent. It CANNOT be undone. Continue?
igalic/Plume:refactor/extract-searcher-with-dbpool
into main
No due date set.
This pull request currently doesn't have any dependencies.
Deleting a branch is permanent. It CANNOT be undone. Continue?
This PR is another attempt at fixing #799
Instead of relying on a separate actor model, as described, we make use of the fact that DbPool is an
Arc
, and can be arbitrarily cloned, so we add it toSearcher
. Further more, anddb_pool.get()
acts like sending a message to an Actor: if there are enough connections, the Pool gives us one, if not, tough luck!this way, we don’t need to pass along a conn into the searcher functions.
This should make splitting PlumeRocket up into its components a little easier.
👌
I would prefer using
?
instead ofunwrap
here.can you briefly explain why?
we use
.unwrap()
in all other lines.I think all the previous ones are safe: we now it can’t panic because we control the search index schema, we know that these fields exist (even if Rust can’t check this at comoile-time). Here, we may fail to get a DB connection from the pool for whatever reason, and I think we should make the error “go up”, so that the web UI or the CLI can display a proper error.
Same here.
👀
you’re not trying to convert the original
diesel::r2d2::Error
?It is a
r2d2::Error
, not the same as Diesel’s one apparently. And I don’t want to add another direct dependency in our Cargo.toml.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
🙋🏻♀️
why are we returning
Arc<Self>
?this means our code needs to know exactly how it’s going to be used
what about cli? does that use an Arc?
i would use this function to only return a Self
there’s no need to init_pool, we just want a copy
we can create an initialize method, which tries to call open and create methods in the appropriate order with the error recovery, if that makes sense here
but as it stands, for a new function, this does too much
closing in favour of #813
Reviewers