[
https://issues.apache.org/jira/browse/SOLR-11865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16450065#comment-16450065
]
Bruno Roustant edited comment on SOLR-11865 at 4/24/18 3:37 PM:
----------------------------------------------------------------
Sorry for the delay.
Yes, if you can take it from here, that would be awesome!
* Getters for defaults: you're right, there is no need. Please remove them.
* keepElevationPriority as a constant in QEC: good point.
* keepElevationPriority meaning:
Actually the comment is not right, maybe the sorting has changed since the
time I wrote this comment. I don't think it is linked anymore to forceElevation
since the ElevationComparatorSource can be added as a SortField even if
forceElevation=false when one sorts by score.
The point is
- with keepElevationPriority=true, the behavior is unchanged, the elevated
documents (on top) are sorted by the order of the elevation rules and elevated
ids in the config file.
- with keepElevationPriority=false, the behavior changes, the elevated
documents (still on top) are in any order (this will allow the use of the
efficient but unsorted TrieSubsetMatcher in the other patch), and they may be
re-ordered by other sort fields
was (Author: bruno.roustant):
Sorry for the delay.
Yes, if you can take it from here, that would be awesome!
* Getters for defaults: you're right, there is no need. Please remove them.
* keepElevationPriority as a constant in QEC: good point.
* keepElevationPriority meaning:
Actually the comment is not right, maybe the sorting has changed since the time
I wrote this comment. I don't think it is linked anymore to forceElevation
since the ElevationComparatorSource can be added as a SortField even if
forceElevation=false when one sort by score.
The point is
- with keepElevationPriority=true, the behavior is unchanged, the elevated
documents (on top) are sorted by the order of the elevation rules and elevated
ids in the config file.
- with keepElevationPriority=false, the behavior changes, the elevated
documents (still on top) are in any order, and they may be re-ordered by other
sort fields (this will allow the use of the efficient but unsorted
TrieSubsetMatcher in the other patch).
> Refactor QueryElevationComponent to prepare query subset matching
> -----------------------------------------------------------------
>
> Key: SOLR-11865
> URL: https://issues.apache.org/jira/browse/SOLR-11865
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SearchComponents - other
> Affects Versions: master (8.0)
> Reporter: Bruno Roustant
> Priority: Minor
> Labels: QueryComponent
> Fix For: master (8.0)
>
> Attachments:
> 0001-Refactor-QueryElevationComponent-to-introduce-Elevat.patch,
> 0002-Refactor-QueryElevationComponent-after-review.patch,
> 0003-Remove-exception-handlers-and-refactor-getBoostDocs.patch,
> SOLR-11865.patch
>
>
> The goal is to prepare a second improvement to support query terms subset
> matching or query elevation rules.
> Before that, we need to refactor the QueryElevationComponent. We make it
> extendible. We introduce the ElevationProvider interface which will be
> implemented later in a second patch to support subset matching. The current
> full-query match policy becomes a default simple MapElevationProvider.
> - Add overridable methods to handle exceptions during the component
> initialization.
> - Add overridable methods to provide the default values for config properties.
> - No functional change beyond refactoring.
> - Adapt unit test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
