[
https://issues.apache.org/jira/browse/LUCENE-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13054985#comment-13054985
]
Mike Sokolov commented on LUCENE-1889:
--------------------------------------
No, no range queries, sorry. I don't think that's easily expressible as a
regex? So it would add probably require yet another data structure in
FieldQuery - right now we have Map<String,QueryPhraseMap> for TermQuery; I've
added a List<QueryPhraseMap> and QPM.Pattern for matching wildcards and
regexes. To handle RangeQuery, you'd need to add another such data structure:
it would probably be best to introduce some new abstraction to represent all of
these query-proxies.
It seemed a less useful case to me anyway since we don't usually use range
queries in the context of full text; more often they come up in structured
metadata? Curious if you have requests for that?
Anyway I will clean up a bit and post.
> FastVectorHighlighter: support for additional queries
> -----------------------------------------------------
>
> Key: LUCENE-1889
> URL: https://issues.apache.org/jira/browse/LUCENE-1889
> Project: Lucene - Java
> Issue Type: Wish
> Components: modules/highlighter
> Reporter: Robert Muir
> Priority: Minor
>
> I am using fastvectorhighlighter for some strange languages and it is working
> well!
> One thing i noticed immediately is that many query types are not highlighted
> (multitermquery, multiphrasequery, etc)
> Here is one thing Michael M posted in the original ticket:
> {quote}
> I think a nice [eventual] model would be if we could simply re-run the
> scorer on the single document (using InstantiatedIndex maybe, or
> simply some sort of wrapper on the term vectors which are already a
> mini-inverted-index for a single doc), but extend the scorer API to
> tell us the exact term occurrences that participated in a match (which
> I don't think is exposed today).
> {quote}
> Due to strange requirements I am using something similar to this (but
> specialized to our case).
> I am doing strange things like forcing multitermqueries to rewrite into
> boolean queries so they will be highlighted,
> and flattening multiphrasequeries into boolean or'ed phrasequeries.
> I do not think these things would be 'fast', but i had a few ideas that might
> help:
> * looking at contrib/highlighter, you can support FilteredQuery in flatten()
> by calling getQuery() right?
> * maybe as a last resort, try Query.extractTerms() ?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
