[
https://issues.apache.org/jira/browse/LUCENE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14217002#comment-14217002
]
Martin Braun edited comment on LUCENE-6061 at 11/18/14 11:08 PM:
-----------------------------------------------------------------
Well I am doing the synonym approach for other parts already, but I think the
FastVectorHighlighter approach is better as it does exactly the part with "when
I highlight field X, load its content from field Y", but I just want it to be
able to render into arbitrary objects (or in my case I just want the plain
offsets).
I am currently working on a more sophisticated approach that lets me search for
more information about one single token (I am reindexing the document's tokens
into a new index with all it's occurences (offsets) by using the same analyzer
chain that the complete documents use and extracting the attributes. (I think
it's similar to the approach PH uses? But with storing the results into an
index) Like that I can implement a cool way of handling synonym searching as
well) and this enables me to do highlighting without the need of one of the
Highlighters in Lucene so I am not that dependent on the Highlighting API
anymore.
But I think I might need the Highlighter API some time in the near future so I
am keeping my _FastVectorHighlighterUtil_
Generally I just want to make the Highlighter API (I am talking about
_FastVectorHighlighter_ here) easier to use and more intuitive than what I
would need to do with the indexing trick.
was (Author: s4ke):
Well I am doing the synonym approach for other parts already, but I think the
FastVectorHighlighter approach is better as it does exactly the part with "when
I highlight field X, load its content from field Y", but I just want it to be
able to render into arbitrary objects (or in my case I just want the plain
offsets).
I am currently working on a more sophisticated approach that lets me search for
more information about one single token (I am reindexing the document's tokens
into a new index with all it's occurences (offsets) by using the same analyzer
chain that the complete documents use and extracting the attributes. Like that
I can implement a cool way of handling synonym searching as well) and enables
me to do highlighting as well (I think it's similar to the approach PH uses?
But with storing the results into an index) so I am not that dependent on the
Highlighting API anymore.
Generally I just want to make the Highlighter API (I am talking about
_FastVectorHighlighter_ here) easier to use and more intuitive than what I
would need to do with the indexing trick.
> Add Support for something different than Strings in Highlighting
> (FastVectorHighlighter)
> ----------------------------------------------------------------------------------------
>
> Key: LUCENE-6061
> URL: https://issues.apache.org/jira/browse/LUCENE-6061
> Project: Lucene - Core
> Issue Type: Wish
> Components: core/search, modules/highlighter
> Affects Versions: Trunk
> Reporter: Martin Braun
> Priority: Critical
> Labels: FastVectorHighlighter, Highlighter, Highlighting
> Fix For: 4.10.2, 5.0, Trunk
>
>
> In my application I need Highlighting and I stumbled upon the really neat
> FastVectorHighlighter. One problem appeared though. It lacks a way to render
> the Highlights into something different than Strings, so I rearranged some of
> the code to support that:
> https://github.com/Hotware/LuceneBeanExtension/blob/master/src/main/java/de/hotware/lucene/extension/highlight/FVHighlighterUtil.java
> Is there a specific reason to only support String[] as a return type? If not,
> I would be happy to write a new class that supports rendering into a generic
> Type and rewire that into the existing class (or just do it as an addition
> and leave the current class be).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
