String fromatter #283
String fromatter #283
Conversation
| bool formatStackTraceAsArray = false) | ||
| : base(omitEnclosingObject, closingDelimiter, renderMessage, formatProvider, serializer, inlineFields, true, formatStackTraceAsArray) | ||
| bool formatStackTraceAsArray = false, | ||
| bool renderMessageTemplate = true) |
There was a problem hiding this comment.
This is a breaking change; introducing a new (even optional) parameter. Why do you want to change this?
| using Serilog.Events; | ||
| using Serilog.Formatting.Elasticsearch; | ||
|
|
||
| namespace Host |
There was a problem hiding this comment.
Can you change the namespace?
| /// Note that using this formatter comes at the cost that the exception tree | ||
| /// with inner exceptions can grow deep. | ||
| /// </summary> | ||
| public class ElasticsearchStringifyFormatter : ExceptionAsObjectJsonFormatter |
There was a problem hiding this comment.
The power of ES is that it can understand the different types. Although I understand what you want here, it reduces functionality in order to fix another issue. A formatter that prefixes the type I can see living in this repository, this class is a small addition for specific use cases. Can it not exist only in your project (or a separate nuget package)?
There was a problem hiding this comment.
I didn't know this was possible and would've loved if it was a part of the original package! Very cool, and solves my issue as well.
There was a problem hiding this comment.
I didn't know this was possible and would've loved if it was a part of the original package! Very cool, and solves my issue as well.
Are you then okay with closing this PR and use it directly from your code only?
| namespace Host | ||
| { | ||
| /// <summary> | ||
| /// A JSON formatter which ensures no type conflicts arieses in Elasticsearch by casting everything to strings. |
|
Closing for now as it can be used from outside the package. |
What issue does this PR address?
Implements formatter that avoids the common issue type conflicts in Elasticsearch when different log statements use the same property name differently.
Does this PR introduce a breaking change?
No. All changes are backward compatible.
Please check if the PR fulfills these requirements
Other information:
This addresses #282.