申请人的相关性需要根据当月的可用性%进行排序。首先,可用率超过60%的申请人应该来,然后可用率低于60%的申请人应该来。
我正在尝试使用的fluent dsl查询使用elasticsearch.net
var response = await
_elasticClient.SearchAsync<ApplicantsWithDetailsResponse>(s =>
s.Aggregations(a => a
.Filter("higer_average", f => f.Filter(fd => fd.Range(r => r.Field(p
=> p.AvailablePercentage).GreaterThanOrEquals(60).Boost(5))))
.Filter("lower_average", f => f.Filter(fd => fd.Range(r => r.Field(p
=> p.AvailablePercentage).GreaterThan(0).LessThan(60).Boost(3)))
)));
或者
var response = await _elasticClient.SearchAsync<ApplicantsWithDetailsResponse>(
s => s
.Query(q => q
.Bool(p =>
p.Must(queryFilter => queryFilter.MatchAll())
.Filter(f => f.Range(r => r.Field("AvailablePercentage").GreaterThanOrEquals(60)))
.Boost(5)
.Filter(f => f.Range(r => r.Field("AvailablePercentage").GreaterThan(0).LessThan(60)))
.Boost(1.2)
)));
申请人的名单不符合逻辑。他们混合在一起。
即使我尝试过滤只显示大于60的值,这也不起作用
1条答案
按热度按时间toiithl61#
你的问题不正确;它序列化为
升压作用于整个系统
bool
查询最后
Filter
“指定”将覆盖以前的任何筛选器过滤器是
and
埃德,所以所有人都需要满足于比赛在开发过程中,观察客户端发送给elasticsearch的json是很有用的。有很多方法可以做到这一点,其中一个有用的方法是
这将把所有请求和响应写到控制台。请注意,您可能不希望在生产环境中为每个请求都这样做,因为以这种方式缓冲请求和响应会带来性能开销。
您的查询应该类似于
它发出以下查询
将范围查询与
should
子句,并指定至少有一个必须与using匹配MinimumShouldMatch
. 这是必要的,因为存在must
子句,这意味着should
从句对文档起到增强信号的作用,但是文档不必满足任何一个从句就可以被认为是匹配的。与MinimumShouldMatch
设置为1时,至少有一个should
条款必须满足才能被视为匹配。自从
must
子句是match_all
在这种情况下,我们可以省略它并删除它MinimumShouldMatch
. 一should
不带a的子句must
子句表示至少有一个子句必须匹配。为了简洁起见,我们还可以使用操作符重载来组合查询。最后的查询看起来像
它发出查询