Expose "unmentioned properties" somehow

It would be interesting if there was a way to access “every property that was not explicitly mentioned” in a template.

For example, say I need to relocate a few properties to match a given log aggregator. I can “move” them in the template to whatever position I want, which is actually much nicer than having to code this in an enricher.

Exemple:

• { {needThisToBeNested: { nestedValue: @p['someProperty'] }, ..@p} }

Notice how I basically “move” the someProperty value into a nested structure. However, the ..@p at the end will end up emitting the same property again in the root level.

I’d like for a way to expand “only the properties that have not been used explicitly in the template”, so that the expansion at the end did not include a duplicate of someProperty.

I assume this is currently impossible without writing a custom user-defined function that filters @p, which would then force me to pass a list of all properties to filter manually and create substantial verbosity and repetition on my template. Something like:

• { {needThisToBeNested: { nestedValue: @p['someProperty'] }, ..FilterThis(@p, 'someProperty')} }

I imagine FilterThis would also not be the most efficient thing in the world, since it needs to match a StructuralValue, inspect all inner properties and then return a new StructuralValue without the ones that match the list of parameters.

Having said that, after trying a quick sample, user-defined functions do not appear to allow extra parameters in them:

public static LogEventPropertyValue? FilterThis(LogEventPropertyValue? property, params string[] filters)

System.ArgumentException: The function FilterThis requires 1 arguments.

So now I actually don’t know how to filter the properties to avoid the duplication.

[nblumhardt]

👍 currently the purely-functional nature of the language makes an “extract” difficult to visualize; it’s likely this is as good as it will get, for now.

Serilog output templates treat @Properties as “unmentioned properties”, but the overall design/mechanism doesn’t carry across - I think emulating it would result in some nasty implementation hacks 😃

[julealgon]

Ohhh ok. I was under the impression the shorthand syntax was only used for the main properties (level, message, template, etc).

Now I understand your sample, and it is a good workaround indeed. Still not ideal though, considering I’ll probably have to “move” a dozen or so properties this way, which will force me to add a lot of cruft to the end of the template duplicating every property name.

For that reason, I still think an “extract”-like method would be useful.