Algolia 搜索记录中的嵌套对象 - 一个对象中的多个 facetFilters
Algolia search on nested objects in a record - multiple facetFilters in one object
我正在从 Mongo 迁移到 Firebase,顶部是 Algolia 以提供搜索。但是遇到了一个障碍,提出了一种类似的方法来搜索记录的各个元素。
我有一个对象可以在有空房间时存储:从和到。每条记录可以有许多单独的 from/to 组合(参见下面的示例 2)。我希望能够 运行 进行如下搜索:
roomavailable.from <= 1522195200 AND roomavailable.to >=1522900799
但只让查询搜索每个元素内的匹配项,而不是所有元素中的任何方面。 Mongo 中的元素查询就是这样工作的。但是如果我 运行 查询下面列出的记录,它将 return 记录,因为两个 roomavailable 对象满足 .from 和 .to 查询。我觉得。
有没有一种方法可以确保搜索只查找匹配个人中的一对 .from 和 .to object/element?
以下是存储在 Algolia 中的记录的相关部分,因此您可以看到结构。
"roomavailable": [
{
"_id": "rJbdWvY9M",
"from": 1522195200,
"to": 1522799999
},
{
"_id": "r1H_-vKqz",
"from": 1523923200,
"to": 1524268799
}
],
这里是 Mongo (mongoose) 等效项,它在单个元素中搜索(有效):
$elemMatch: {
from: {
$lte: moment(dateArray[0]).utc().startOf('day').format()
},
to: {
$gte: moment(dateArray[1]).utc().endOf('day').format()
}
}
我也试过这个查询,但它似乎仍然匹配 .from 和 .to 但在任何单独的 roomavailable 元素中:
index.search({
query: '',
filters: filters,
facetFilters: [roomavailable.from: 1522195200, roomavailable.to: 1524268799],
attributesToRetrieve: [
"roomavailable",
],
restrictHighlightAndSnippetArrays: true
})
我在 Algolia 上发现了一些讨论在 facetFilters 中使用 1 个括号还是 2 个括号的帖子。我都试过了。都不行。
任何建议都会很棒。谢谢!
编辑:参见关于 Algolia Discourse 的讨论:
嗨@kanec,感谢您澄清您的问题!
确实,@Alefort 的建议(在单独的索引中使用 roomavailable
)将是最简单的选择,因为我上面提到的查询肯定会 return 您想要的结果。这意味着您必须单独查询房间可用性索引才能获得可用的 ID,因此您必须使用 multiple-queries
:
https://www.algolia.com/doc/api-reference/api-methods/multiple-queries/
也就是说,我问过我们的核心 API 团队,看看是否有更合理的方法来解决这个问题,但我担心这是由于数组的性能原因导致的过滤器限制。您可以按以下方式转换您的数据结构,并将您的房间索引为 object
:
[
{
"roomavailable": {
"0": {
"_id": "rJbdWvY9M",
"from": 1522195200,
"to": 1522799999
},
"1": {
"_id": "r1H_-vKqz",
"from": 1523923200,
"to": 1524268799
}
}
}
]
因此您可以应用以下过滤器:
{
"filters": "roomavailable.0.from <= 1522195200 AND roomavailable.0.to >= 1522799999 AND roomavailable.1.from <= 1522195200 AND roomavailable.1.to >=1522900799"
}
这样做的缺点是您需要知道 roomavailable
的长度才能在 front-end 上构建搜索查询(您可以在索引时添加一个roomavailable_count
属性) 而且如果每个项目有相当多的房间,这可能会降低性能;在这种情况下,切换到专用索引完全有意义,原因如下:
- 如果您在后端频繁更新可用房间,则不会影响其他索引的构建时间
- 过滤器的性能会更好(如上所述)
- 索引策略将更容易处理
让我知道您对此有何看法,以及它是否对您有帮助。
我正在从 Mongo 迁移到 Firebase,顶部是 Algolia 以提供搜索。但是遇到了一个障碍,提出了一种类似的方法来搜索记录的各个元素。
我有一个对象可以在有空房间时存储:从和到。每条记录可以有许多单独的 from/to 组合(参见下面的示例 2)。我希望能够 运行 进行如下搜索:
roomavailable.from <= 1522195200 AND roomavailable.to >=1522900799
但只让查询搜索每个元素内的匹配项,而不是所有元素中的任何方面。 Mongo 中的元素查询就是这样工作的。但是如果我 运行 查询下面列出的记录,它将 return 记录,因为两个 roomavailable 对象满足 .from 和 .to 查询。我觉得。
有没有一种方法可以确保搜索只查找匹配个人中的一对 .from 和 .to object/element?
以下是存储在 Algolia 中的记录的相关部分,因此您可以看到结构。
"roomavailable": [
{
"_id": "rJbdWvY9M",
"from": 1522195200,
"to": 1522799999
},
{
"_id": "r1H_-vKqz",
"from": 1523923200,
"to": 1524268799
}
],
这里是 Mongo (mongoose) 等效项,它在单个元素中搜索(有效):
$elemMatch: {
from: {
$lte: moment(dateArray[0]).utc().startOf('day').format()
},
to: {
$gte: moment(dateArray[1]).utc().endOf('day').format()
}
}
我也试过这个查询,但它似乎仍然匹配 .from 和 .to 但在任何单独的 roomavailable 元素中:
index.search({
query: '',
filters: filters,
facetFilters: [roomavailable.from: 1522195200, roomavailable.to: 1524268799],
attributesToRetrieve: [
"roomavailable",
],
restrictHighlightAndSnippetArrays: true
})
我在 Algolia 上发现了一些讨论在 facetFilters 中使用 1 个括号还是 2 个括号的帖子。我都试过了。都不行。
任何建议都会很棒。谢谢!
编辑:参见关于 Algolia Discourse 的讨论:
嗨@kanec,感谢您澄清您的问题!
确实,@Alefort 的建议(在单独的索引中使用 roomavailable
)将是最简单的选择,因为我上面提到的查询肯定会 return 您想要的结果。这意味着您必须单独查询房间可用性索引才能获得可用的 ID,因此您必须使用 multiple-queries
:
https://www.algolia.com/doc/api-reference/api-methods/multiple-queries/
也就是说,我问过我们的核心 API 团队,看看是否有更合理的方法来解决这个问题,但我担心这是由于数组的性能原因导致的过滤器限制。您可以按以下方式转换您的数据结构,并将您的房间索引为 object
:
[
{
"roomavailable": {
"0": {
"_id": "rJbdWvY9M",
"from": 1522195200,
"to": 1522799999
},
"1": {
"_id": "r1H_-vKqz",
"from": 1523923200,
"to": 1524268799
}
}
}
]
因此您可以应用以下过滤器:
{
"filters": "roomavailable.0.from <= 1522195200 AND roomavailable.0.to >= 1522799999 AND roomavailable.1.from <= 1522195200 AND roomavailable.1.to >=1522900799"
}
这样做的缺点是您需要知道 roomavailable
的长度才能在 front-end 上构建搜索查询(您可以在索引时添加一个roomavailable_count
属性) 而且如果每个项目有相当多的房间,这可能会降低性能;在这种情况下,切换到专用索引完全有意义,原因如下:
- 如果您在后端频繁更新可用房间,则不会影响其他索引的构建时间
- 过滤器的性能会更好(如上所述)
- 索引策略将更容易处理
让我知道您对此有何看法,以及它是否对您有帮助。