I think an `action` field is a good idea with one caveat that without formal
naming strategy it's fairly simple to get a lot of inconsistencies in there and
have for example `starting_compaction` in one place and `compaction_start` in
another. Can't think of a good way to solve it without defining some naming
rules beforehand and then adding a check for compliance as a part of a review
process.
Than again I might be overthinking this and it doesn't matter as long as the
actions are unique and greppable in code.
On another note, here seems to be a general believe that `FormatArgs` always
represent data worth adding to a data portion of logs. I personally don't think
that's the case, with a message `log("Starting compaction for shard ~p on
update sequence ~p", [<<"shard">>, 12])` it would be helpful to have an ability
to query by `shard` field, much less so for `update_sequence` field. Let's not
forget that data points are not free, each represent an index on a receiving
side meaning storage size and log processing rate.
If we are insist on treating `FormatArgs` and `ExtraFields` as the same, then
probably we are better to give up on `io_lib:format` for message formatting and
switch to a proper templating like
[mustache](https://github.com/mojombo/mustache.erl) or
[dtl](https://github.com/erlydtl/erlydtl), if we can't keep things simple we as
well can go whole way.
[ Full content available at: https://github.com/apache/couchdb/issues/1373 ]
This message was relayed via gitbox.apache.org for [email protected]
