[Refactoring] Move DbConn out PlumeRocket #797

New issue

Open

opened 2020-07-14 20:42:13 +00:00 by igalic · 1 comment

igalic commented

2020-07-14 20:42:13 +00:00

Owner

Currently, we pass the struct PlumeRocket to most routes:

/// Common context needed by most routes and operations on models
pub struct PlumeRocket {
    pub conn: DbConn,
    pub intl: rocket_i18n::I18n,
    pub user: Option<users::User>,
    pub searcher: Arc<search::Searcher>,
    pub worker: Arc<ScheduledThreadPool>,
    pub flash_msg: Option<(String, String)>,
}

The reason for refactoring (#462) was clippy warning us about too many arguments to our route functions.
so we collected all the data that clumped together in the parameter lists, into a single Object.

This is presenting problems, when trying to migrate to async rocket.

I think we should extract DbConn again.
This should (could?) allow us to use #[database] guard, making our async migration slightly less pain-freer.

What do we need to do?

decorate DbConn with #[database]
identify all route functions that use rockets.conn, and
add a parameter dbconn, replacing it
once all uses are replaced, remove DbConn from PlumeRockets

Benefits? Drawbacks? Alternatives?
Discuss!

Currently, we pass the `struct` `PlumeRocket` to most routes: ```rust /// Common context needed by most routes and operations on models pub struct PlumeRocket { pub conn: DbConn, pub intl: rocket_i18n::I18n, pub user: Option<users::User>, pub searcher: Arc<search::Searcher>, pub worker: Arc<ScheduledThreadPool>, pub flash_msg: Option<(String, String)>, } ``` The reason for refactoring (https://git.joinplu.me/Plume/Plume/pulls/462) was clippy warning us about too many arguments to our route functions. so we collected all the [data that clumped together](https://refactoring.guru/smells/data-clumps) in the parameter lists, into a single Object. This is [presenting problems](https://git.joinplu.me/Plume/Plume/pulls/777), when trying to [migrate to async rocket](https://git.joinplu.me/Plume/Plume/pulls/730). ----- I think we should extract DbConn again. This should (could?) allow us to use [`#[database]` guard](https://github.com/SergioBenitez/Rocket/pull/1343), making our `async` migration slightly less pain-freer. What do we need to do? - [x] decorate `DbConn` with `#[database]` - [ ] identify all route functions that *use* `rockets.conn`, and - [ ] add a parameter `dbconn`, replacing it - [ ] once all uses are replaced, remove `DbConn` from `PlumeRockets` ------ Benefits? Drawbacks? Alternatives? Discuss!

kiwii commented

2020-07-15 09:46:45 +00:00

Owner

What I can tell out of my head is:

benefits:
- we can clearly see which routes use the database, and which don't
- we will probably have less custom code if we use the #[database] attribute that generates some code for us, I guess.
drawbacks:
- not sure it is the case, but maybe we won't be able to migrate to sqlx with the #[database] attribute, I don't know what types SQLx supports, and if they are compatible with Rocket's attribute.
alternatives:
- keeping it the way it is? but that makes the async migration harder, so it is not really an option

Clippy shouldn't be unhappy either, it is just one parameter, so I'm all for it!

What I can tell out of my head is: - benefits: - we can clearly see which routes use the database, and which don't - we will probably have less custom code if we use the `#[database]` attribute that generates some code for us, I guess. - drawbacks: - not sure it is the case, but maybe we won't be able to migrate to `sqlx` with the `#[database]` attribute, I don't know what types SQLx supports, and if they are compatible with Rocket's attribute. - alternatives: - keeping it the way it is? but that makes the async migration harder, so it is not really an option Clippy shouldn't be unhappy either, it is just one parameter, so I'm all for it!