Hi. I'm the author of slog. I sometimes check rev-dependencies on slog
and I've noticed that reql
is using it.
First of all, thanks for using slog
- I've put quite a bit of effort into making it, and I'm happy to see it being used. I hope it will work well for you. Second - I know reql
is 0.0.5
and some stuff I might point out you might find obvious, and just made it as shortcuts in reql
. Even so - maybe what I wrote will be useful for other people when eg. google will point them here. Third - feel free to ignore anything that you disagree with, I'm just sharing my opinion on how I envisioned things to work, and doing it your own way is fine with me.
Logger
is Sync
so it does not require wrapping in RwLock
. The idea is that Logger
s should be worry-free and when creating them you should only be concerned about the "context of logging", and not about your program threading-structure and so on.
Generally libraries should almost never create their own Drain
s. It's app to application using libraries to setup logging. Only the application can know what are the logging requirements: where, how and what to log. Usually libraries should accept Logger
from whatever is using them, potentially falling back to something. Here's the reference example: https://github.com/slog-rs/slog/blob/master/crates/example-lib/lib.rs . In case of reql
, I guess corresponding struct to MyLib
would be Client
. Note that this requires storing Logger
in Client
and potentially other structs. This is beneficial, as such Loggers
can carry the additional data. In reql
case, I guess the Client
's logger should carry the user, host, db
records with respective values. So eg. when someone is using multiple connections, it's clear which message comes from which Client
.
It's not slog
related but while looking at reql
the:
pub const r: command::Client = command::Client;
thing is very non-idiomatic. reql
is it's own crate, with it's own namespace. Having a const object, introduces a singleton, which forces locking and other problems. If anything there should be either global static function returning a connection builder, or Client
should have a static method, returning a builder, and the user of reql
would be responsible for locking etc.
extern create reql;
fn main() {
let logger = /* ... */
let reql_db = reql::Client::new(logger).set_db("x").build().expect("couldn't connect to db");
}
I'm not sure if logging errors in error!
is a good idea. I mean - it's the data that is being returned to the user of the library and most of the time user is going to log an error themselves. It only makes sense for the library to log things that the user of it is not able to access directly, to allow transparency into what is happening internally.