[
https://issues.apache.org/jira/browse/LUCENE-2876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984177#action_12984177
]
Robert Muir commented on LUCENE-2876:
-------------------------------------
Thanks for the review Doron!
bq. jdoc: in some of the scorer constructors a Weight param was added but
existing jdocs for the costructor which document (some) params was not updated
to also mention the weight. I am not 100% sure this should be fixed, as there
is inconsistency in the level of jdoc for scorer implementations. So if there
were no jdocs at all there I would say nothing, but since there were some now
they became less complete...
I'll fix this, thanks!
{quote}
ExactPhraseScorer is created with both Weight and Similarity - I think the
Similarity param can be removed as part of this cleanup.
Same for SloppyPhraseScorer, PhraseScorer, SpanScorer, TermScorer,
MatchAllDocsScorer - Similarity param can be removed.
{quote}
These still need the Similarity param? They use it in scoring, its just they
don't pass it to the superclass constructor (Scorer's constructor).
Its possible I misunderstood your idea though. Lets take the TermQuery example,
are you suggesting that
we should expose TermWeight's "Similarity" and just pass TermWeight to
TermScorer (requiring TermScorer
to take a TermWeight in its ctor instead of Weight + Similarity?) Currently
TermWeight's local copy of
Similarity, which it uses to compute IDF, is private.
bq. it is interesting that SloppyPhraseScorer now extends PhraseScorer but
ExactPhraseScorer does not, is this on purpose? Perhaps related do Mike's
recent optimizations in this scorer?
Yes, that's correct. Just at a glance he might have done this so that
ExactPhraseScorer can compute a
score cache like TermScorer, and other similar optimizations since the "tf"
values are really integers for
this exact case.
It might be that if we look at splitting calculations and matching out from
Scorer, that we can make
these "matchers" like ExactPhrase/SloppyPhrase simpler, and we could then clean
up... not sure though!
> Remove Scorer.getSimilarity()
> -----------------------------
>
> Key: LUCENE-2876
> URL: https://issues.apache.org/jira/browse/LUCENE-2876
> Project: Lucene - Java
> Issue Type: Task
> Components: Query/Scoring
> Reporter: Robert Muir
> Assignee: Robert Muir
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2876.patch
>
>
> Originally this was part of the patch for per-field Similarity (LUCENE-2236),
> but I pulled it
> out here as its own issue as its really mostly unrelated. I also like it as a
> separate issue
> to apply the deprecation to branch_3x to just make less surprises/migration
> hassles for 4.0 users.
> Currently Scorer takes a confusing number of ctors, either a Similarity, or a
> Weight + Similarity.
> Also, lots of scorers don't use the Similarity at all, and its not really
> needed in Scorer itself.
> Additionally, the Weight argument is often null. The Weight makes sense to be
> here in Scorer,
> its the parent that created the scorer, and used by Scorer itself to support
> LUCENE-2590's features.
> But I dont think all queries work with this feature correctly right now,
> because they pass null.
> Finally the situation gets confusing if you start to consider delegators like
> ScoreCachingWrapperScorer,
> which arent really delegating correctly so I'm unsure features like
> LUCENE-2590 aren't working with this.
> So I think we should remove the getSimilarity, if your scorer uses a
> Similarity its already coming
> to you via your ctor from your Weight and you can manage this yourself.
> Also, all scorers should pass the Weight (parent) that created them, and this
> should be Scorer's only ctor.
> I fixed all core/contrib/solr Scorers (even the internal ones) to pass their
> parent Weight, just for consistency
> of this visitor interface. The only one that passes null is Solr's
> ValueSourceScorer.
> I set fix-for 3.1, not because i want to backport anything, only to mark the
> getSimilarity deprecated there.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
