[
https://issues.apache.org/jira/browse/SOLR-15873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17464667#comment-17464667
]
Christine Poerschke edited comment on SOLR-15873 at 12/23/21, 5:08 PM:
-----------------------------------------------------------------------
Removing of the code could simplify the remaining code but on a practical level
(at least theoretically) backwards compatibility would also need consideration
and it's possible that some custom {{ReRankCollector}} (which we don't know of)
does for some reason use the code that would be removed.
But I think it could be done and would bring some nice code simplifications,
e.g. something like this:
* Step 1 in (say) Solr 9.0
** factor out a {{ReRankRescorer}} class tailored to the "rescore all as part
of reranking" use case
** mark any methods that will go away as deprecated
* between (say) Solr 9.0 and Solr 9.1
** custom code (which we don't know of) using the deprecated methods continues
to build and behave just like before
** custom code owners have an opportunity to adjust their code, this may
involve them "forking" the 9.0 {{LTRRescorer}} code
* Step 2 in (say) Solr 9.1
** deprecated code goes away or its signature changes
** the code simplification happens
I've had a go at trying this out (and probably should have shared the outline
above first this morning, sorry) and to illustrate will open draft pull
requests shortly.
[~abenedetti], [~4nn4r], [~diegoceccarelli] - what do you think?
was (Author: cpoerschke):
Removing of the code could simplify the remaining code but on a practical level
(at least theoretically) backwards compatibility would also need consideration
and it's possible that some custom {{ReRankCollector}} (which we don't know of)
does for some reason use the code that would be removed.
But I think it could be done and would bring some nice code simplifications,
e.g. something like this:
* Step 1 in (say) Solr 9.0
** factor out a {{ReRankRescorer}} class tailored to the "rescore all as part
of reranking" use case
** mark any methods that will go away as deprecated
* between (say) Solr 9.0 and Solr 9.1
** custom code (which we don't know of) using the deprecate methods continues
to build and behave just like before
** custom code owners have an opportunity to adjust their code, this may
involve them "forking" the 9.0 {{LTRRescorer}} code
* Step 2 in (say) Solr 9.1
** deprecated code goes away or its signature changes
** the code simplification happens
I've had a go at trying this out (and probably should have shared the outline
above first this morning, sorry) and to illustrate will open draft pull
requests shortly.
[~abenedetti] [~4nn4r] [~diegoceccarelli] - what do you think?
> simplify LTR[Interleaving]Rescorer code
> ---------------------------------------
>
> Key: SOLR-15873
> URL: https://issues.apache.org/jira/browse/SOLR-15873
> Project: Solr
> Issue Type: Task
> Components: contrib - LTR
> Reporter: Christine Poerschke
> Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> On the dev mailing list
> [https://lists.apache.org/thread/113d1yzty5ryvyt2o9msfytldv41qpgq] thread
> [~4nn4r] shared about the discovery of the
> {{org.apache.solr.ltr.LTRRescorer#scoreSingleHit}} code block and how
> {{hitUpto >= topN}} never arises and so if the piece of code be removed.
> This ticket is about removing (or maybe not) of the code block.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
