[
https://issues.apache.org/jira/browse/LUCENE-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100888#comment-13100888
]
Mike Sokolov commented on LUCENE-1889:
--------------------------------------
I'm a little out of my depth here, but it appears from poking around in svn
history that the field name got pulled up in to MTQ from its subclasses when
the "flex_1458" branch was merged in, and I guess that hasn't happened in 3.x?
So it looks to me that the only way to get this change into 3.x is either to do
the same kind of refactoring that was done in that branch, or to go back to
special-casing all the different MTQs. (ie something like:
{code}
else if (query instanceof WildcardQuery) {
return ((WildcardQuery)query).getField();
}
else if (query instanceof PrefixQuery) {
return ((PrefixQuery)query).getField();
}
etc...
{code}
sorry - I didn't realize the patch relied on something only in trunk. That
branch was merged in a year and a half ago now, but I guess it must include
enough major changes that it's difficult to back-port.
> 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
> Attachments: LUCENE-1889.patch, LUCENE-1889.patch, LUCENE-1889.patch
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
