lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Braun (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LUCENE-6061) Add Support for something different than Strings in Highlighting (FastVectorHighlighter)
Date Tue, 18 Nov 2014 23:09:36 GMT

    [ 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:09 PM:
-----------------------------------------------------------------

Well I am doing the synonym approach for other parts of my analysis 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. (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.

> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message