rmuir commented on PR #12118: URL: https://github.com/apache/lucene/pull/12118#issuecomment-1413950962
> For the record this need comes from implementing sparse retrieval similarly to what's discussed at #11799, so `FeatureField` no longer stores features but regular terms here. One option is to reuse `FeatureField` for this. Another option could be to reuse `TermQuery` by configuring the `Similarity`'s `SimScorer` to properly decode the frequency. I think this is where my confusion is. Hopefully sparse retrieval is implemented in a way that doesn't require this codepath and still takes advantage of WAND-skipping. But I think this change is OK for the use-case of faceting: if you are going to put FeatureQuery in a required clause for some reason (to me this is unrelated to any sparse retrieval, an app may just want a feature to be required for a particular search), then to support facets that reflect that, you need to disable scores to count correctly. Maybe add a comment above it in the code, something like `// e.g. for faceting` so that it doesn't cause confusion. -- 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. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
