[
https://issues.apache.org/jira/browse/LUCENE-3318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066350#comment-13066350
]
Hoss Man commented on LUCENE-3318:
----------------------------------
I think rmuir's point is that at a Java class level, we already have a
highlighter that can do this.
If we add a new XyzBasedHighlighter class that can take advantage of some new
XYZ information that can be recorded at index time, it's better for that
highlighter to fail fast if the Xyz info isn't actually in the index -- if you
want term vectors or re-analysis as a fall back, then make that decision in
your code when you call XyzBasedHighlighter.getHighlights().
i don't really know anything about the existing Highlighter impl, but i agree
with that philosophy at the Java API level
(At a Solr API level there are a lot more options. the naive API is to make
the user pick an impl and fail if it doesn't work, but alternately we could
pick the impl based on what options are used on the fields being indexed,
etc...)
> Sketch out highlighting based on term positions / position iterators
> --------------------------------------------------------------------
>
> Key: LUCENE-3318
> URL: https://issues.apache.org/jira/browse/LUCENE-3318
> Project: Lucene - Java
> Issue Type: Sub-task
> Components: modules/highlighter
> Affects Versions: Positions Branch
> Reporter: Simon Willnauer
> Assignee: Mike Sokolov
> Fix For: Positions Branch
>
>
> Spinn off from LUCENE-2878. Since we have positions on a large number of
> queries already in the branch is worth looking at highlighting as a real
> consumer of the API. A prototype is already committed.
--
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
