atris edited a comment on issue #1303: LUCENE-9114: Improve ValueSourceScorer's Default Cost Implementation URL: https://github.com/apache/lucene-solr/pull/1303#issuecomment-594352993 > OH; an idea occurred to me. We don't actually need the cost to be mutable (which wasn't so pretty), we just need a matchCost that a ValueSourceScorer can choose to provide if it wants (which you just did). This way if someone (like Solr) wants to force the cost, it could wrap the original ValueSource to supply to FunctionRangeQuery -- one with a FunctionValues that overrides getRangeScorer to wrap subclass VSC to specify the cost. I know this is more code than the mutable cost but isn't as bad as what I was originally fearing, having to total black box, wrap a query, weight, scorer, etc. Perhaps this wrapping might even be a static convenience method on FunctionRangeQuery that takes in a VS & cost and returns a VS that is only to be used by FRQ. @dsmiley , Agreed. I believe that the semantics here are completely driven from the use cases -- and yours is the use case we are chasing right now :) If the tradeoff of defining a new VS which overrides the cost method is fine, I am more than happy to remove the mutable cost. Raised an iteration for the same, please see and let me know your thoughts and comments.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
