lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Sokolov (JIRA)" <>
Subject [jira] [Commented] (LUCENE-1889) FastVectorHighlighter: support for additional queries
Date Sat, 25 Jun 2011 23:55:47 GMT


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:
>             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:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message