Open bikeshedder opened 3 years ago
The only downside with this I see right now is that writing the configuration like that would require the the configuration parameters to be nested within a manager
property:
{
"pg": {
"manager": {
"host": "/run/postgresql"
},
"pool": {
"max_size": 64
}
}
}
It should be possible to keep the old configuration structure using some serde annotations, but feel like this should be avoided in the interest of clarity.
@bikeshedder Thanks a lot for opening the issue! My two cents (from a Rust beginner :)):
I don't see the added value of Into/From traits for Config <-> Pool; it seems calling create_pool
that consumes the config is already very explicit and simple.
I also don't really dig the idea of extracting the connection details into a specific config sub-field; even though the structure is a bit more clear, the usability is lower.
What do you think about flattening the deadpool-*
Config structs to include the max_size
and timeout_*
attributes directly in the struct, with respective defaults next to the connection details, like this?
e.g. Redis (Postgres config is a bit longer currently)
pub struct Config {
pub url: Option<String>,
pub pool_size: Option<usize>,
pub timeout_wait: Option<Duration>,
pub timeout_create: Option<Duration>,
pub timeout_recycle: Option<Duration>,
}
Internally, the conversion from these specific fields to the PoolConfig/Timeout could still happen, possibly by extracting the PoolConfig behavior to a Trait of sorts...
Right now the
Config
structs of thedeadpool-*
crates contain all the connection configuration and apool: PoolConfig
field. It would be better to move the configuration specific to the connection/manager into its own structure.Right now the
Config
structs implements acreate_pool
method which creates a manager using the connection/manager specific fields and uses thepool
field to create the actual Pool.I think a better design would be to have a
PoolConfig
andManagerConfig
structure which are both part of a new structure calledConfig
. The newConfig
structure would look more or less like that:The
create_pool
would now consumeself
and also enable the implementation of theInto
/From
traits:The
Config
struct could even be made into a genericConfig<M>
structure, but I'm undecided if that's actually worth it.