context of logging

[arBmind]

Very nice idea. I know you want to prove your point of faster "binary logging". But I think this extension fits much better here than any other logging framework.

As background: I ran into the issue that at positions where errors occur the context that lead to this issue is out of focus.

For example I migrate multiple databases and multiple tables. But a column data type does not match to the current database provider. But when I tell the user "yeah this data type does not work" he needs the context which column, which table and which database the error refers to.

The idea is, that I store context information to the log, but those are only written once a log message is written.

The "very stylized" usage might look like this:

void migrate_database(auto database) {
  logger.context("migrating database %s", database.name);
  for (auto table : database.tables) migrate_table(table);
}
void migrate_table(auto table) {
  logger.context("migrating table %s", table.name);
  for (auto column : table.columns) migrate_column(column);
}
void migrate_column(auto column) {
  logger.context("column %s", column.name);
  auto sql_type = to_sql_type(column.type);
}
auto to_sql_type(auto type) {
  // … else
  logger.error("wrong sql type");
}

The log may look something like this:

error: wrong sql type
context: column xyz, migrating table users, migrating database example

Or the context is only set once

context: migrating database example
context: > migrating table users
context: > > column xyz
error: wrong sql type
context: > > column abc
error: wrong sql type
context: > migrating table products
context: > > column price
context: wrong sql type

I hope you get what I mean. What do you think?

[blapid]

Glad you liked it :)

Your idea sounds very interesting! I usually solve such issues with huge log lines that emit all of the context on the error branch, but what you suggest seem more elegant.

A couple of questions/thoughts:

1. Are subsequent context calls necessarily mean nested structure? If so, what kind of control over the structure do you suggest we give the user?
2. I think that some kind of context_clear call would be needed. Otherwise, you'd get irrelevant context from the past. What do you think?
3. When writing this framework, I avoided any allocation during the log call sites. This means that if we're to add context calls as you suggest, the amount we keep would be limited by the amount of memory we allocate when we create the logger. Yeah, the users will be able to control that amount, but if they're wrong, they could lose some of the context. It's not too bad, but we have to decide what to do in that case: stop accepting context calls or dropping the oldest calls.

Anyway, I'll mark this as a feature request so I can track those better.

[arBmind]

I suggest to use the C++ scoping for nesting the context. The same way as std::lock_guard.

{
    auto ctx = logger.context(…);
    // context is active here
} // context is freed here

Internally you might create a linked list of context objects and avoid all allocations.

I you like the idea I might try to create a PR for a more detailed discussion.