Solr: How to dynamically elevate limited number of documents? Has QueryElevationComponent to be modified?(Solr:如何动态提升有限数量的文档?QueryElevationComponent 是否需要修改?)
问题描述
我的要求是针对用户请求提升有限数量(例如五个)文档.
my requirement is to elevate a limited number of (e.g. five) documents for a user request.
我得到的是一个单独的文档字段,它存储了一个类似于表示电梯排名值的提升值的数值.
What I've got is a single document field which stores a numerical value similar to a boosting value which represents an elevator ranking value.
因此,用户查询将返回电梯排名值最高的 5 个文档,其余文档按常规顺序填充页面.
So a user query would return 5 documents with the highest elevator ranking value and the remaining documents to fill a page in regular order.
怎么做?
QueryElevationComponent
只允许static 查询定义.提升不允许提升特殊电梯排名字段的有限数量文档.
The QueryElevationComponent
does only allow static query definitions. Boosting does not allow to boost a limited number of documents for the special elevator ranking field.
我必须编写修改后的 QueryElevationComponent 吗?如果是,有没有好的示例如何做到这一点?
Do I have to write a modified QueryElevationComponent? If yes, are there good examples how to do that?
或者是否存在另一种方法,我没有赶上?
Or does another approach exists, I didnt catched up?
感谢您的任何提示或想法!
Thank you for any hints or ideas!
推荐答案
使用两个单独的请求找到了解决方案.
Found a solution using two separate requests.
首先按该分数字段提升文档.使用分页来限制结果.从结果页面中获取唯一的文档 ID,并在新请求中显式提升这些 ID.
First boost documents by that score field. Use pagination to limit the result. Take the unique document ids from the result page and boost these ones explicitly within a new request.
这篇关于Solr:如何动态提升有限数量的文档?QueryElevationComponent 是否需要修改?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持编程学习网!
本文标题为:Solr:如何动态提升有限数量的文档?QueryElevationComponent 是否需要修改?
基础教程推荐
- 减少 JVM 暂停时间 >1 秒使用 UseConcMarkSweepGC 2022-01-01
- 设置 bean 时出现 Nullpointerexception 2022-01-01
- Java Keytool 导入证书后出错,"keytool error: java.io.FileNotFoundException &拒绝访问" 2022-01-01
- 在 Libgdx 中处理屏幕的正确方法 2022-01-01
- 如何使用 Java 创建 X509 证书? 2022-01-01
- 无法使用修饰符“public final"访问 java.util.Ha 2022-01-01
- FirebaseListAdapter 不推送聊天应用程序的单个项目 - Firebase-Ui 3.1 2022-01-01
- 降序排序:Java Map 2022-01-01
- Java:带有char数组的println给出乱码 2022-01-01
- “未找到匹配项"使用 matcher 的 group 方法时 2022-01-01