Question

我正在使用Azure搜索复杂类型预览API（2017-11-11-Preview）来按复杂类型进行筛选/构面。我所有的过滤器和构面都是在嵌套类型（而不是根类型）的属性上创建的，看起来它们没有在正确的嵌套级别上组合，而仅通过文档根目录组合。例如，我在搜索索引中有下一个文档

{ 
  apartmentComplexId: "1",
  apartmentTypes: [
    { 
      bedroomCount: 1,
      bathroomCount: 2
    },
    { 
      bedroomCount: 2,
      bathroomCount: 3
    }
  ]
}

apartmentTypes.bedroomCount和apartmentTypes.bathroomCount被刻面和过滤。数据集的构面结果将返回

{
  "apartmentTypes/bedroomCount": [
    {
      "count": 1,
      "value": 1
    },
    {
      "count": 1,
      "value": 2
    }
  ],
  "apartmentTypes/bathroomCount": [
    {
      "count": 1,
      "value": 2
    },
    {
      "count": 1,
      "value": 3
    }
  ]
}

当我执行下一个查询时：

$filter=apartmentTypes/any(x: x/bedroomCount eq 1)&facet=apartmentTypes/bathroomCount

作为响应，我的facet集合包含bathroomCount的所有两个可能的facet值-2和3，每个值均为1。

{
  "apartmentTypes/bathroomCount": [
    {
      "count": 1,
      "value": 2
    },
    {
      "count": 1,
      "value": 3
    }
  ]
}

下一步，我尝试在更具体的过滤器中使用构面数据

$filter=apartmentTypes/any(x: x/bedroomCount eq 1 and x/bathroomCount eq 3)

糟糕，我的结果集为空。

我了解更正确的过滤器字符串应类似于

$filter=apartmentTypes/any(x: x/bedroomCount) and values/any(x: x/bathroomcount eq 3)

但是我需要完全像这样的功能-找到的实体应该在其集合中包含具有所有多面结果的项目。

Answer 1

切边和过滤都在文档范围内进行，而不是在复杂集合中的项目范围内进行操作（尽管您可以像在第一个示例中那样在复杂集合上编写相关的过滤器）。这是设计使然。

在您的情况下，这导致用户期望与系统行为不匹配。作为用户，如果我点击描述公寓的各个方面，我自然会假设过滤也在公寓上进行，但实际上是在公寓复杂物上进行。这就是为什么您的示例中的空结果集如此不直观的原因。

我建议根据用户的浏览方式为索引建模。假设用户通常搜索的是公寓，而不是公寓，请尝试制作apartmentType文档类型，并在必要时对公寓的信息进行非规范化。

同时，请考虑在User Voice上创建一个项目，以帮助我们优先考虑将对相关方面的支持优先于复杂集合。

通过筛选后的嵌套属性进行构面的Azure Search Complex类型基于发现的对象

1 个答案: