[ 
https://issues.apache.org/jira/browse/LUCENE-9439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176555#comment-17176555
 ] 

Dawid Weiss commented on LUCENE-9439:
-------------------------------------

It does, doesn't it? I am in favor of your suggestion to split the patch into 
separate two issues - makes sense. I'll do it (have an away day tomorrow but 
Friday, hopefully).

And you're right that something resembling an "end product" highlighter would 
be nice too. Although I believe part of the power is in these components being 
so nicely decoupled... You can easily build pretty much any kind of 
highlighting you wish with these... For example, I built a component that uses 
hit highlighting over several fields but always fills in certain fields with 
the default "snippet" if they're not part of the query hit.  Yes, it does 
require custom code as opposed to just configuration but it also opens up a 
great freedom of choice in how you want your highlighter to work.

I'll have to think how to best showcase this without putting everything in one 
box.

> Matches API should enumerate hit fields that have no positions (no iterator)
> ----------------------------------------------------------------------------
>
>                 Key: LUCENE-9439
>                 URL: https://issues.apache.org/jira/browse/LUCENE-9439
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Dawid Weiss
>            Assignee: Dawid Weiss
>            Priority: Minor
>         Attachments: LUCENE-9439.patch, matchhighlighter.patch
>
>          Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> I have been fiddling with Matches API and it's great. There is one corner 
> case that doesn't work for me though -- queries that affect fields without 
> positions return {{MatchesUtil.MATCH_WITH_NO_TERMS}} but this constant is 
> problematic as it doesn't carry the field name that caused it (returns null).
> The associated fromSubMatches combines all these constants into one (or 
> swallows them) which is another problem.
> I think it would be more consistent if MATCH_WITH_NO_TERMS was replaced with 
> a true match (carrying field name) returning an empty iterator (or a constant 
> "empty" iterator NO_TERMS).
> I have a very compelling use case: I wrote an "auto-highlighter" that runs on 
> top of Matches API and automatically picks up query-relevant fields and 
> snippets. Everything works beautifully except for cases where fields are 
> searchable but don't have any positions (token-like fields).
> I can work on a patch but wanted to reach out first - [~romseygeek]?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to