Nlog: Support for `RuleName` property on a `<Rule>` (LoggingRule class)

[qaqz111]

Type:

• Feature request

NLog version: 4.4.12

Platform: .Net 4.5

• Why do we need it?
  The Id property of class LoggingRule can be used to locate exact rule in code, otherwise, we have to code a lot to find the rule we want:
  ```C#
  var rule = config.LoggingRules
  .FirstOrDefault(r =>
  "*" == r.LoggerNamePattern &&
  false == r.Final &&
  (null == r.ChildRules || 0 == r.ChildRules.Count) &&
  (null == r.Filters || 0 == r.Filters.Count) &&
  (null != r.Levels && 5 == r.Levels.Count) &&
  (null != r.Targets && 2 == r.Targets.Count));

So, if there is an `Id` property, we can do this:
```C#
            var rule = config.LoggingRules
                .FirstOrDefault(r => "ruleYouWant" == r.Id);

• An example of the XML config, if relevant.

  <rules>
    <logger name="*" writeTo="trace"/>
    <logger id="ruleYouWant" name="*" minlevel="Debug" writeTo="con,file"/>
  </rules>

Not only for LoggingRule class, but all that can be accessed by code should have an Id property or something else which can be used to locate them in code like Linq calls.

[304NotModified]

I like the idea!

Currently you could use the index as a poor man's solution

[qaqz111]

Haha, yes a poor man's solution indeed o(≧▽≦)o

In fact sometimes the index can be of help, but in a more complex application, the index way have a problem is that, we can not ensure that rules added by code always take the same indexes, so currently checking all properties is the most stable way.

I'm looking forward to this feature getting online ;)

[304NotModified]

I like the idea, and it's easy to implement, but there is one issue:

    <logger name="myname" writeTo="trace"/>

this means: filter the logs on the name "myname"

    <logger id="myname" writeTo="trace"/>

And this won't filter on an id or something. It could be confusing. Yes the name of name attribute if bad, but we can't change it. What do you guys think?

[stjephan]

I think id should be ok. If it's explained in the docu it should be enough.
Whats about "alias", "accessId" , "apiAccessId" or something like that?

[304NotModified]

Im thinking of rule-name or rule-id

[stjephan]

2 times a config value with "name" in it? I prefer "rule-id"

[304NotModified]

OK, and should be enforce an unique id?

Should be there a method to get the rules as dictionary? (id -> rule) - how do you think we should handle duplicate ids?

[stjephan]

Method would be nice but not a must. With simple linq statement I will find the required role.
For duplicates I suggest only to write into internal log and throw exception of enabled.

[304NotModified]

@snakefoot any opinion on this one?

[snakefoot]

@snakefoot any opinion on this one?

Seldom working with runtime configuration of NLog, so don't have much input. The easy solution would be to just add a non-unique Name-property to the LoggingRule (Not sure why this is rejected).

[304NotModified]

The easy solution would be to just add a non-unique Name-property to the LoggingRule (Not sure why this is rejected).

What's rejected?

[snakefoot]

What's rejected?

Totally forgot that the Xml-config had the name-alias. Yes then it has to be something else than "name" :)

Little confusing that one can use name-property in xml, but it is called LoggerNamePattern in code.

Think "Id" is good then, but then it has to been unique, and all loggingrules without id should get an auto-guid. Could be that changing to Dictionary-container will be a somewhat more complicated.

Maybe instead of "Id" then it could be "Tag", thus not introducing an unique-constraint.

[304NotModified]

Little confusing that one can use name-property in xml, but it is called LoggerNamePattern in code.

true, confusing. Maybe change it in NLog 5

[304NotModified]

Maybe instead of "Id" then it could be "Tag", thus not introducing an unique-constraint.

I only like tagging when it supports multiple tags ;)

I'm also fine by using a ID (attribute will be rule-id) and skipping the duplicate IDS when building a dictionary. Like HTML

[snakefoot]

I only like tagging when it supports multiple tags ;)

I only expect that when the property is called Tags and is a collection :)

I'm also fine by using a ID (attribute will be rule-id) and skipping the duplicate IDS when building a dictionary. Like HTML

Think that will give a very bad user-experience if only enforcing the constraint, when requesting the collection as dictionary. Should it throw exceptions when building the dictionary? (Like Linq.ToDictionary)

[snakefoot]

It could also be called label, but then you would probably argue that it should have more labels. Another alternative is alias.

[304NotModified]

I only expect that when the property is called Tags and is a collection :)

true, but tagging is IMO strange when only one tag could be applied.

Think that will give a very bad user-experience if only enforcing the constraint, when requesting the collection as dictionary. Should it throw exceptions when building the dictionary? (Like Linq.ToDictionary)

good one, exception is indeed better.

[snakefoot]

good one, exception is indeed better.

I would prefer that if adding "Id"-property, then it should validate it being unique at insert, instead of at a random point later.

[304NotModified]

yes and the exception is dependent of throwConfigExceptions

[qaqz111]

I think non-unique Name-property with the name of ruleName should be OK.

The reason for non-unique is that maybe we want to locate a group of rules, if the accessor is unique, the batch operations are still complicated.

The word 'Id' can give an impression that this is an unique identifier which was similar to 'id' property of html tags. So, I prefer ruleName if the property is non-unique, otherwise, ruleId for unique.

The other solution is, a Group property for locate multiple(grouped) rules, meanwhile, the ruleId for accurately locate an unique rule. Of course, there is alternative ways that you can use string.StartsWith in .Where() Linq calls for unique id property to locate multiple rules with same prefix .

Personally, I prefer the non-unique ruleName, and this is the most simple and clean solution: please don't make the api complex.

[stjephan]

Is it not possible to create child rules for groupping propose?

[stjephan]

Is this feature available during the next weeks?

[304NotModified]

I think it will be 4.6, or if a PR is sent, ealier

[snakefoot]

Resolved with #2891

[304NotModified]

FYI, NLog 4.6 RC is online which includes this feature