lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Willnauer (JIRA)" <>
Subject [jira] Commented: (LUCENE-2590) Enable access to the freq information in a Query's sub-scorers
Date Mon, 23 Aug 2010 11:02:16 GMT


Simon Willnauer commented on LUCENE-2590:

Can't we simplify this? I liked your original proposal, breaking out
explicit visitRequired, visitOptional, etc., but keeping this as a
single class. Or we can go back to the original patch (just passing
an arg expressing the relationship)?

The problem leading to this quiet heavy change was that I wanted to call a specific function
for each Boolean.Occur relationship. That turned out to be ugly since I had to either add
a switch / case statement to each of the visitSubScorers methods or add  a visitSubScorers
method for each relationship. I didn't like that at all so I moved forward to specify a callback
for each relationship. I see your point of being to heavy though. I guess we should go back
to the original approach since I don't want to decide it on a switch case basis.

 also don't like the "context" approach, setting attrs on a shared
instance. This is basically setting up arguments to pass to the
callback - why not simply pass these arguments (on the stack)
Passing it on the stack has one limitation which is that if I want to pass more information
around in the future I need to change the interface while I only add a member to the "context"
if I pass it that way. Another reason was that if I want to pass custom info  from a custom
query scorer to another I can not do that since there is not context. 

One other solution would be to reduce the interface back to:
public abstract class ScorerVisitor<P extends Query, C extends Query, S extends Scorer>{
   public Occur relationship;
   public abstract void visit(P parent, C child, S childScorer);

but hold the relationship as an attribute that way we don't  have it in the method signature
which I don't like though.

I don't like the "accept" name - it's very generic - can we put this
back to visitSubScorers or something that makes it clear you're
visiting the full sub-tree (visitScorers? visitScorerTree?)?

I'm ok with visitScorers

> Enable access to the freq information in a Query's sub-scorers
> --------------------------------------------------------------
>                 Key: LUCENE-2590
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>         Attachments: LUCENE-2590.patch, LUCENE-2590.patch, LUCENE-2590.patch
> The ability to gather more details than just the score, of how a given
> doc matches the current query, has come up a number of times on the
> user's lists.  (most recently in the thread "Query Match Count" by
> Ryan McV on java-user).
> EG if you have a simple TermQuery "foo", on each hit you'd like to
> know how many times "foo" occurred in that doc; or a BooleanQuery +foo
> +bar, being able to separately see the freq of foo and bar for the
> current hit.
> Lucene doesn't make this possible today, which is a shame because
> Lucene in fact does compute exactly this information; it's just not
> accessible from the Collector.

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:
For additional commands, e-mail:

View raw message