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

Robert Muir commented on LUCENE-6412:
-------------------------------------

Lemme expand a little more on what I think is a good path:

We fix the spans first before committing any major decision decisions with 
regards to query proximity support. Spans need work but 
[[email protected]] completely revived them, and there is a base of users 
already using them. They are already in the nightly benchmark (this should be 
improved). They already have a test suite of expected behavior and have been 
around for a long time.

We try to "drop" Spans down to Scorer. This means spans still keep their 
external API (at first) and we just fix things behind the scenes. This might 
involve making compromises, like deferring/sandboxing legacy payloads support 
and keeping it on the old spans API. I think a goal must be that PhraseScorer 
and SloppyPhraseScorer cutover to the new api without performance regressions 
before declaring success. 

If i thought things were ready today, I'd be benchmarking removal of 
Scorer.freq() and addition of 
Scorer.nextStartPosition()/startPosition()/endPosition(). But we don't have 
spans "up to speed" yet: there are large issues like completion of two-phase 
support, payloads, test coverage, benchmarking improvements that still remain. 
We need to do that first before deciding on proximity apis for the core search 
apis like Scorer, and we now have a good place to do it.


> Merge SpanTermQuery into TermQuery
> ----------------------------------
>
>                 Key: LUCENE-6412
>                 URL: https://issues.apache.org/jira/browse/LUCENE-6412
>             Project: Lucene - Core
>          Issue Type: Improvement
>    Affects Versions: Trunk, 5.2
>            Reporter: Alan Woodward
>            Priority: Minor
>         Attachments: LUCENE-6412.patch
>
>
> Having a separate SpanTermQuery doesn't actually gain us anything now, and 
> it's trivial enough to make TermQuery extend SpanQuery copy the getSpans() 
> and getField() impls over from STQ.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to