Extraction patterns#24
Conversation
|
This should be enough to make |
KodrAus
left a comment
There was a problem hiding this comment.
This looks good to me! The loop over pattern elements is pretty subtle. Maybe we should document how it works once the design's nailed down more?
|
Thanks @KodrAus! I've got another changeset in the works that should bring the whole I think I've got the essentials figured out so that the one "recursive pattern" feature will give us groups (all-or-nothing), captures that include literal text: Loaded {SignalId:signal-{:ident}}
// Matches:
// Loaded signal-12345abc
// Extracts:
// SignalId = "signal-12345abc"
{:{Year:nat}-{Month:nat}}
// Matches
// 2012-02
// Does not match:
// 2012With some small additions we should also be able to squeeze optionals and alternation out of it, still throwing some ideas around. Cheers! |
This includes enough functionality to parse log files written by the Serilog.Sinks.File sink using its default output format:
Extraction pattern:
{@t:timestamp}-@tis the well-known timestamp property;timestampis a named matcher that will be extended to handle a variety of formats (iso8601dtcould be specified here if the file used ISO date times)[- any text not enclosed in curly braces is a literal part of the pattern{@l:ident}- the level;identis anything conforming to C-style identifier rules; omitting the:identwould be possible here if the level had whitespace to the right, but since we don't want to pull]into the level name, we need to be more specific{@m:*}- the matcher*is the "non-greedy content" matcher; it'll read until the pattern following it matches**will match until the two following patterns match, and so-on{:n}is an anonymous match - the name is empty, andnis a matcher for newlines{@x:*}- exception; also using the "non-greedy content" matcher, but since the following pattern is end-of-input it'll slurp up anything that's left in the framePatterns stop matching when the frame ends, so the pattern can still handle:
I.e. the newline and exception are not mandatory.
There are some comments in
ExtractionPatternInterpreterTestssuggesting how we might extend this to a couple more cases.Needs better error messages, and error handling/"report" mode, but does get the end-to-end scenario going :-)