[ https://issues.apache.org/jira/browse/LUCENE-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771458#action_12771458 ]
Mark Miller commented on LUCENE-2013: ------------------------------------- Nice catch - I think I like this method better than the core modifications. bq. but this also means that no third-party queries have any way to influence their highlighting. Unfortunately, I think thats already the deal in many cases. The Highlighter is very special case - ugly, but the current state of things. We will hopefully get away from that eventually. > QueryScorer and SpanRegexQuery are incompatible. > ------------------------------------------------ > > Key: LUCENE-2013 > URL: https://issues.apache.org/jira/browse/LUCENE-2013 > Project: Lucene - Java > Issue Type: Bug > Components: contrib/highlighter > Affects Versions: 2.9 > Environment: Lucene-Java 2.9 > Reporter: Benjamin Keil > Fix For: 3.0 > > Attachments: lucene-2013-2009-10-28-2135.patch, > lucene-2013-2009-10-28.patch, lucene-2013-2009-10-29-0136.patch, > LUCENE-2013.patch > > > Since the resolution of #LUCENE-1685, users are not supposed to rewrite their > queries before submitting them to QueryScorer: > bq.------------------------------------------------------------------------ > bq.r800796 | markrmiller | 2009-08-04 06:56:11 -0700 (Tue, 04 Aug 2009) | 1 > line > bq. > bq.LUCENE-1685: The position aware SpanScorer has become the default scorer > for Highlighting. The SpanScorer implementation has replaced QueryScorer and > the old term highlighting QueryScorer has been renamed to QueryTermScorer. > Multi-term queries are also now expanded by default. If you were previously > rewritting the query for multi-term query highlighting, you should no longer > do that (unless you switch to using QueryTermScorer). The SpanScorer API (now > QueryScorer) has also been improved to more closely match the API of the > previous QueryScorer implementation. > bq.------------------------------------------------------------------------ > This is a great convenience for the most part, but it's causing me > difficulties with SpanRegexQuerys, as the WeightedSpanTermExtractor uses > Query.extractTerms() to collect the fields used in the query, but > SpanRegexQuery does not implement this method, so highlighting any query with > a SpanRegexQuery throws an UnsupportedOpertationException. If this issue is > circumvented, there is still the issue of SpanRegexQuery throwing an > exception when someone calls its getSpans() method. > I can provide the patch that I am currently using, but I'm not sure that my > solution is optimal. It adds two methods to SpanQuery: > extractFields(Set<String> fields) which is equivalent to > fields.add(getField()) except when MaskedFieldQuerys get involved, and > mustBeRewrittenToGetSpans() which returns true for SpanQuery, false for > SpanTermQuery, and is overridden in each composite SpanQuery to return a > value depending on its components. In this way SpanRegexQuery (and any other > custom SpanQuerys) do not need to be adjusted. > Currently the collection of fields and non-weighted terms are done in a > single step. In the proposed patch the WeightedSpanTerm extraction from a > SpanQuery proceeds in two steps. First, if the QueryScorer's field is null, > then the fields are collected from the SpanQuery using the extractFields() > method. Second the terms are collected using extractTerms(), rewriting the > query for each field if mustBeRewrittenToGetSpans() returns true. -- 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: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org