db_logger is a logging implementation that writes log entries to a
database. At the time of this writing, it supports PostgreSQL and
SQLite via the sqlx crate.
Closes#458. Implements Log for references to loggers, as well as loggers wrapped
in `Arc` or `Pin`. More may be added in the future. Especially, we probably will
want to add a blanket implementation (bounded on `Borrow`) once we have impl
specialization. (Technically, we could probably already do this now, but at the
risk of painting ourselves into a corner.)
Attempt number two/three? Too many in any case.
Previously I proposed a design that followed a `struct` like syntax:
```rust
info!("my message: {}", arg, {
key1: "value1",
key2: 123,
});
```
However it turns out that this does not work well with named arguments
as reported in issues #369 and #372. The implementation was eventually
reverted in pr #374.
This new design takes inspiration from the `tracing` crate which already
supports key-value pairs in logging events. The basic idea is to put the
key-value pairs before the message and arguments. Applying the same
structure like syntax as above we would get something like the
following.
```rust
info!({
key1: "value1",
key2: 123,
}, "my message: {}", arg);
```
But personally I'm not a big fan of this formatting, let's try putting
everything on a single line instead.
```rust
info!({ key1: "value1", key2: 123 }, "my message: {}", arg);
```
A little better, but at this point the structure like syntax is really
more annoying then helpful. So, instead I've done away it, opting
instead use the following syntax.
```rust
info!(key1 = "value1", key2 = 123, "my message: {}", arg);
```
Two major differences:
* Removed the brackets.
* Colons (`:`) are replaced with equal/assignment signs (`=`).
This gives us syntax similar to variable assignment.
But then we run in some limitations of the macro syntax, specifically
that `expr` fragments aren't allowed after `expr` fragments. To fix this
I went with the easiest option of changing the last comma (`,`) after
the key-value pairs to a semicolon (`;`). Making the final syntax look
like the following.
```rust
info!(key1 = "value1", key2 = 123; "my message: {}", arg);
info!(target: "my_target", key1 = "value1", key2 = 123; "my message: {}", arg);
log!(target: "my_target", log::Level::Info, key1 = "value1", key2 = 123; "my message: {}", arg);
```
Which, in my opinion and all things considered, it's too bad looking.
It's replaced by hint::spin_loop, however that has only been stable
since 1.49.0. Since we still support 1.31.0 we can't use it. Once the
MSRV is updated to 1.49 we can use hint::spin_loop.
* prepare for.0.4.14 release
* update based on value-bag API
* rename to_error to to_borrowed_error
* note method name change in changelog
* update to released value-bag
It was not clear whether `error` or `trace` was the maximum log level.
The docs said "`error!` represents the _highest_-priority log messages and `trace!` the _lowest_".
Yet, `set_max_level` regards `Trace` to be the maximum level.
I attempted to clarify this by avoiding the terms "high" and "low" in the docs except for where
they are applicable to the Rust order as defined in `Ord`.
Some platforms don't provide a AtomicUsize. Instead of just failing to
build with this error:
291 | use std::sync::atomic::{AtomicUsize, Ordering};
| ^^^^^^^^^^^ no `AtomicUsize` in `sync::atomic`
let's instead add a fake AtomicUsize.
As the platform doesn't have atomics we can't implement an Atomic
version of AtomicUsize, so this version is not atomic. Any platform
without atomics is unlikely to have multiple cores, so this shouldn't be
a problem.
This is somewhat based on:
940d2e9d7f
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
