[jira] [Commented] (LUCENE-8268) MatchesIterator.term() should return an array
[ https://issues.apache.org/jira/browse/LUCENE-8268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16448218#comment-16448218 ] Adrien Grand commented on LUCENE-8268: -- What I meant is that if you run "(a OR b) NEAR c" with an IntervalQuery, you would only have one query, the top-level IntervalQuery since inner nodes are IntervalsSource instances. So you won't be able to distinguish matches against "a" from matches against "b". > MatchesIterator.term() should return an array > - > > Key: LUCENE-8268 > URL: https://issues.apache.org/jira/browse/LUCENE-8268 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8268.patch, LUCENE-8268.patch > > > At the moment, we return a single BytesRef from MatchesIterator.term(), which > works well for the queries that currently implement this. This won't be > enough for queries that operate on more than one term, however, such as > phrase or Span queries. > In preparation for LUCENE-8249, this issue will change the method to return > an array of BytesRef -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8268) MatchesIterator.term() should return an array
[ https://issues.apache.org/jira/browse/LUCENE-8268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16448211#comment-16448211 ] Alan Woodward commented on LUCENE-8268: --- bq. since inner nodes are not queries? Sorry, I'm not following here - inner nodes are always generated by a Weight, which in turn has a parent query. bq. Maybe we should just remove this method for now I think that may be the most sensible, I'll close this as Won't Fix and open a new issue to just remove it entirely. > MatchesIterator.term() should return an array > - > > Key: LUCENE-8268 > URL: https://issues.apache.org/jira/browse/LUCENE-8268 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8268.patch, LUCENE-8268.patch > > > At the moment, we return a single BytesRef from MatchesIterator.term(), which > works well for the queries that currently implement this. This won't be > enough for queries that operate on more than one term, however, such as > phrase or Span queries. > In preparation for LUCENE-8249, this issue will change the method to return > an array of BytesRef -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8268) MatchesIterator.term() should return an array
[ https://issues.apache.org/jira/browse/LUCENE-8268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16448190#comment-16448190 ] Adrien Grand commented on LUCENE-8268: -- Returning a query means that intervals won't be able to say what matched, since inner nodes are not queries? Maybe we should just remove this method for now and add something back when use-cases for it are clearer? > MatchesIterator.term() should return an array > - > > Key: LUCENE-8268 > URL: https://issues.apache.org/jira/browse/LUCENE-8268 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8268.patch, LUCENE-8268.patch > > > At the moment, we return a single BytesRef from MatchesIterator.term(), which > works well for the queries that currently implement this. This won't be > enough for queries that operate on more than one term, however, such as > phrase or Span queries. > In preparation for LUCENE-8249, this issue will change the method to return > an array of BytesRef -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8268) MatchesIterator.term() should return an array
[ https://issues.apache.org/jira/browse/LUCENE-8268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16448159#comment-16448159 ] Alan Woodward commented on LUCENE-8268: --- Here's a patch removing term() and adding getLeafQuery() > MatchesIterator.term() should return an array > - > > Key: LUCENE-8268 > URL: https://issues.apache.org/jira/browse/LUCENE-8268 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8268.patch, LUCENE-8268.patch > > > At the moment, we return a single BytesRef from MatchesIterator.term(), which > works well for the queries that currently implement this. This won't be > enough for queries that operate on more than one term, however, such as > phrase or Span queries. > In preparation for LUCENE-8249, this issue will change the method to return > an array of BytesRef -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8268) MatchesIterator.term() should return an array
[
https://issues.apache.org/jira/browse/LUCENE-8268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16447948#comment-16447948
]
Simon Willnauer commented on LUCENE-8268:
-
{quote}
So at the moment there isn't anything that actually uses this. My reason for
adding it was to make it possible to identify the leaf query that returned each
position, but maybe it would be a better idea to remove terms() entirely, and
add a getLeafQuery() method instead?
{quote}
hard to tell since I don't know the API well enough. But if this is the
purpose, I agree.
> MatchesIterator.term() should return an array
> -
>
> Key: LUCENE-8268
> URL: https://issues.apache.org/jira/browse/LUCENE-8268
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8268.patch
>
>
> At the moment, we return a single BytesRef from MatchesIterator.term(), which
> works well for the queries that currently implement this. This won't be
> enough for queries that operate on more than one term, however, such as
> phrase or Span queries.
> In preparation for LUCENE-8249, this issue will change the method to return
> an array of BytesRef
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8268) MatchesIterator.term() should return an array
[ https://issues.apache.org/jira/browse/LUCENE-8268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16447802#comment-16447802 ] Alan Woodward commented on LUCENE-8268: --- bq. Can we add a users of multiple terms? So at the moment there isn't anything that actually uses this. My reason for adding it was to make it possible to identify the leaf query that returned each position, but maybe it would be a better idea to remove terms() entirely, and add a getLeafQuery() method instead? > MatchesIterator.term() should return an array > - > > Key: LUCENE-8268 > URL: https://issues.apache.org/jira/browse/LUCENE-8268 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8268.patch > > > At the moment, we return a single BytesRef from MatchesIterator.term(), which > works well for the queries that currently implement this. This won't be > enough for queries that operate on more than one term, however, such as > phrase or Span queries. > In preparation for LUCENE-8249, this issue will change the method to return > an array of BytesRef -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8268) MatchesIterator.term() should return an array
[ https://issues.apache.org/jira/browse/LUCENE-8268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16447779#comment-16447779 ] Simon Willnauer commented on LUCENE-8268: - a couple of questions: * in _compareBytesRefArrays_ how can you tell that comparing each individual term is correct? * is _BytesRefIterator_ an option as a return value and would it make sense. It's hart do tell without a single user of this. * In the current context there is no gain changing this interface. Can we add a users of multiple terms? > MatchesIterator.term() should return an array > - > > Key: LUCENE-8268 > URL: https://issues.apache.org/jira/browse/LUCENE-8268 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8268.patch > > > At the moment, we return a single BytesRef from MatchesIterator.term(), which > works well for the queries that currently implement this. This won't be > enough for queries that operate on more than one term, however, such as > phrase or Span queries. > In preparation for LUCENE-8249, this issue will change the method to return > an array of BytesRef -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8268) MatchesIterator.term() should return an array
[
https://issues.apache.org/jira/browse/LUCENE-8268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16447768#comment-16447768
]
Alan Woodward commented on LUCENE-8268:
---
Patch attached. It changes the signature from {code}BytesRef term(){code} to
{code}BytesRef[] terms(){code}, and adds a test to ensure that matches at the
same position are iterated over in term order.
> MatchesIterator.term() should return an array
> -
>
> Key: LUCENE-8268
> URL: https://issues.apache.org/jira/browse/LUCENE-8268
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8268.patch
>
>
> At the moment, we return a single BytesRef from MatchesIterator.term(), which
> works well for the queries that currently implement this. This won't be
> enough for queries that operate on more than one term, however, such as
> phrase or Span queries.
> In preparation for LUCENE-8249, this issue will change the method to return
> an array of BytesRef
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
