8.15.6 - Bring Back IProperty.Name

[niemyjski]

Elastic.Clients.Elasticsearch version: 8.15.6

Elasticsearch version: 8.15.1

.NET runtime version: 8.x

Operating system version: Any

Description of the problem including expected versus actual behavior:

Seems really important for debugging and lookup purposes to have the field name attached to a property. Maybe this could be stored in local metadata?. We use this heavily in Foundatio.Parsers for:

1. Getting server and local code mappings to resolve field names based on partial name matches.
2. Help with resolving FieldAliasProperty (seems really odd that FieldAliasProperty is missing the name).

Expected behavior

Being able to lookup properties by name

Reference: FoundatioFx/Foundatio.Parsers#84

[flobernd]

Hi @niemyjski,

this is a difficult one. In ES, property objects do not hold their names. They are always used as part of a dictionary (Properties type in the new client):

{
  "prop": {
    "my_property": {
      "type": "boolean",
      "...": "..."
    }
  }
}

Keeping the property name as local metadata in the IProperty instance could easily cause inconsistencies if the same IProperty instance is added to multiple Properties dictionaries while using different names for the keys.

Would it help, if I add an additional method to the Properties dictionary type that allows to perform a reverse lookup? Something like:

class Properties
{
    public string? TryGetName(IProperty property) { ... }
}

[niemyjski]

That would be extremely useful!

[flobernd]

I just double checked and saw that Properties implements IEnumerable<KeyValuePair<PropertyName, IProperty>> which means that the reverse lookup could be done using this interface.

Given that fact, I think that a custom TryGetName method won't provide any benefits since the lookup can be done with a Linq one-liner. WDYT?

[niemyjski]

I think it helps those that are upgrading I'm also using this on IProperty not IProperties, am I missing something?

[flobernd]

@niemyjski

The Elasticsearch API uses Dictionary<Field | PropertyName, Property> in almost all (but not really all) cases since the Property type itself (as defined by Elasticsearch) does not contain its own name.

NEST changed the structure by pulling-in the dictionary key as a synthetic Name property.

This is problematic for at least 3 reasons:

1. In some rare cases, IProperty is used outside of a dictionary (e.g. in DynamicTemplate) which means that this place is incompatible with the structural change.
2. It prevents properties from being reused (you can't use the same IProperty instance for multiple properties, because it's bound to a name).
3. It is inconsistent with the REST API (which is only a low priority reason of course).

I'm also using this on IProperty not IProperties

I think the trick is to pass Properties instead of IProperty to your functions. This way you always have access to the IEnumerable<KeyValuePair<PropertyName, IProperty>> interface mentioned above and a reverse lookup would be as easy as:

var propertyName = properties.FirstOrDefault(x => ReferenceEquals(x.Value, property)).Key;

Would that work for you?