【问题标题】:FieldIndexOption not applied to nested objectsFieldIndexOption 不适用于嵌套对象
【发布时间】:2016-06-03 18:40:01
【问题描述】:

我正在使用 ElasticSearch 和 NEST 版本 2 来索引数据。我的数据对象可以有相同类型的子对象。我使用注释来表示不分析某些字段。发生的事情是这个注释被应用到父对象,而不是子对象。我正在尝试弄清楚如何修改我的注释以包含子实例。

我有这样的事情:

public class Person {
    public int Id {get; set;}

    [String(Index = FieldIndexOption.NotAnalyzed)]
    public string Code {get; set;}

    public Person child {get; set;}
}

当我第一次创建索引时如下:

client.Map<Person>(d => d.AutoMap());

映射如下所示:

"people": {
    "mappings": {
        "person": {
            "properties": {
                "id": {
                    "type": "integer"
                },
                "code": {
                    "type": "string",
                    "index": "not_analyzed"
                },
                "child": {
                    "type": "object"
                }
            }
        }
    }
}

我索引一些文档后如下:

client.Index(person);

映射更改为:

"people": {
    "mappings": {
        "person": {
            "properties": {
                "id": {
                    "type": "integer"
                },
                "code": {
                    "type": "string",
                    "index": "not_analyzed"
                },
                "child": {
                    "properties": {
                        "id": {
                            "type": "integer"
                        },
                        "code": {
                            "type": "string"
                        }
                    }
                }
            }
        }
    }
}

假设我有这样的文件:

{
    "id": 100,
    "code": "ABC100",
    "child": {
        "id": 123,
        "code": "ABC123"
    }
}

发生的情况是顶级人的Code字段没有分析,这很好,所以我可以这样搜索:

GET people/_search
{
  "query": {
    "term": {
      "code": "ABC100"
    }
  }
}

但是child上的code字段是用默认分析器分析的,所以ABC123变成了abc123。

因此,所有这些都会找到我的文档:

GET people/_search
{
  "query": {
    "term": {
      "child.id": 123
    }
  }
}
GET people/_search
{
  "query": {
    "term": {
      "child.code": "abc123"
    }
  }
}
GET people/_search
{
  "query": {
    "match": {
      "child.id": "ABC123"
    }
  }
}

但这不是:

GET people/_search
{
  "query": {
    "term": {
      "child.code": "ABC123"
    }
  }
}

我需要对我的对象注释进行哪些更改才能将相同的字段选项应用于子人员? (顺便说一句,在现实生活中,我有几个没有分析的领域,以及几个层次的深度。)

【问题讨论】:

  • 你能展示你用curl -XGET localhost:9200/people得到的映射吗?
  • 编辑了我的问题以包含此信息。

标签: elasticsearch nest


【解决方案1】:

Automapping in NEST does not recurse further than the top level by default,因此 Person 上的子属性被映射为一个对象,当您索引文档时,动态映射和字段类型推断会在映射中创建 child 上的字段。

NEST 可以通过将深度参数传递给.AutoMap(int) 来递归地映射类型

client.Map<Person>(m => m.AutoMap(1));

这将导致以下映射

{
  "properties": {
    "id": {
      "type": "integer"
    },
    "code": {
      "type": "string",
      "index": "not_analyzed"
    },
    "child": {
      "properties": {
        "id": {
          "type": "integer"
        },
        "code": {
          "type": "string",
          "index": "not_analyzed"
        },
        "child": {
          "properties": {},
          "type": "object"
        }
      },
      "type": "object"
    }
  }
}

我们现在使用预期的字段映射设置将id 和code 映射到子对象上。我们还在child 上获得了一个child 字段,映射为object。

如果您知道深度永远只会是 1,如果我们不想要顶层 child 上的 child 字段,我们可以稍微整理一下映射,使用流利的映射

client.Map<Person>(m => m
    .AutoMap()
    .Properties(p => p
        .Object<Person>(o => o
            .Name(n => n.child)
            .Properties(pp => pp
                .Number(n => n
                    .Name(nn => nn.Id)
                    .Type(NumberType.Integer)
                )
                .String(s => s
                    .Name(n => n.Code)
                    .NotAnalyzed()
                )
            )
        )
    )
);

产生

{
  "properties": {
    "id": {
      "type": "integer"
    },
    "code": {
      "type": "string",
      "index": "not_analyzed"
    },
    "child": {
      "type": "object",
      "properties": {
        "id": {
          "type": "integer"
        },
        "code": {
          "type": "string",
          "index": "not_analyzed"
        }
      }
    }
  }
}

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2022-12-10
    • 2019-01-05
    • 2018-11-04
    • 2019-08-27
    • 2021-09-05
    • 2016-04-08
    相关资源
    最近更新 更多