[
https://issues.apache.org/jira/browse/LUCENE-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901349#action_12901349
]
Simon Willnauer commented on LUCENE-2590:
-----------------------------------------
{quote}
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)?
{quote}
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.
{quote}
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)
instead?
{quote}
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:
{code}
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);
}
{code}
but hold the relationship as an attribute that way we don't have it in the
method signature which I don't like though.
{quote}
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?)?
{quote}
I'm ok with visitScorers
> Enable access to the freq information in a Query's sub-scorers
> --------------------------------------------------------------
>
> Key: LUCENE-2590
> URL: https://issues.apache.org/jira/browse/LUCENE-2590
> 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: [email protected]
For additional commands, e-mail: [email protected]
