[
https://issues.apache.org/jira/browse/LUCENE-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17207983#comment-17207983
]
Michael McCandless commented on LUCENE-9560:
--------------------------------------------
+1 to make this simpler. The common solution of the (inefficient, doubly
indexed) {{all}} field that apps are forced to use today is not a great
solution.
A position-aware term query (and e.g. phrase query?) would let you stop
double-indexing, but pay some small search-time performance since positions
must be decoded while searching even for non-positional (term) query.
I think the fun/challenging part of this is how to know which fields mapped to
which token positions while indexing? Apps could statically assign positions
to fields (field "title" gets 0-1000, field "body" gets 1000 - 6000, etc.)?
Or, they could do it dynamically, but then every document must record its own
"position to field" mapping and then at search time, decode that encoding.
This does perfect for interval queries, but, which interval query could we
(dynamically?) feed position constraints to? Maybe we would just need our own
{{IntervalsSource}} filter?
> Position aware TermQuery
> ------------------------
>
> Key: LUCENE-9560
> URL: https://issues.apache.org/jira/browse/LUCENE-9560
> Project: Lucene - Core
> Issue Type: New Feature
> Components: core/search
> Reporter: Haoyu Zhai
> Priority: Major
>
> In our work, we index most of our fields into an "all" field (like
> elasticsearch) to make our search faster. But at the same time we still want
> to support some of the field specific search (like {{title}}), so currently
> our solution is to double index them so that we could do both "all" search as
> well as specific field search.
> I want to propose a new term query that accept a range in a specific field to
> search so that we could search on "all" field but act like a field specific
> search. Then we need not to doubly index those field.
--
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
