[ 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