atris commented on issue #1303: LUCENE-9114: Improve ValueSourceScorer's Default Cost Implementation URL: https://github.com/apache/lucene-solr/pull/1303#issuecomment-594105306 > Ehh; nevermind my ill-thought-out idea of a cost on the Map context. There are many ValueSource.getValues impls that'd need to parse it, and then there's a concern that we wouldn't want it to propagate to sub-FunctionValues. > > Alternative proposal: When FunctionRangeQuery calls functionValues.getRangeScorer, it gets back a ValueSourceScorer. We could just add a mutable cost on VSC that if set will be returned by VSC and if not VSC will delegate to the proposed `FV.cost`. While the mutability of it isn't pretty, it's also quite minor. It saves FRQ from having to wrap the scorer only to specify a matchCost. Yeah, I had a similar idea but the per VS implementations' need for parsing was putting off. I am not a fan of the intrusive mutability ability but agree that it is the cleanest thing to do to support this functionality while not needing to define a cost model for every FV implementation in this PR. As a follow up to this PR, I plan to define cost models for DoubleValuesSource, IntFieldSource etc. Raised another iteration with the said approach. I am not sure how to comprehensively write a test for this functionality -- but Lucene and Solr test suites pass with this commit. 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
