[SERVER-46650] Allow use of string variables in log messages Created: 05/Mar/20 Updated: 27/Oct/23 Resolved: 06/Mar/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Tools |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Xuerui Fa | Assignee: | Andy Schwerin |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: |
| Description |
|
Currently, it seems we aren't able to use string variables directly in a call to LOGV2. We end up with work-arounds like here, where we build the message using str::stream and then pass that in as an attribute. Ideally, there would be a way for us to pass in string variables directly. |
| Comments |
| Comment by Andy Schwerin [ 30/Mar/20 ] | |||||
|
Non-literal message strings are explicitly not supported. | |||||
| Comment by William Schultz (Inactive) [ 30/Mar/20 ] | |||||
|
I feel that this issue also impacts the ease of writing log statements for printf style debugging. For example, right now, I have to write a diagnostic log message like:
but ideally I would like to just write:
The latter, though, does not appear to be supported. | |||||
| Comment by Andy Schwerin [ 06/Mar/20 ] | |||||
|
For the example in the ticket description, I think the improvement in The logging system intentionally prohibits the use of variables in messages. I suppose we could investigate allowing constexpr values and not just string literals, but we want the message to be determined at compile time, and extractable to an external catalog. Variable data is intended to appear in the attribute fields. | |||||
| Comment by Judah Schvimer [ 06/Mar/20 ] | |||||
|
Another example is here, where 'newlyAdded' could use a string constant (and ideally would), but we inline the string instead. | |||||
| Comment by Bruce Lucas (Inactive) [ 06/Mar/20 ] | |||||
|
This seems contrary to the goals of structured logging. Shouldn't the strings in the example you cited be provided as attributes, i.e. the output should be something like
(Not sure of the details of the attribute names because I'm not quite sure exactly what is mismatched in this case, but hopefully this conveys the idea.) | |||||
| Comment by Judah Schvimer [ 05/Mar/20 ] | |||||
|
This would especially be useful for string constants that we don't want to have to duplicate. |