[jira] [Commented] (SOLR-13904) Make Analytics component aware of timeAllowed
[ https://issues.apache.org/jira/browse/SOLR-13904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16971021#comment-16971021 ] Mikhail Khludnev commented on SOLR-13904: - I don't know. Legacy apps, perhaps. > Make Analytics component aware of timeAllowed > - > > Key: SOLR-13904 > URL: https://issues.apache.org/jira/browse/SOLR-13904 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Priority: Major > Attachments: SOLR-13904.patch, SOLR-13904.patch > > -- 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
[jira] [Comment Edited] (SOLR-13904) Make Analytics component aware of timeAllowed
[ https://issues.apache.org/jira/browse/SOLR-13904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16970864#comment-16970864 ] Mikhail Khludnev edited comment on SOLR-13904 at 11/10/19 5:46 AM: --- Attaching rough cut. It's works, I'll make it more reproducible. [~dpgove], [~houstonputman], what's your take on that? was (Author: mkhludnev): Attaching rough cut. It's works, I'll make it more reproducible. [~dpgove], [~houstonputman], what's you take on that? > Make Analytics component aware of timeAllowed > - > > Key: SOLR-13904 > URL: https://issues.apache.org/jira/browse/SOLR-13904 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Priority: Major > Attachments: SOLR-13904.patch, SOLR-13904.patch > > -- 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
[jira] [Updated] (SOLR-13904) Make Analytics component aware of timeAllowed
[ https://issues.apache.org/jira/browse/SOLR-13904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-13904: Attachment: SOLR-13904.patch Status: Open (was: Open) Attaching rough cut. It's works, I'll make it more reproducible. [~dpgove], [~houstonputman], what's you take on that? > Make Analytics component aware of timeAllowed > - > > Key: SOLR-13904 > URL: https://issues.apache.org/jira/browse/SOLR-13904 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Priority: Major > Attachments: SOLR-13904.patch, SOLR-13904.patch > > -- 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
[jira] [Commented] (SOLR-13911) Support missing() aggregation in JSON facet module
[
https://issues.apache.org/jira/browse/SOLR-13911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16970848#comment-16970848
]
Mikhail Khludnev commented on SOLR-13911:
-
+1
> Support missing() aggregation in JSON facet module
> --
>
> Key: SOLR-13911
> URL: https://issues.apache.org/jira/browse/SOLR-13911
> Project: Solr
> Issue Type: Sub-task
> Components: Facet Module
>Reporter: Munendra S N
>Priority: Major
> Attachments: SOLR-11695.patch
>
>
> Add {{missing()}} aggregation in JSON Facet module similar to
> StatsComponent's missing
--
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
[jira] [Commented] (SOLR-13904) Make Analytics component aware of timeAllowed
[
https://issues.apache.org/jira/browse/SOLR-13904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16969913#comment-16969913
]
Mikhail Khludnev commented on SOLR-13904:
-
Attached patch let to interrupt long analytics computation, but now it causes
500 and NPE somewhere around {{AnalyticsShardResponseWriter.write()}}
> Make Analytics component aware of timeAllowed
> -
>
> Key: SOLR-13904
> URL: https://issues.apache.org/jira/browse/SOLR-13904
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13904.patch
>
>
--
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
[jira] [Updated] (SOLR-13904) Make Analytics component aware of timeAllowed
[ https://issues.apache.org/jira/browse/SOLR-13904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-13904: Attachment: SOLR-13904.patch > Make Analytics component aware of timeAllowed > - > > Key: SOLR-13904 > URL: https://issues.apache.org/jira/browse/SOLR-13904 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Priority: Major > Attachments: SOLR-13904.patch > > -- 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
[jira] [Moved] (SOLR-13904) Make Analytics component aware of timeAllowed
[ https://issues.apache.org/jira/browse/SOLR-13904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev moved LUCENE-9039 to SOLR-13904: - Key: SOLR-13904 (was: LUCENE-9039) Lucene Fields: (was: New) Project: Solr (was: Lucene - Core) Security: Public > Make Analytics component aware of timeAllowed > - > > Key: SOLR-13904 > URL: https://issues.apache.org/jira/browse/SOLR-13904 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Priority: Major > -- 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
[jira] [Updated] (LUCENE-9039) Make Analytics component aware of timeAllowed
[ https://issues.apache.org/jira/browse/LUCENE-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9039: - Parent: (was: LUCENE-9036) Issue Type: Improvement (was: Sub-task) > Make Analytics component aware of timeAllowed > - > > Key: LUCENE-9039 > URL: https://issues.apache.org/jira/browse/LUCENE-9039 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Mikhail Khludnev >Priority: Major > -- 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
[jira] [Created] (LUCENE-9039) Make Analytics component aware of timeAllowed
Mikhail Khludnev created LUCENE-9039: Summary: Make Analytics component aware of timeAllowed Key: LUCENE-9039 URL: https://issues.apache.org/jira/browse/LUCENE-9039 Project: Lucene - Core Issue Type: Sub-task Reporter: Mikhail Khludnev -- 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
[jira] [Commented] (LUCENE-9036) ExitableDirectoryReader to interrupt DocValues as well
[ https://issues.apache.org/jira/browse/LUCENE-9036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16969906#comment-16969906 ] Mikhail Khludnev commented on LUCENE-9036: -- I decided to postpone Analytics component coverage, turns out it fails with NPE on timeout. I file an dedicated issue. > ExitableDirectoryReader to interrupt DocValues as well > -- > > Key: LUCENE-9036 > URL: https://issues.apache.org/jira/browse/LUCENE-9036 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Mikhail Khludnev >Priority: Major > Attachments: LUCENE-9036.patch, LUCENE-9036.patch, LUCENE-9036.patch > > > This allow to make AnalyticsComponent and json.facet sensitive to time > allowed. > Does it make sense? Is it enough to check on DV creation ie per field/segment > or it's worth to check every Nth doc? -- 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
[jira] [Updated] (LUCENE-9036) ExitableDirectoryReader to interrupt DocValues as well
[ https://issues.apache.org/jira/browse/LUCENE-9036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9036: - Attachment: LUCENE-9036.patch Status: Patch Available (was: Patch Available) > ExitableDirectoryReader to interrupt DocValues as well > -- > > Key: LUCENE-9036 > URL: https://issues.apache.org/jira/browse/LUCENE-9036 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Mikhail Khludnev >Priority: Major > Attachments: LUCENE-9036.patch, LUCENE-9036.patch, LUCENE-9036.patch > > > This allow to make AnalyticsComponent and json.facet sensitive to time > allowed. > Does it make sense? Is it enough to check on DV creation ie per field/segment > or it's worth to check every Nth doc? -- 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
[jira] [Updated] (LUCENE-9036) ExitableDirectoryReader to interrupt DocValues as well
[ https://issues.apache.org/jira/browse/LUCENE-9036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9036: - Attachment: LUCENE-9036.patch Status: Patch Available (was: Patch Available) > ExitableDirectoryReader to interrupt DocValues as well > -- > > Key: LUCENE-9036 > URL: https://issues.apache.org/jira/browse/LUCENE-9036 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Mikhail Khludnev >Priority: Major > Attachments: LUCENE-9036.patch, LUCENE-9036.patch > > > This allow to make AnalyticsComponent and json.facet sensitive to time > allowed. > Does it make sense? Is it enough to check on DV creation ie per field/segment > or it's worth to check every Nth doc? -- 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
[jira] [Commented] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16969002#comment-16969002 ] Mikhail Khludnev commented on LUCENE-9031: -- I think I disable MTQ Intervals test, commit it as-is unless [~romseygeek] provide more ideas, and address MTQ later, it won't be easy. > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch, LUCENE-9031.patch, LUCENE-9031.patch, > LUCENE-9031.patch, LUCENE-9031.patch, LUCENE-9031.patch > > Time Spent: 1.5h > Remaining Estimate: 0h > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Updated] (LUCENE-9036) ExitableDirectoryReader to interrupt DocValues as well
[ https://issues.apache.org/jira/browse/LUCENE-9036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9036: - Status: Patch Available (was: Open) > ExitableDirectoryReader to interrupt DocValues as well > -- > > Key: LUCENE-9036 > URL: https://issues.apache.org/jira/browse/LUCENE-9036 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Mikhail Khludnev >Priority: Major > Attachments: LUCENE-9036.patch > > > This allow to make AnalyticsComponent and json.facet sensitive to time > allowed. > Does it make sense? Is it enough to check on DV creation ie per field/segment > or it's worth to check every Nth doc? -- 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
[jira] [Updated] (LUCENE-9036) ExitableDirectoryReader to interrupt DocValues as well
[ https://issues.apache.org/jira/browse/LUCENE-9036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9036: - Attachment: LUCENE-9036.patch Status: Open (was: Open) What do you think about [^LUCENE-9036.patch]? Tests are coming little bit later. > ExitableDirectoryReader to interrupt DocValues as well > -- > > Key: LUCENE-9036 > URL: https://issues.apache.org/jira/browse/LUCENE-9036 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Mikhail Khludnev >Priority: Major > Attachments: LUCENE-9036.patch > > > This allow to make AnalyticsComponent and json.facet sensitive to time > allowed. > Does it make sense? Is it enough to check on DV creation ie per field/segment > or it's worth to check every Nth doc? -- 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
[jira] [Commented] (LUCENE-8836) Optimize DocValues TermsDict to continue scanning from the last position when possible
[
https://issues.apache.org/jira/browse/LUCENE-8836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968986#comment-16968986
]
Mikhail Khludnev commented on LUCENE-8836:
--
I'm not sure if {{SortedSetDocValues.termsEnum()}} is relevant to this?
> Optimize DocValues TermsDict to continue scanning from the last position when
> possible
> --
>
> Key: LUCENE-8836
> URL: https://issues.apache.org/jira/browse/LUCENE-8836
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Bruno Roustant
>Priority: Major
> Labels: docValues, optimization
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Lucene80DocValuesProducer.TermsDict is used to lookup for either a term or a
> term ordinal.
> Currently it does not have the optimization the FSTEnum has: to be able to
> continue a sequential scan from where the last lookup was in the IndexInput.
> For sparse lookups (when searching only a few terms or ordinal) it is not an
> issue. But for multiple lookups in a row this optimization could save
> re-scanning all the terms from the block start (since they are delat encoded).
> This patch proposes the optimization.
> To estimate the gain, we ran 3 Lucene tests while counting the seeks and the
> term reads in the IndexInput, with and without the optimization:
> TestLucene70DocValuesFormat - the optimization saves 24% seeks and 15% term
> reads.
> TestDocValuesQueries - the optimization adds 0.7% seeks and 0.003% term reads.
> TestDocValuesRewriteMethod.testRegexps - the optimization saves 71% seeks and
> 82% term reads.
> In some cases, when scanning many terms in lexicographical order, the
> optimization saves a lot. In some case, when only looking for some sparse
> terms, the optimization does not bring improvement, but does not penalize
> neither. It seems to be worth to always have it.
--
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
[jira] [Commented] (SOLR-13892) Add postfilter support to {!join} queries
[
https://issues.apache.org/jira/browse/SOLR-13892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968123#comment-16968123
]
Mikhail Khludnev commented on SOLR-13892:
-
[~jbernste], Thanks for your comments.
{quote}The postfilter in this patch is not the main optimization{quote}
OK. Fair. It might make sense to highlight it into the issue summary. So, far
it doesn't meet user expectation about post filtering: when I have
{{fq=id:1&fq={!foo cost=9000}...}} I expect that post filter just checks one
doc with {{id:1}}, which is not the case here since {{PostFilterJoinQuery}}
materializes {{toOrdBitSet}}. And there are probably shorter way to yield
bitset as a filter for standard intersection algorithm.
{quote}Notice the bytesrefs from the to index are sorted without sorting.{quote}
Sure. They are sorted/merged in {{SlowCompositeReaderWrapper}} and
{{OrdinalMap}} and hopefully cached until searcher is thrown away by commit.
{quote}Also notice that in the patch the bytesrefs from the from index are
never materialized in memory at once{quote}
I'd say: They are materialized already in memory at least once in
{{SlowCompositeReaderWrapper}} and {{OrdinalMap}}, but the point is correct.
Concurrently running joins doesn't duplicate those ByteRefs, which seems to be
happen with JoinUtils.
{quote}This can be slow when there are a large number of join terms because
seeks into the terms enum need to be done for the entire join list for each
segment{quote}
Note: the case for {{{!join score=none}}} is highly selective "from"-side
query, and frequently updated index with tradeoff in query time caused by
segment enumeration. In 400K wide scan usecase you mention above, classic join
might run relatively well too.
So, I think this feature can be proposed for users purposing peak throughput on
static indices. I suggest to name it referring to 'global ordinals' at least to
avoid clashing with real post filter aka existential join LUCENE-6332.
> Add postfilter support to {!join} queries
> -
>
> Key: SOLR-13892
> URL: https://issues.apache.org/jira/browse/SOLR-13892
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13892.patch
>
>
> The JoinQParserPlugin would be a lot performant in many use-cases if it could
> operate as a post-filter, especially when doc-values for the involved fields
> are available.
> With this issue, I'd like to propose a post-filter implementation for the
> {{join}} qparser.
--
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
[jira] [Updated] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9031: - Attachment: LUCENE-9031.patch > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch, LUCENE-9031.patch, LUCENE-9031.patch, > LUCENE-9031.patch, LUCENE-9031.patch, LUCENE-9031.patch > > Time Spent: 1h 20m > Remaining Estimate: 0h > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Updated] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9031: - Attachment: LUCENE-9031.patch Status: Patch Available (was: Patch Available) > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch, LUCENE-9031.patch, LUCENE-9031.patch, > LUCENE-9031.patch, LUCENE-9031.patch > > Time Spent: 1h 20m > Remaining Estimate: 0h > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Updated] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9031: - Attachment: (was: LUCENE-9031.patch) > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch, LUCENE-9031.patch, LUCENE-9031.patch, > LUCENE-9031.patch, LUCENE-9031.patch > > Time Spent: 1h 20m > Remaining Estimate: 0h > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Commented] (SOLR-13892) Add postfilter support to {!join} queries
[
https://issues.apache.org/jira/browse/SOLR-13892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16967815#comment-16967815
]
Mikhail Khludnev commented on SOLR-13892:
-
Feel free to check this
[condition|https://github.com/apache/lucene-solr/blob/4f16d87c7ee5d4cf6e335cfd464733b149d62eb5/solr/core/src/java/org/apache/solr/search/JoinQParserPlugin.java#L73]
pls
> Add postfilter support to {!join} queries
> -
>
> Key: SOLR-13892
> URL: https://issues.apache.org/jira/browse/SOLR-13892
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13892.patch
>
>
> The JoinQParserPlugin would be a lot performant in many use-cases if it could
> operate as a post-filter, especially when doc-values for the involved fields
> are available.
> With this issue, I'd like to propose a post-filter implementation for the
> {{join}} qparser.
--
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
[jira] [Comment Edited] (SOLR-13892) Add postfilter support to {!join} queries
[
https://issues.apache.org/jira/browse/SOLR-13892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16967757#comment-16967757
]
Mikhail Khludnev edited comment on SOLR-13892 at 11/5/19 6:42 PM:
--
{{{!join score=none}}} switches execution to
[TermsQuery|https://github.com/apache/lucene-solr/blob/4f16d87c7ee5d4cf6e335cfd464733b149d62eb5/lucene/join/src/java/org/apache/lucene/search/join/JoinUtil.java#L379]
as a result of these, complexity of operation is proportional to number of
values under "from"-side of join. As you remind, classic {{{!join}}} complexity
is proportional of number of terms at "to"-side despite of "from"-side
selectivity.
was (Author: mkhludnev):
{!join score=none} switches execution to
https://github.com/apache/lucene-solr/blob/4f16d87c7ee5d4cf6e335cfd464733b149d62eb5/lucene/join/src/java/org/apache/lucene/search/join/JoinUtil.java#L37
as a result of these, complexity of operation is proportional to number of
values under "from"-side of join. As you remind, classic {!join} complexity is
proportional of number of terms at "to"-side despite of "from"-side
selectivity.
> Add postfilter support to {!join} queries
> -
>
> Key: SOLR-13892
> URL: https://issues.apache.org/jira/browse/SOLR-13892
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13892.patch
>
>
> The JoinQParserPlugin would be a lot performant in many use-cases if it could
> operate as a post-filter, especially when doc-values for the involved fields
> are available.
> With this issue, I'd like to propose a post-filter implementation for the
> {{join}} qparser.
--
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
[jira] [Commented] (SOLR-13892) Add postfilter support to {!join} queries
[
https://issues.apache.org/jira/browse/SOLR-13892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16967757#comment-16967757
]
Mikhail Khludnev commented on SOLR-13892:
-
{!join score=none} switches execution to
https://github.com/apache/lucene-solr/blob/4f16d87c7ee5d4cf6e335cfd464733b149d62eb5/lucene/join/src/java/org/apache/lucene/search/join/JoinUtil.java#L37
as a result of these, complexity of operation is proportional to number of
values under "from"-side of join. As you remind, classic {!join} complexity is
proportional of number of terms at "to"-side despite of "from"-side
selectivity.
> Add postfilter support to {!join} queries
> -
>
> Key: SOLR-13892
> URL: https://issues.apache.org/jira/browse/SOLR-13892
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13892.patch
>
>
> The JoinQParserPlugin would be a lot performant in many use-cases if it could
> operate as a post-filter, especially when doc-values for the involved fields
> are available.
> With this issue, I'd like to propose a post-filter implementation for the
> {{join}} qparser.
--
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
[jira] [Commented] (SOLR-13892) Add postfilter support to {!join} queries
[
https://issues.apache.org/jira/browse/SOLR-13892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16967734#comment-16967734
]
Mikhail Khludnev commented on SOLR-13892:
-
{quote} this join has proven to be 700% faster than the existing implementation.
{quote}
Which of existing impls you mean here just \{!join} or \{!join score=none} ?
> Add postfilter support to {!join} queries
> -
>
> Key: SOLR-13892
> URL: https://issues.apache.org/jira/browse/SOLR-13892
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13892.patch
>
>
> The JoinQParserPlugin would be a lot performant in many use-cases if it could
> operate as a post-filter, especially when doc-values for the involved fields
> are available.
> With this issue, I'd like to propose a post-filter implementation for the
> {{join}} qparser.
--
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
[jira] [Commented] (SOLR-13892) Add postfilter support to {!join} queries
[
https://issues.apache.org/jira/browse/SOLR-13892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16967703#comment-16967703
]
Mikhail Khludnev commented on SOLR-13892:
-
# the attached code doesn't get gain in comparison to existing {{{!join ..
score=none}}} SOLR-6234 please prove the opposite
# post-filter is irrelevant to these joins (I can explain why). The
opportunity for something like post-filtering/two-phase is discussed at
LUCENE-6332
> Add postfilter support to {!join} queries
> -
>
> Key: SOLR-13892
> URL: https://issues.apache.org/jira/browse/SOLR-13892
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13892.patch
>
>
> The JoinQParserPlugin would be a lot performant in many use-cases if it could
> operate as a post-filter, especially when doc-values for the involved fields
> are available.
> With this issue, I'd like to propose a post-filter implementation for the
> {{join}} qparser.
--
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
[jira] [Commented] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16967309#comment-16967309 ] Mikhail Khludnev commented on LUCENE-9031: -- Turns out supporting HighlightFlag.PHRASES and HighlightFlag.MULTI_TERM_QUERY is out of reach due to absence of methods like TermSpans.collect(SpanCollector) in Matches. Thus, when Interval wildcard is expanded I didnt' find a way to let highlighter know detailed info about match. I suppose it's out of scope for now., > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch, LUCENE-9031.patch, LUCENE-9031.patch, > LUCENE-9031.patch, LUCENE-9031.patch > > Time Spent: 10m > Remaining Estimate: 0h > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Comment Edited] (LUCENE-9026) Make it easier to extend DocValuesTermsQuery
[
https://issues.apache.org/jira/browse/LUCENE-9026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16967049#comment-16967049
]
Mikhail Khludnev edited comment on LUCENE-9026 at 11/5/19 7:33 AM:
---
{quote}I'm considering extending the query to implement Solr's
[PostFilter|https://lucene.apache.org/solr/8_2_0/solr-core/org/apache/solr/search/PostFilter.html]
interface. The ultimate goal of this is to make it more efficient to run this
query with very large numbers of terms.
{quote}
Hello, [~gerlowskija].
Please notice
[method=docValuesTermsFilter|https://lucene.apache.org/solr/guide/7_3/other-parsers.html#terms-query-parser],
I suppose it does it underneath.
{panel:title=UPD}
Ok. It can do that on lucene level, but including it as {{fq}} turns eager
docset evaluation in SolrIndexSearcher.getProcessedFilter() thus it can only
get gain as
{code:java}
q={!bool filter='{!terms cache=false method=docValuesTermsFilter v=$termz}'
must='' should=''}
{code}
{panel}
was (Author: mkhludnev):
{quote}I'm considering extending the query to implement Solr's
[PostFilter|https://lucene.apache.org/solr/8_2_0/solr-core/org/apache/solr/search/PostFilter.html]
interface. The ultimate goal of this is to make it more efficient to run this
query with very large numbers of terms.
{quote}
Hello, [~gerlowskija].
Please notice
[method=docValuesTermsFilter|https://lucene.apache.org/solr/guide/7_3/other-parsers.html#terms-query-parser],
I suppose it does it underneath.
{panel:title=UPD}
Ok. It can do that on lucene level, but including it as {{fq}} turns eager
docset evaluation in SolrIndexSearcher.getProcessedFilter() thus it can only
get gain as
{code:java}
q={!bool filter='{!terms cache=false method=docValuesTermsFilter v=&termz}'
must='' should=''}
{code}
{panel}
> Make it easier to extend DocValuesTermsQuery
>
>
> Key: LUCENE-9026
> URL: https://issues.apache.org/jira/browse/LUCENE-9026
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Minor
> Attachments: LUCENESOLR-9026.patch
>
>
> The visibility of some of the fields in DocValuesTermsQuery make it difficult
> to efficiently subclass. Especially the "termData" instance variable, which
> is really core to the functioning of the class but is totally inaccessible
> from any sub-classes, forcing subclasses to store a duplicate
> PrefixCodedTerms object, and then juggle the state of both.
> Are there any objections to making "termData" (and potentiall some other
> instance variables) protected instead of private for this class?
--
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
[jira] [Comment Edited] (LUCENE-9026) Make it easier to extend DocValuesTermsQuery
[
https://issues.apache.org/jira/browse/LUCENE-9026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16967049#comment-16967049
]
Mikhail Khludnev edited comment on LUCENE-9026 at 11/4/19 10:36 PM:
{quote}I'm considering extending the query to implement Solr's
[PostFilter|https://lucene.apache.org/solr/8_2_0/solr-core/org/apache/solr/search/PostFilter.html]
interface. The ultimate goal of this is to make it more efficient to run this
query with very large numbers of terms.
{quote}
Hello, [~gerlowskija].
Please notice
[method=docValuesTermsFilter|https://lucene.apache.org/solr/guide/7_3/other-parsers.html#terms-query-parser],
I suppose it does it underneath.
{panel:title=UPD}
Ok. It can do that on lucene level, but including it as {{fq}} turns eager
docset evaluation in SolrIndexSearcher.getProcessedFilter() thus it can only
get gain as
{code:java}
q={!bool filter='{!terms cache=false method=docValuesTermsFilter v=&termz}'
must='' should=''}
{code}
{panel}
was (Author: mkhludnev):
{quote}I'm considering extending the query to implement Solr's
[PostFilter|https://lucene.apache.org/solr/8_2_0/solr-core/org/apache/solr/search/PostFilter.html]
interface. The ultimate goal of this is to make it more efficient to run this
query with very large numbers of terms.
{quote}
Hello, [~gerlowskija].
Please notice
[method=docValuesTermsFilter|https://lucene.apache.org/solr/guide/7_3/other-parsers.html#terms-query-parser],
I suppose it does it underneath.
> Make it easier to extend DocValuesTermsQuery
>
>
> Key: LUCENE-9026
> URL: https://issues.apache.org/jira/browse/LUCENE-9026
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Minor
> Attachments: LUCENESOLR-9026.patch
>
>
> The visibility of some of the fields in DocValuesTermsQuery make it difficult
> to efficiently subclass. Especially the "termData" instance variable, which
> is really core to the functioning of the class but is totally inaccessible
> from any sub-classes, forcing subclasses to store a duplicate
> PrefixCodedTerms object, and then juggle the state of both.
> Are there any objections to making "termData" (and potentiall some other
> instance variables) protected instead of private for this class?
--
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
[jira] [Comment Edited] (LUCENE-9026) Make it easier to extend DocValuesTermsQuery
[
https://issues.apache.org/jira/browse/LUCENE-9026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16967049#comment-16967049
]
Mikhail Khludnev edited comment on LUCENE-9026 at 11/4/19 10:15 PM:
{quote}I'm considering extending the query to implement Solr's
[PostFilter|https://lucene.apache.org/solr/8_2_0/solr-core/org/apache/solr/search/PostFilter.html]
interface. The ultimate goal of this is to make it more efficient to run this
query with very large numbers of terms.
{quote}
Hello, [~gerlowskija].
Please notice
[method=docValuesTermsFilter|https://lucene.apache.org/solr/guide/7_3/other-parsers.html#terms-query-parser],
I suppose it does it underneath.
was (Author: mkhludnev):
{quote}I'm considering extending the query to implement Solr's
[PostFilter|https://lucene.apache.org/solr/8_2_0/solr-core/org/apache/solr/search/PostFilter.html]
interface. The ultimate goal of this is to make it more efficient to run this
query with very large numbers of terms.
{quote}
Hello, [~gerlowskija].
Please notice
[method=docValuesTermsFilter|https://lucene.apache.org/solr/guide/7_3/other-parsers.html#terms-query-parser],
I suppose it's done it underneath.
> Make it easier to extend DocValuesTermsQuery
>
>
> Key: LUCENE-9026
> URL: https://issues.apache.org/jira/browse/LUCENE-9026
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Minor
> Attachments: LUCENESOLR-9026.patch
>
>
> The visibility of some of the fields in DocValuesTermsQuery make it difficult
> to efficiently subclass. Especially the "termData" instance variable, which
> is really core to the functioning of the class but is totally inaccessible
> from any sub-classes, forcing subclasses to store a duplicate
> PrefixCodedTerms object, and then juggle the state of both.
> Are there any objections to making "termData" (and potentiall some other
> instance variables) protected instead of private for this class?
--
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
[jira] [Commented] (LUCENE-9026) Make it easier to extend DocValuesTermsQuery
[
https://issues.apache.org/jira/browse/LUCENE-9026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16967049#comment-16967049
]
Mikhail Khludnev commented on LUCENE-9026:
--
{quote}I'm considering extending the query to implement Solr's
[PostFilter|https://lucene.apache.org/solr/8_2_0/solr-core/org/apache/solr/search/PostFilter.html]
interface. The ultimate goal of this is to make it more efficient to run this
query with very large numbers of terms.
{quote}
Hello, [~gerlowskija].
Please notice
[method=docValuesTermsFilter|https://lucene.apache.org/solr/guide/7_3/other-parsers.html#terms-query-parser],
I suppose it's done it underneath.
> Make it easier to extend DocValuesTermsQuery
>
>
> Key: LUCENE-9026
> URL: https://issues.apache.org/jira/browse/LUCENE-9026
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Minor
> Attachments: LUCENESOLR-9026.patch
>
>
> The visibility of some of the fields in DocValuesTermsQuery make it difficult
> to efficiently subclass. Especially the "termData" instance variable, which
> is really core to the functioning of the class but is totally inaccessible
> from any sub-classes, forcing subclasses to store a duplicate
> PrefixCodedTerms object, and then juggle the state of both.
> Are there any objections to making "termData" (and potentiall some other
> instance variables) protected instead of private for this class?
--
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
[jira] [Commented] (SOLR-13892) Add postfilter support to {!join} queries
[
https://issues.apache.org/jira/browse/SOLR-13892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966891#comment-16966891
]
Mikhail Khludnev commented on SOLR-13892:
-
Hello, [~gerlowskija].
The concern is that such post filtering doesn't make much gain after "to"-side
bitset is calculated eagerly (real lazy "exists"-kind of join is aside from
it). What I saw in the patch if what we already have in Lucene's JoinUtil, and
what's switched on by \{!join .. score=none} SOLR-6234, there should be even
something in ref guide. I also agree with [~jpountz] that it's worth to use
TwoPhase matching in new code rather than old postfiltering.
Thanks
> Add postfilter support to {!join} queries
> -
>
> Key: SOLR-13892
> URL: https://issues.apache.org/jira/browse/SOLR-13892
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13892.patch
>
>
> The JoinQParserPlugin would be a lot performant in many use-cases if it could
> operate as a post-filter, especially when doc-values for the involved fields
> are available.
> With this issue, I'd like to propose a post-filter implementation for the
> {{join}} qparser.
--
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
[jira] [Commented] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16965580#comment-16965580 ] Mikhail Khludnev commented on LUCENE-9031: -- Turns out, highlighting multiterm intervals is way harder. Added some band aid into the patch. So far PhraseHelper and/or TermVector isn't covered yet. I suppose I'll continue to mimic Intervals to Spans. > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch, LUCENE-9031.patch, LUCENE-9031.patch, > LUCENE-9031.patch, LUCENE-9031.patch > > Time Spent: 10m > Remaining Estimate: 0h > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Updated] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9031: - Attachment: LUCENE-9031.patch > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch, LUCENE-9031.patch, LUCENE-9031.patch, > LUCENE-9031.patch, LUCENE-9031.patch > > Time Spent: 10m > Remaining Estimate: 0h > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Created] (LUCENE-9036) ExitableDirectoryReader to interrupt DocValues as well
Mikhail Khludnev created LUCENE-9036: Summary: ExitableDirectoryReader to interrupt DocValues as well Key: LUCENE-9036 URL: https://issues.apache.org/jira/browse/LUCENE-9036 Project: Lucene - Core Issue Type: Improvement Reporter: Mikhail Khludnev This allow to make AnalyticsComponent and json.facet sensitive to time allowed. Does it make sense? Is it enough to check on DV creation ie per field/segment or it's worth to check every Nth doc? -- 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
[jira] [Commented] (LUCENE-9021) QueryParser should avoid creating an LookaheadSuccess(Error) object with every instance
[ https://issues.apache.org/jira/browse/LUCENE-9021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16965405#comment-16965405 ] Mikhail Khludnev commented on LUCENE-9021: -- I think I can commit it. I would like someone to confirm it makes sense. > QueryParser should avoid creating an LookaheadSuccess(Error) object with > every instance > --- > > Key: LUCENE-9021 > URL: https://issues.apache.org/jira/browse/LUCENE-9021 > Project: Lucene - Core > Issue Type: Bug >Reporter: Przemek Bruski >Priority: Major > Attachments: LUCENE-9021.patch > > Time Spent: 10m > Remaining Estimate: 0h > > This is basically the same as > https://issues.apache.org/jira/browse/SOLR-11242 , but for Lucene QueryParser -- 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
[jira] [Updated] (LUCENE-9028) Public method for MultiTermIntervalSource
[
https://issues.apache.org/jira/browse/LUCENE-9028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated LUCENE-9028:
-
Fix Version/s: 8.4
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Public method for MultiTermIntervalSource
> -
>
> Key: LUCENE-9028
> URL: https://issues.apache.org/jira/browse/LUCENE-9028
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.4
>
> Attachments: LUCENE-9028.patch
>
>
> Right now we have prefix and widlcard for multiterm Intervals. Sometimes it's
> necessary to provide terms set in a more generic way as automaton.
> {code:java}
> Intervals.multiterm(CompiledAutomaton automaton, int maxExpansions, String
> pattern)
> {code}
> As a benefit we can handle it more efficient rather than or over terms.
> What do you think?
--
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
[jira] [Commented] (LUCENE-9028) Public method for MultiTermIntervalSource
[
https://issues.apache.org/jira/browse/LUCENE-9028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16965237#comment-16965237
]
Mikhail Khludnev commented on LUCENE-9028:
--
I haven't got a reply. So, I put it as is, hopefully we can review and polish
before 8.4. Just let me know is there are any concern,
> Public method for MultiTermIntervalSource
> -
>
> Key: LUCENE-9028
> URL: https://issues.apache.org/jira/browse/LUCENE-9028
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: LUCENE-9028.patch
>
>
> Right now we have prefix and widlcard for multiterm Intervals. Sometimes it's
> necessary to provide terms set in a more generic way as automaton.
> {code:java}
> Intervals.multiterm(CompiledAutomaton automaton, int maxExpansions, String
> pattern)
> {code}
> As a benefit we can handle it more efficient rather than or over terms.
> What do you think?
--
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
[jira] [Updated] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9031: - Attachment: LUCENE-9031.patch > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch, LUCENE-9031.patch, LUCENE-9031.patch, > LUCENE-9031.patch > > Time Spent: 10m > Remaining Estimate: 0h > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Updated] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9031: - Attachment: (was: LUCENE-9031.patch) > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch, LUCENE-9031.patch, LUCENE-9031.patch > > Time Spent: 10m > Remaining Estimate: 0h > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Commented] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16964683#comment-16964683 ] Mikhail Khludnev commented on LUCENE-9031: -- Just adding assert for Curious Geourge. [~romseygeek], would you mind to have a look, please? > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch, LUCENE-9031.patch, LUCENE-9031.patch, > LUCENE-9031.patch > > Time Spent: 10m > Remaining Estimate: 0h > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Updated] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9031: - Attachment: LUCENE-9031.patch > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch, LUCENE-9031.patch, LUCENE-9031.patch, > LUCENE-9031.patch > > Time Spent: 10m > Remaining Estimate: 0h > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Resolved] (LUCENE-9035) Increase doc snippet to attempt to overflow buffers at intervals.CachingMatchesIterator
[ https://issues.apache.org/jira/browse/LUCENE-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev resolved LUCENE-9035. -- Resolution: Won't Fix Can't do it reliably. > Increase doc snippet to attempt to overflow buffers at > intervals.CachingMatchesIterator > --- > > Key: LUCENE-9035 > URL: https://issues.apache.org/jira/browse/LUCENE-9035 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Mikhail Khludnev >Priority: Major > > It seems like TestIntervals.testNestedMaxGaps() is the most promising to do > so. -- 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
[jira] [Commented] (LUCENE-9028) Public method for MultiTermIntervalSource
[
https://issues.apache.org/jira/browse/LUCENE-9028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16963503#comment-16963503
]
Mikhail Khludnev commented on LUCENE-9028:
--
I think it may go into. There are minor questions: do we need the second method
defaulting 128? Should it accept Automaton or CompiledAutomaton?
> Public method for MultiTermIntervalSource
> -
>
> Key: LUCENE-9028
> URL: https://issues.apache.org/jira/browse/LUCENE-9028
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: LUCENE-9028.patch
>
>
> Right now we have prefix and widlcard for multiterm Intervals. Sometimes it's
> necessary to provide terms set in a more generic way as automaton.
> {code:java}
> Intervals.multiterm(CompiledAutomaton automaton, int maxExpansions, String
> pattern)
> {code}
> As a benefit we can handle it more efficient rather than or over terms.
> What do you think?
--
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
[jira] [Updated] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9031: - Attachment: LUCENE-9031.patch > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch, LUCENE-9031.patch, LUCENE-9031.patch > > Time Spent: 10m > Remaining Estimate: 0h > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Created] (LUCENE-9035) Increase doc snippet to attempt to overflow buffers at intervals.CachingMatchesIterator
Mikhail Khludnev created LUCENE-9035: Summary: Increase doc snippet to attempt to overflow buffers at intervals.CachingMatchesIterator Key: LUCENE-9035 URL: https://issues.apache.org/jira/browse/LUCENE-9035 Project: Lucene - Core Issue Type: Sub-task Reporter: Mikhail Khludnev It seems like TestIntervals.testNestedMaxGaps() is the most promising to do so. -- 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
[jira] [Issue Comment Deleted] (LUCENE-8422) Add Matches iteration to interval queries
[ https://issues.apache.org/jira/browse/LUCENE-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-8422: - Comment: was deleted (was: !image-2019-10-30-12-08-40-145.png! What worries me a little is absence of coverage in that caching code, even after running Intervals package tests. ) > Add Matches iteration to interval queries > - > > Key: LUCENE-8422 > URL: https://issues.apache.org/jira/browse/LUCENE-8422 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Fix For: 7.5 > > Attachments: LUCENE-8422.patch, LUCENE-8422.patch, LUCENE-8422.patch, > image-2019-10-30-12-08-40-145.png > > > Follow up to LUCENE-8404, we can now add Matches iteration to interval > queries in the sandbox. -- 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
[jira] [Commented] (LUCENE-8422) Add Matches iteration to interval queries
[ https://issues.apache.org/jira/browse/LUCENE-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16963344#comment-16963344 ] Mikhail Khludnev commented on LUCENE-8422: -- !image-2019-10-30-12-08-40-145.png! What worries me a little is absence of coverage in that caching code, even after running Intervals package tests. > Add Matches iteration to interval queries > - > > Key: LUCENE-8422 > URL: https://issues.apache.org/jira/browse/LUCENE-8422 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Fix For: 7.5 > > Attachments: LUCENE-8422.patch, LUCENE-8422.patch, LUCENE-8422.patch, > image-2019-10-30-12-08-40-145.png > > > Follow up to LUCENE-8404, we can now add Matches iteration to interval > queries in the sandbox. -- 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
[jira] [Updated] (LUCENE-8422) Add Matches iteration to interval queries
[ https://issues.apache.org/jira/browse/LUCENE-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-8422: - Attachment: image-2019-10-30-12-08-40-145.png > Add Matches iteration to interval queries > - > > Key: LUCENE-8422 > URL: https://issues.apache.org/jira/browse/LUCENE-8422 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Fix For: 7.5 > > Attachments: LUCENE-8422.patch, LUCENE-8422.patch, LUCENE-8422.patch, > image-2019-10-30-12-08-40-145.png > > > Follow up to LUCENE-8404, we can now add Matches iteration to interval > queries in the sandbox. -- 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
[jira] [Commented] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16963239#comment-16963239 ] Mikhail Khludnev commented on LUCENE-9031: -- done [https://github.com/apache/lucene-solr/pull/985/files] > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch, LUCENE-9031.patch > > Time Spent: 10m > Remaining Estimate: 0h > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Updated] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9031: - Attachment: (was: LUCENE-9031.patch) > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch, LUCENE-9031.patch > > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Updated] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9031: - Attachment: LUCENE-9031.patch > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch, LUCENE-9031.patch > > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Updated] (LUCENE-9028) Public method for MultiTermIntervalSource
[
https://issues.apache.org/jira/browse/LUCENE-9028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated LUCENE-9028:
-
Status: Patch Available (was: Open)
> Public method for MultiTermIntervalSource
> -
>
> Key: LUCENE-9028
> URL: https://issues.apache.org/jira/browse/LUCENE-9028
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: LUCENE-9028.patch
>
>
> Right now we have prefix and widlcard for multiterm Intervals. Sometimes it's
> necessary to provide terms set in a more generic way as automaton.
> {code:java}
> Intervals.multiterm(CompiledAutomaton automaton, int maxExpansions, String
> pattern)
> {code}
> As a benefit we can handle it more efficient rather than or over terms.
> What do you think?
--
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
[jira] [Updated] (LUCENE-9028) Public method for MultiTermIntervalSource
[
https://issues.apache.org/jira/browse/LUCENE-9028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated LUCENE-9028:
-
Attachment: LUCENE-9028.patch
Assignee: Mikhail Khludnev
Status: Open (was: Open)
> Public method for MultiTermIntervalSource
> -
>
> Key: LUCENE-9028
> URL: https://issues.apache.org/jira/browse/LUCENE-9028
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: LUCENE-9028.patch
>
>
> Right now we have prefix and widlcard for multiterm Intervals. Sometimes it's
> necessary to provide terms set in a more generic way as automaton.
> {code:java}
> Intervals.multiterm(CompiledAutomaton automaton, int maxExpansions, String
> pattern)
> {code}
> As a benefit we can handle it more efficient rather than or over terms.
> What do you think?
--
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
[jira] [Commented] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16962354#comment-16962354 ] Mikhail Khludnev commented on LUCENE-9031: -- I'm not sure I've got your point. I did cache for queries. But it requires some code change in TermIS. Also added Interval queries into TestUnifiedHighlighter. Couldn't make I.fixField() to highlight correctly, to be continued. Also, it seems like highlighting of BQ of SHOULDs is deferent from highlighting Intervals.or(), I'm not sure if Intervals has any method, highlighted by the same way as BQ of SHOULDs. Attached patch with many repeats just for Yetus. > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch, LUCENE-9031.patch > > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Commented] (LUCENE-8422) Add Matches iteration to interval queries
[
https://issues.apache.org/jira/browse/LUCENE-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16962343#comment-16962343
]
Mikhail Khludnev commented on LUCENE-8422:
--
Btw, why it grow every time for one match only. Shouldn't it grow twice?
{code:java}
+posAndOffsets = ArrayUtil.grow(posAndOffsets, (count + 1) * 4);
{code}
> Add Matches iteration to interval queries
> -
>
> Key: LUCENE-8422
> URL: https://issues.apache.org/jira/browse/LUCENE-8422
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.5
>
> Attachments: LUCENE-8422.patch, LUCENE-8422.patch, LUCENE-8422.patch
>
>
> Follow up to LUCENE-8404, we can now add Matches iteration to interval
> queries in the sandbox.
--
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
[jira] [Updated] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9031: - Attachment: LUCENE-9031.patch > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch, LUCENE-9031.patch > > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Commented] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16961529#comment-16961529 ] Mikhail Khludnev commented on LUCENE-9031: -- attached rough cut, thinking about testing. > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch > > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Updated] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9031: - Status: Patch Available (was: Open) > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch > > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Updated] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9031: - Attachment: LUCENE-9031.patch > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch > > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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
[jira] [Commented] (LUCENE-8422) Add Matches iteration to interval queries
[ https://issues.apache.org/jira/browse/LUCENE-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16961512#comment-16961512 ] Mikhail Khludnev commented on LUCENE-8422: -- raised LUCENE-9031 > Add Matches iteration to interval queries > - > > Key: LUCENE-8422 > URL: https://issues.apache.org/jira/browse/LUCENE-8422 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Fix For: 7.5 > > Attachments: LUCENE-8422.patch, LUCENE-8422.patch, LUCENE-8422.patch > > > Follow up to LUCENE-8404, we can now add Matches iteration to interval > queries in the sandbox. -- 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
[jira] [Created] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
Mikhail Khludnev created LUCENE-9031: Summary: UnsupportedOperationException on highlighting Interval Query Key: LUCENE-9031 URL: https://issues.apache.org/jira/browse/LUCENE-9031 Project: Lucene - Core Issue Type: Bug Components: modules/queries Reporter: Mikhail Khludnev Assignee: Mikhail Khludnev Fix For: 8.4 When UnifiedHighlighter highlights Interval Query it encounters UnsupportedOperationException. -- 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
[jira] [Commented] (LUCENE-9031) UnsupportedOperationException on highlighting Interval Query
[
https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16961509#comment-16961509
]
Mikhail Khludnev commented on LUCENE-9031:
--
{noformat}
java.lang.UnsupportedOperationException
at
org.apache.lucene.queries.intervals.CachingMatchesIterator$1.getQuery(CachingMatchesIterator.java:127)
at
org.apache.lucene.search.DisjunctionMatchesIterator.getQuery(DisjunctionMatchesIterator.java:168)
at
org.apache.lucene.search.uhighlight.OffsetsEnum$OfMatchesIteratorWithSubs.enqueueCachedMatches(OffsetsEnum.java:236)
at
org.apache.lucene.search.uhighlight.OffsetsEnum$OfMatchesIteratorWithSubs.nextWhenMatchesIterator(OffsetsEnum.java:215)
at
org.apache.lucene.search.uhighlight.OffsetsEnum$OfMatchesIteratorWithSubs.nextPosition(OffsetsEnum.java:200)
at
org.apache.lucene.search.uhighlight.FieldHighlighter.highlightOffsetsEnums(FieldHighlighter.java:130)
at
org.apache.lucene.search.uhighlight.FieldHighlighter.highlightFieldForDoc(FieldHighlighter.java:79)
at
org.apache.lucene.search.uhighlight.UnifiedHighlighter.highlightFieldsAsObjects(UnifiedHighlighter.java:641)
at
org.apache.lucene.search.uhighlight.UnifiedHighlighter.highlightFields(UnifiedHighlighter.java:510){noformat}
> UnsupportedOperationException on highlighting Interval Query
>
>
> Key: LUCENE-9031
> URL: https://issues.apache.org/jira/browse/LUCENE-9031
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/queries
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.4
>
>
> When UnifiedHighlighter highlights Interval Query it encounters
> UnsupportedOperationException.
--
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
[jira] [Commented] (LUCENE-8422) Add Matches iteration to interval queries
[
https://issues.apache.org/jira/browse/LUCENE-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16961456#comment-16961456
]
Mikhail Khludnev commented on LUCENE-8422:
--
Why {{CachingMatchesIterator.getSubMatches(...).new MatchesIterator()
\{...}.getQuery()}} introduced here throws UnsupportedOpExc? see
[https://github.com/apache/lucene-solr/blob/3af4e6adc6b1ffdc5099ba68227ce0dc6b252644/lucene/queries/src/java/org/apache/lucene/queries/intervals/CachingMatchesIterator.java#L127]
I tried to experiment with highlighting Interval queries, didn't find any
particular test for it. Thus, I tweaked
{{TestUnifiedHighlighter.testBuddhism()}} for using Intervals.phrase(). Turns
out it fails roughly at %50 with this exception. The fix is obvious. Don't we
need it fixed? I can.
> Add Matches iteration to interval queries
> -
>
> Key: LUCENE-8422
> URL: https://issues.apache.org/jira/browse/LUCENE-8422
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.5
>
> Attachments: LUCENE-8422.patch, LUCENE-8422.patch, LUCENE-8422.patch
>
>
> Follow up to LUCENE-8404, we can now add Matches iteration to interval
> queries in the sandbox.
--
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
[jira] [Updated] (LUCENE-9028) Public method for MultiTermIntervalSource
[
https://issues.apache.org/jira/browse/LUCENE-9028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated LUCENE-9028:
-
Description:
Right now we have prefix and widlcard for multiterm Intervals. Sometimes it's
necessary to provide terms set in a more generic way as automaton.
{code:java}
Intervals.multiterm(CompiledAutomaton automaton, int maxExpansions, String
pattern)
{code}
As a benefit we can handle it more efficient rather than or over terms.
What do you think?
was:
Right now we have prefix and widlcard for multiterm Intervals. Sometimes it's
necessary to provide terms set in a more generic way as automaton.
{code:java}
Intervals.multierm(CompiledAutomaton automaton, int maxExpansions, String
pattern)
{code}
As a benefit we can handle it more efficient rather than or over terms.
What do you think?
> Public method for MultiTermIntervalSource
> -
>
> Key: LUCENE-9028
> URL: https://issues.apache.org/jira/browse/LUCENE-9028
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Priority: Major
>
> Right now we have prefix and widlcard for multiterm Intervals. Sometimes it's
> necessary to provide terms set in a more generic way as automaton.
> {code:java}
> Intervals.multiterm(CompiledAutomaton automaton, int maxExpansions, String
> pattern)
> {code}
> As a benefit we can handle it more efficient rather than or over terms.
> What do you think?
--
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
[jira] [Updated] (LUCENE-9028) Public method for MultiTermIntervalSource
[
https://issues.apache.org/jira/browse/LUCENE-9028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated LUCENE-9028:
-
Summary: Public method for MultiTermIntervalSource (was: Provide public
method for MultiTermIntervalSource)
> Public method for MultiTermIntervalSource
> -
>
> Key: LUCENE-9028
> URL: https://issues.apache.org/jira/browse/LUCENE-9028
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Priority: Major
>
> Right now we have prefix and widlcard for multiterm Intervals. Sometimes it's
> necessary to provide terms set in a more generic way as automaton.
> {code:java}
> Intervals.multierm(CompiledAutomaton automaton, int maxExpansions, String
> pattern)
> {code}
> As a benefit we can handle it more efficient rather than or over terms.
> What do you think?
--
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
[jira] [Created] (LUCENE-9028) Provide public method for MultiTermIntervalSource
Mikhail Khludnev created LUCENE-9028:
Summary: Provide public method for MultiTermIntervalSource
Key: LUCENE-9028
URL: https://issues.apache.org/jira/browse/LUCENE-9028
Project: Lucene - Core
Issue Type: Improvement
Reporter: Mikhail Khludnev
Right now we have prefix and widlcard for multiterm Intervals. Sometimes it's
necessary to provide terms set in a more generic way as automaton.
{code:java}
Intervals.multierm(CompiledAutomaton automaton, int maxExpansions, String
pattern)
{code}
As a benefit we can handle it more efficient rather than or over terms.
What do you think?
--
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
[jira] [Updated] (LUCENE-9021) QueryParser should avoid creating an LookaheadSuccess(Error) object with every instance
[ https://issues.apache.org/jira/browse/LUCENE-9021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9021: - Status: Patch Available (was: Open) > QueryParser should avoid creating an LookaheadSuccess(Error) object with > every instance > --- > > Key: LUCENE-9021 > URL: https://issues.apache.org/jira/browse/LUCENE-9021 > Project: Lucene - Core > Issue Type: Bug >Reporter: Przemek Bruski >Priority: Major > Attachments: LUCENE-9021.patch > > Time Spent: 10m > Remaining Estimate: 0h > > This is basically the same as > https://issues.apache.org/jira/browse/SOLR-11242 , but for Lucene QueryParser -- 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
[jira] [Commented] (SOLR-13808) Query DSL should let to cache filter
[
https://issues.apache.org/jira/browse/SOLR-13808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16958161#comment-16958161
]
Mikhail Khludnev commented on SOLR-13808:
-
This particular failure is LUCENE-8996. So, patch is there. Enjoy. If there is
a desire I think it can go into next release after 8.3.
> Query DSL should let to cache filter
>
>
> Key: SOLR-13808
> URL: https://issues.apache.org/jira/browse/SOLR-13808
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13808.patch
>
>
> Query DSL let to express Lucene BQ's filter
>
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar"}}} }}{code}
> However, it might easily catch the need in caching it in filter cache. This
> might rely on ExtensibleQuery and QParser:
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar", cache:true}}} }}
> {code}
>
--
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
[jira] [Updated] (SOLR-13808) Query DSL should let to cache filter
[
https://issues.apache.org/jira/browse/SOLR-13808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13808:
Attachment: (was: SOLR-13808.patch)
> Query DSL should let to cache filter
>
>
> Key: SOLR-13808
> URL: https://issues.apache.org/jira/browse/SOLR-13808
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13808.patch
>
>
> Query DSL let to express Lucene BQ's filter
>
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar"}}} }}{code}
> However, it might easily catch the need in caching it in filter cache. This
> might rely on ExtensibleQuery and QParser:
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar", cache:true}}} }}
> {code}
>
--
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
[jira] [Updated] (SOLR-13808) Query DSL should let to cache filter
[
https://issues.apache.org/jira/browse/SOLR-13808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13808:
Attachment: SOLR-13808.patch
Status: Patch Available (was: Patch Available)
> Query DSL should let to cache filter
>
>
> Key: SOLR-13808
> URL: https://issues.apache.org/jira/browse/SOLR-13808
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13808.patch, SOLR-13808.patch
>
>
> Query DSL let to express Lucene BQ's filter
>
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar"}}} }}{code}
> However, it might easily catch the need in caching it in filter cache. This
> might rely on ExtensibleQuery and QParser:
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar", cache:true}}} }}
> {code}
>
--
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
[jira] [Updated] (SOLR-13808) Query DSL should let to cache filter
[
https://issues.apache.org/jira/browse/SOLR-13808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13808:
Attachment: SOLR-13808.patch
Status: Patch Available (was: Patch Available)
> Query DSL should let to cache filter
>
>
> Key: SOLR-13808
> URL: https://issues.apache.org/jira/browse/SOLR-13808
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13808.patch
>
>
> Query DSL let to express Lucene BQ's filter
>
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar"}}} }}{code}
> However, it might easily catch the need in caching it in filter cache. This
> might rely on ExtensibleQuery and QParser:
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar", cache:true}}} }}
> {code}
>
--
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
[jira] [Updated] (SOLR-13808) Query DSL should let to cache filter
[
https://issues.apache.org/jira/browse/SOLR-13808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13808:
Attachment: (was: SOLR-13808.patch)
> Query DSL should let to cache filter
>
>
> Key: SOLR-13808
> URL: https://issues.apache.org/jira/browse/SOLR-13808
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13808.patch
>
>
> Query DSL let to express Lucene BQ's filter
>
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar"}}} }}{code}
> However, it might easily catch the need in caching it in filter cache. This
> might rely on ExtensibleQuery and QParser:
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar", cache:true}}} }}
> {code}
>
--
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
[jira] [Updated] (SOLR-13808) Query DSL should let to cache filter
[
https://issues.apache.org/jira/browse/SOLR-13808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13808:
Status: Patch Available (was: Open)
> Query DSL should let to cache filter
>
>
> Key: SOLR-13808
> URL: https://issues.apache.org/jira/browse/SOLR-13808
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13808.patch
>
>
> Query DSL let to express Lucene BQ's filter
>
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar"}}} }}{code}
> However, it might easily catch the need in caching it in filter cache. This
> might rely on ExtensibleQuery and QParser:
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar", cache:true}}} }}
> {code}
>
--
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
[jira] [Updated] (SOLR-13808) Query DSL should let to cache filter
[
https://issues.apache.org/jira/browse/SOLR-13808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13808:
Attachment: SOLR-13808.patch
Status: Open (was: Open)
> Query DSL should let to cache filter
>
>
> Key: SOLR-13808
> URL: https://issues.apache.org/jira/browse/SOLR-13808
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13808.patch
>
>
> Query DSL let to express Lucene BQ's filter
>
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar"}}} }}{code}
> However, it might easily catch the need in caching it in filter cache. This
> might rely on ExtensibleQuery and QParser:
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar", cache:true}}} }}
> {code}
>
--
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
[jira] [Updated] (SOLR-13824) JSON Request API to reject anything after JSON object is over
[
https://issues.apache.org/jira/browse/SOLR-13824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13824:
Summary: JSON Request API to reject anything after JSON object is over
(was: JSON Request API ignores prematurely closing curly brace. )
> JSON Request API to reject anything after JSON object is over
> -
>
> Key: SOLR-13824
> URL: https://issues.apache.org/jira/browse/SOLR-13824
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JSON Request API
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13824.patch, SOLR-13824.patch, SOLR-13824.patch,
> SOLR-13824.patch
>
>
> {code:java}
> json={query:"content:foo", facet:{zz:{field:id}}}
> {code}
> this works fine, but if we mistype {{}}} instead of {{,}}
> {code:java}
> json={query:"content:foo"} facet:{zz:{field:id}}}
> {code}
> It's captured only partially, here's we have under debug
> {code:java}
> "json":{"query":"content:foo"},
> {code}
> I suppose it should throw an error with 400 code.
--
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
[jira] [Assigned] (SOLR-13824) JSON Request API ignores prematurely closing curly brace.
[
https://issues.apache.org/jira/browse/SOLR-13824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev reassigned SOLR-13824:
---
Assignee: Mikhail Khludnev
> JSON Request API ignores prematurely closing curly brace.
> --
>
> Key: SOLR-13824
> URL: https://issues.apache.org/jira/browse/SOLR-13824
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JSON Request API
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13824.patch, SOLR-13824.patch, SOLR-13824.patch,
> SOLR-13824.patch
>
>
> {code:java}
> json={query:"content:foo", facet:{zz:{field:id}}}
> {code}
> this works fine, but if we mistype {{}}} instead of {{,}}
> {code:java}
> json={query:"content:foo"} facet:{zz:{field:id}}}
> {code}
> It's captured only partially, here's we have under debug
> {code:java}
> "json":{"query":"content:foo"},
> {code}
> I suppose it should throw an error with 400 code.
--
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
[jira] [Updated] (SOLR-13824) JSON Request API ignores prematurely closing curly brace.
[
https://issues.apache.org/jira/browse/SOLR-13824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13824:
Fix Version/s: 8.4
Resolution: Fixed
Status: Resolved (was: Patch Available)
> JSON Request API ignores prematurely closing curly brace.
> --
>
> Key: SOLR-13824
> URL: https://issues.apache.org/jira/browse/SOLR-13824
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JSON Request API
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13824.patch, SOLR-13824.patch, SOLR-13824.patch,
> SOLR-13824.patch
>
>
> {code:java}
> json={query:"content:foo", facet:{zz:{field:id}}}
> {code}
> this works fine, but if we mistype {{}}} instead of {{,}}
> {code:java}
> json={query:"content:foo"} facet:{zz:{field:id}}}
> {code}
> It's captured only partially, here's we have under debug
> {code:java}
> "json":{"query":"content:foo"},
> {code}
> I suppose it should throw an error with 400 code.
--
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
[jira] [Comment Edited] (SOLR-13808) Query DSL should let to cache filter
[
https://issues.apache.org/jira/browse/SOLR-13808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16952969#comment-16952969
]
Mikhail Khludnev edited comment on SOLR-13808 at 10/21/19 11:55 AM:
Ok. It seems like the plan is to
# -create \{!cache} query parser to hook it up by existing DSL. Caveat for
users is loosing scoring-.
# enable cache by default for \{!bool filter=... filter=..}
# make sure that it's sensitive for \{!cache=false} local param for enclosing
queries
I'm fine with it and patches are welcome.
was (Author: mkhludnev):
Ok. It seems like the plan is to
# create \{!cache} query parser to hook it up by existing DSL. Caveat for
users is loosing scoring.
# enable cache by default for \{!bool filter=... filter=..}
# make sure that it sensitive for \{!cache=false} local param for enclosing
queries
I'm fine with it and patches are welcome.
> Query DSL should let to cache filter
>
>
> Key: SOLR-13808
> URL: https://issues.apache.org/jira/browse/SOLR-13808
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Major
>
> Query DSL let to express Lucene BQ's filter
>
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar"}}} }}{code}
> However, it might easily catch the need in caching it in filter cache. This
> might rely on ExtensibleQuery and QParser:
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar", cache:true}}} }}
> {code}
>
--
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
[jira] [Commented] (SOLR-13850) Atomic Updates with PreAnalyzedField
[
https://issues.apache.org/jira/browse/SOLR-13850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16955997#comment-16955997
]
Mikhail Khludnev commented on SOLR-13850:
-
{quote}I'm not even sure it's meaningful to have a pre-analyzed field be
"stored".
{quote}
[Looks
like|https://lucene.apache.org/solr/guide/6_6/working-with-external-files-and-processes.html#WorkingwithExternalFilesandProcesses-JsonPreAnalyzedParser]
it is.
Let's embrace the failure. Patch is welcome.
> Atomic Updates with PreAnalyzedField
>
>
> Key: SOLR-13850
> URL: https://issues.apache.org/jira/browse/SOLR-13850
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7.2, 8.2
> Environment: Ubuntu 16.04 LTS / Java 8 (Zulu), Windows 10 / Java 11
> (Oracle)
>Reporter: Oleksandr Drapushko
>Priority: Critical
> Labels: AtomicUpdate
>
> If you try to update non pre-analyzed fields in a document using atomic
> updates, data in pre-analyzed fields (if there is any) will be lost.
> *Steps to reproduce*
> 1. Index this document into techproducts
> {code:json}
> {
> "id": "a",
> "n_s": "s1",
> "pre":
> "{\"v\":\"1\",\"str\":\"Alaska\",\"tokens\":[{\"t\":\"alaska\",\"s\":0,\"e\":6,\"i\":1}]}"
> }
> {code}
> 2. Query the document
> {code:json}
> {
> "response":{"numFound":1,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"a",
> "n_s":"s1",
> "pre":"Alaska",
> "_version_":1647475215142223872}]
> }}
> {code}
> 3. Update using atomic syntax
> {code:json}
> {
> "add": {
> "doc": {
> "id": "a",
> "n_s": {"set": "s2"}
> }}}
> {code}
> 4. Observe the warning in solr log
> UI:
> {noformat}
> WARN x:techproducts_shard2_replica_n6 PreAnalyzedField Error parsing
> pre-analyzed field 'pre'
> {noformat}
> solr.log:
> {noformat}
> WARN (qtp1384454980-23) [c:techproducts s:shard2 r:core_node8
> x:techproducts_shard2_replica_n6] o.a.s.s.PreAnalyzedField Error parsing
> pre-analyzed field 'pre' => java.io.IOException: Invalid JSON type
> java.lang.String, expected Map
> at
> org.apache.solr.schema.JsonPreAnalyzedParser.parse(JsonPreAnalyzedParser.java:86)
> {noformat}
> 5. Query the document again
> {code:json}
> {
> "response":{"numFound":1,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"a",
> "n_s":"s2",
> "_version_":1647475461695995904}]
> }}
> {code}
> *Result*: There is no 'pre' field in the document anymore.
> _My thoughts on it_
> 1. Data loss can be prevented if the warning will be replaced with error
> (re-throwing exception). Atomic updates for such documents still won't work,
> but updates will be explicitly rejected.
> 2. Solr tries to read the document from index, merge it with input document
> and re-index the document, but when it reads indexed pre-analyzed fields the
> format is different, so Solr cannot parse and re-index those fields properly.
--
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
[jira] [Commented] (SOLR-12490) Query DSL supports for further referring and exclusion in JSON facets
[
https://issues.apache.org/jira/browse/SOLR-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16955801#comment-16955801
]
Mikhail Khludnev commented on SOLR-12490:
-
Renamed it \{!json} to avoid clash with nestedQP. Here how it looks now:
!image-2019-10-21-09-37-37-118.png!
> Query DSL supports for further referring and exclusion in JSON facets
> --
>
> Key: SOLR-12490
> URL: https://issues.apache.org/jira/browse/SOLR-12490
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module, faceting
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newdev
> Attachments: SOLR-12490.patch, SOLR-12490.patch,
> image-2019-10-21-09-37-37-118.png
>
>
> It's spin off from the
> [discussion|https://issues.apache.org/jira/browse/SOLR-9685?focusedCommentId=16508720&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16508720].
>
> h2. Problem
> # after SOLR-9685 we can tag separate clauses in hairish queries like
> {{parent}}, {{bool}}
> # we can {{domain.excludeTags}}
> # we are looking for child faceting with exclusions, see SOLR-9510, SOLR-8998
>
> # but we can refer only separate params in {{domain.filter}}, it's not
> possible to refer separate clauses
> see the first comment
--
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
[jira] [Updated] (SOLR-12490) Query DSL supports for further referring and exclusion in JSON facets
[
https://issues.apache.org/jira/browse/SOLR-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-12490:
Attachment: image-2019-10-21-09-37-37-118.png
> Query DSL supports for further referring and exclusion in JSON facets
> --
>
> Key: SOLR-12490
> URL: https://issues.apache.org/jira/browse/SOLR-12490
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module, faceting
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newdev
> Attachments: SOLR-12490.patch, SOLR-12490.patch,
> image-2019-10-21-09-37-37-118.png
>
>
> It's spin off from the
> [discussion|https://issues.apache.org/jira/browse/SOLR-9685?focusedCommentId=16508720&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16508720].
>
> h2. Problem
> # after SOLR-9685 we can tag separate clauses in hairish queries like
> {{parent}}, {{bool}}
> # we can {{domain.excludeTags}}
> # we are looking for child faceting with exclusions, see SOLR-9510, SOLR-8998
>
> # but we can refer only separate params in {{domain.filter}}, it's not
> possible to refer separate clauses
> see the first comment
--
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
[jira] [Updated] (SOLR-12490) Query DSL supports for further referring and exclusion in JSON facets
[
https://issues.apache.org/jira/browse/SOLR-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-12490:
Attachment: SOLR-12490.patch
> Query DSL supports for further referring and exclusion in JSON facets
> --
>
> Key: SOLR-12490
> URL: https://issues.apache.org/jira/browse/SOLR-12490
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module, faceting
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newdev
> Attachments: SOLR-12490.patch, SOLR-12490.patch
>
>
> It's spin off from the
> [discussion|https://issues.apache.org/jira/browse/SOLR-9685?focusedCommentId=16508720&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16508720].
>
> h2. Problem
> # after SOLR-9685 we can tag separate clauses in hairish queries like
> {{parent}}, {{bool}}
> # we can {{domain.excludeTags}}
> # we are looking for child faceting with exclusions, see SOLR-9510, SOLR-8998
>
> # but we can refer only separate params in {{domain.filter}}, it's not
> possible to refer separate clauses
> see the first comment
--
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
[jira] [Updated] (SOLR-12490) Query DSL supports for further referring and exclusion in JSON facets
[
https://issues.apache.org/jira/browse/SOLR-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-12490:
Attachment: (was: SOLR-12490.patch)
> Query DSL supports for further referring and exclusion in JSON facets
> --
>
> Key: SOLR-12490
> URL: https://issues.apache.org/jira/browse/SOLR-12490
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module, faceting
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newdev
> Attachments: SOLR-12490.patch, SOLR-12490.patch
>
>
> It's spin off from the
> [discussion|https://issues.apache.org/jira/browse/SOLR-9685?focusedCommentId=16508720&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16508720].
>
> h2. Problem
> # after SOLR-9685 we can tag separate clauses in hairish queries like
> {{parent}}, {{bool}}
> # we can {{domain.excludeTags}}
> # we are looking for child faceting with exclusions, see SOLR-9510, SOLR-8998
>
> # but we can refer only separate params in {{domain.filter}}, it's not
> possible to refer separate clauses
> see the first comment
--
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
[jira] [Commented] (SOLR-12490) Query DSL supports for further referring and exclusion in JSON facets
[
https://issues.apache.org/jira/browse/SOLR-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16955240#comment-16955240
]
Mikhail Khludnev commented on SOLR-12490:
-
Ok, now it's called \{!query} but it seems odd. Now, qparser handles all
possible cases. See TestJsonRequest in the patch.
> Query DSL supports for further referring and exclusion in JSON facets
> --
>
> Key: SOLR-12490
> URL: https://issues.apache.org/jira/browse/SOLR-12490
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module, faceting
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newdev
> Attachments: SOLR-12490.patch, SOLR-12490.patch
>
>
> It's spin off from the
> [discussion|https://issues.apache.org/jira/browse/SOLR-9685?focusedCommentId=16508720&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16508720].
>
> h2. Problem
> # after SOLR-9685 we can tag separate clauses in hairish queries like
> {{parent}}, {{bool}}
> # we can {{domain.excludeTags}}
> # we are looking for child faceting with exclusions, see SOLR-9510, SOLR-8998
>
> # but we can refer only separate params in {{domain.filter}}, it's not
> possible to refer separate clauses
> see the first comment
--
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
[jira] [Issue Comment Deleted] (SOLR-12490) Query DSL supports for further referring and exclusion in JSON facets
[
https://issues.apache.org/jira/browse/SOLR-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-12490:
Comment: was deleted
(was: Ok, now it's called {{{!query} }}but it seems odd. Now, qparser handles
all possible cases.
{code:java}
client.testJQ( params("json","{query:'cat_s:A'}", "json","{filter:'{!query
v=$whereNY}'}",
"json","{params:{whereNY:{field:{f:where_s, query:NY" )
, "response/numFound==1"
);
client.testJQ( params("json","{query:'cat_s:A'}", "json","{filter:'{!query
v=whereNY}'}",
"json","{params:{whereNY:{field:{f:where_s, query:NY" )
, "response/numFound==1"
);
client.testJQ( params("json","{query:'cat_s:A'}",
"json","{filter:'{!query}whereNY'}",
"json","{params:{whereNY:{field:{f:where_s, query:NY" )
, "response/numFound==1"
);
client.testJQ(params("json", "{query:'cat_s:A'}", "json",
"{filter:{query:{query:whereNY}}}",
"json", "{params:{whereNY:{field:{f:where_s, query:NY"),
"response/numFound==1");
client.testJQ( params("json","{query:'cat_s:A'}",
"json","{filter:{query:{query:$whereNY}}}",
"json","{params:{whereNY:{field:{f:where_s, query:NY" )
, "response/numFound==1"
);
client.testJQ( params("json","{query:'cat_s:A'}",
"json","{filter:{query:{query:$whereNY}}}",
"whereNY","{field:{f:where_s, query:NY}}" )
, "response/numFound==1"
);
{code})
> Query DSL supports for further referring and exclusion in JSON facets
> --
>
> Key: SOLR-12490
> URL: https://issues.apache.org/jira/browse/SOLR-12490
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module, faceting
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newdev
> Attachments: SOLR-12490.patch, SOLR-12490.patch
>
>
> It's spin off from the
> [discussion|https://issues.apache.org/jira/browse/SOLR-9685?focusedCommentId=16508720&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16508720].
>
> h2. Problem
> # after SOLR-9685 we can tag separate clauses in hairish queries like
> {{parent}}, {{bool}}
> # we can {{domain.excludeTags}}
> # we are looking for child faceting with exclusions, see SOLR-9510, SOLR-8998
>
> # but we can refer only separate params in {{domain.filter}}, it's not
> possible to refer separate clauses
> see the first comment
--
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
[jira] [Commented] (SOLR-12490) Query DSL supports for further referring and exclusion in JSON facets
[
https://issues.apache.org/jira/browse/SOLR-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16955238#comment-16955238
]
Mikhail Khludnev commented on SOLR-12490:
-
Ok, now it's called {{{!query} }}but it seems odd. Now, qparser handles all
possible cases.
{code:java}
client.testJQ( params("json","{query:'cat_s:A'}", "json","{filter:'{!query
v=$whereNY}'}",
"json","{params:{whereNY:{field:{f:where_s, query:NY" )
, "response/numFound==1"
);
client.testJQ( params("json","{query:'cat_s:A'}", "json","{filter:'{!query
v=whereNY}'}",
"json","{params:{whereNY:{field:{f:where_s, query:NY" )
, "response/numFound==1"
);
client.testJQ( params("json","{query:'cat_s:A'}",
"json","{filter:'{!query}whereNY'}",
"json","{params:{whereNY:{field:{f:where_s, query:NY" )
, "response/numFound==1"
);
client.testJQ(params("json", "{query:'cat_s:A'}", "json",
"{filter:{query:{query:whereNY}}}",
"json", "{params:{whereNY:{field:{f:where_s, query:NY"),
"response/numFound==1");
client.testJQ( params("json","{query:'cat_s:A'}",
"json","{filter:{query:{query:$whereNY}}}",
"json","{params:{whereNY:{field:{f:where_s, query:NY" )
, "response/numFound==1"
);
client.testJQ( params("json","{query:'cat_s:A'}",
"json","{filter:{query:{query:$whereNY}}}",
"whereNY","{field:{f:where_s, query:NY}}" )
, "response/numFound==1"
);
{code}
> Query DSL supports for further referring and exclusion in JSON facets
> --
>
> Key: SOLR-12490
> URL: https://issues.apache.org/jira/browse/SOLR-12490
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module, faceting
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newdev
> Attachments: SOLR-12490.patch, SOLR-12490.patch
>
>
> It's spin off from the
> [discussion|https://issues.apache.org/jira/browse/SOLR-9685?focusedCommentId=16508720&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16508720].
>
> h2. Problem
> # after SOLR-9685 we can tag separate clauses in hairish queries like
> {{parent}}, {{bool}}
> # we can {{domain.excludeTags}}
> # we are looking for child faceting with exclusions, see SOLR-9510, SOLR-8998
>
> # but we can refer only separate params in {{domain.filter}}, it's not
> possible to refer separate clauses
> see the first comment
--
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
[jira] [Updated] (SOLR-12490) Query DSL supports for further referring and exclusion in JSON facets
[
https://issues.apache.org/jira/browse/SOLR-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-12490:
Attachment: SOLR-12490.patch
Status: Patch Available (was: Patch Available)
> Query DSL supports for further referring and exclusion in JSON facets
> --
>
> Key: SOLR-12490
> URL: https://issues.apache.org/jira/browse/SOLR-12490
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module, faceting
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newdev
> Attachments: SOLR-12490.patch, SOLR-12490.patch
>
>
> It's spin off from the
> [discussion|https://issues.apache.org/jira/browse/SOLR-9685?focusedCommentId=16508720&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16508720].
>
> h2. Problem
> # after SOLR-9685 we can tag separate clauses in hairish queries like
> {{parent}}, {{bool}}
> # we can {{domain.excludeTags}}
> # we are looking for child faceting with exclusions, see SOLR-9510, SOLR-8998
>
> # but we can refer only separate params in {{domain.filter}}, it's not
> possible to refer separate clauses
> see the first comment
--
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
[jira] [Commented] (SOLR-13824) JSON Request API ignores prematurely closing curly brace.
[
https://issues.apache.org/jira/browse/SOLR-13824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16955121#comment-16955121
]
Mikhail Khludnev commented on SOLR-13824:
-
Summary:
* fixed incorrect json payload in several tests;
* reveal at least three "assert masking" across tests
* ObjectBuilder got new getValStrict() assuming (and even asserting) that
correct json and only it is passed on input.
* Utils.fromJSON() method now is strict.
What's the enough pause to let every one who like review the patch?
It's probably worth to ping [~arafalov] as a JSON practitioner.
> JSON Request API ignores prematurely closing curly brace.
> --
>
> Key: SOLR-13824
> URL: https://issues.apache.org/jira/browse/SOLR-13824
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JSON Request API
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13824.patch, SOLR-13824.patch, SOLR-13824.patch,
> SOLR-13824.patch
>
>
> {code:java}
> json={query:"content:foo", facet:{zz:{field:id}}}
> {code}
> this works fine, but if we mistype {{}}} instead of {{,}}
> {code:java}
> json={query:"content:foo"} facet:{zz:{field:id}}}
> {code}
> It's captured only partially, here's we have under debug
> {code:java}
> "json":{"query":"content:foo"},
> {code}
> I suppose it should throw an error with 400 code.
--
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
[jira] [Commented] (SOLR-9685) tag a query in JSON syntax
[
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16954663#comment-16954663
]
Mikhail Khludnev commented on SOLR-9685:
Why did we introduced that curly syntax if just using property/logcal param
should work?
{code:java}
{lucene :{query:'foo:bar', tag:'bar'}}
{code}
> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, 8.0
>
> Attachments: SOLR-9685-doc.patch, SOLR-9685-doc.patch,
> SOLR-9685.patch, SOLR-9685.patch, SOLR-9685.patch
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}
--
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
[jira] [Updated] (SOLR-13824) JSON Request API ignores prematurely closing curly brace.
[
https://issues.apache.org/jira/browse/SOLR-13824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13824:
Attachment: SOLR-13824.patch
Status: Patch Available (was: Patch Available)
> JSON Request API ignores prematurely closing curly brace.
> --
>
> Key: SOLR-13824
> URL: https://issues.apache.org/jira/browse/SOLR-13824
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JSON Request API
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13824.patch, SOLR-13824.patch, SOLR-13824.patch,
> SOLR-13824.patch
>
>
> {code:java}
> json={query:"content:foo", facet:{zz:{field:id}}}
> {code}
> this works fine, but if we mistype {{}}} instead of {{,}}
> {code:java}
> json={query:"content:foo"} facet:{zz:{field:id}}}
> {code}
> It's captured only partially, here's we have under debug
> {code:java}
> "json":{"query":"content:foo"},
> {code}
> I suppose it should throw an error with 400 code.
--
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
[jira] [Commented] (SOLR-12490) Query DSL supports for further referring and exclusion in JSON facets
[
https://issues.apache.org/jira/browse/SOLR-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16954302#comment-16954302
]
Mikhail Khludnev commented on SOLR-12490:
-
Thanks, [~dsmiley] for your comment, although tagging were discussed under
SOLR-9685. What do you think about {{{!json_param}}} trick?
> Query DSL supports for further referring and exclusion in JSON facets
> --
>
> Key: SOLR-12490
> URL: https://issues.apache.org/jira/browse/SOLR-12490
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module, faceting
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newdev
> Attachments: SOLR-12490.patch
>
>
> It's spin off from the
> [discussion|https://issues.apache.org/jira/browse/SOLR-9685?focusedCommentId=16508720&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16508720].
>
> h2. Problem
> # after SOLR-9685 we can tag separate clauses in hairish queries like
> {{parent}}, {{bool}}
> # we can {{domain.excludeTags}}
> # we are looking for child faceting with exclusions, see SOLR-9510, SOLR-8998
>
> # but we can refer only separate params in {{domain.filter}}, it's not
> possible to refer separate clauses
> see the first comment
--
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
[jira] [Updated] (SOLR-13824) JSON Request API ignores prematurely closing curly brace.
[
https://issues.apache.org/jira/browse/SOLR-13824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13824:
Attachment: SOLR-13824.patch
> JSON Request API ignores prematurely closing curly brace.
> --
>
> Key: SOLR-13824
> URL: https://issues.apache.org/jira/browse/SOLR-13824
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JSON Request API
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13824.patch, SOLR-13824.patch, SOLR-13824.patch
>
>
> {code:java}
> json={query:"content:foo", facet:{zz:{field:id}}}
> {code}
> this works fine, but if we mistype {{}}} instead of {{,}}
> {code:java}
> json={query:"content:foo"} facet:{zz:{field:id}}}
> {code}
> It's captured only partially, here's we have under debug
> {code:java}
> "json":{"query":"content:foo"},
> {code}
> I suppose it should throw an error with 400 code.
--
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
[jira] [Commented] (SOLR-13808) Query DSL should let to cache filter
[
https://issues.apache.org/jira/browse/SOLR-13808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16952969#comment-16952969
]
Mikhail Khludnev commented on SOLR-13808:
-
Ok. It seems like the plan is to
# create \{!cache} query parser to hook it up by existing DSL. Caveat for
users is loosing scoring.
# enable cache by default for \{!bool filter=... filter=..}
# make sure that it sensitive for \{!cache=false} local param for enclosing
queries
I'm fine with it and patches are welcome.
> Query DSL should let to cache filter
>
>
> Key: SOLR-13808
> URL: https://issues.apache.org/jira/browse/SOLR-13808
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Major
>
> Query DSL let to express Lucene BQ's filter
>
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar"}}} }}{code}
> However, it might easily catch the need in caching it in filter cache. This
> might rely on ExtensibleQuery and QParser:
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar", cache:true}}} }}
> {code}
>
--
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
[jira] [Updated] (SOLR-13824) JSON Request API ignores prematurely closing curly brace.
[
https://issues.apache.org/jira/browse/SOLR-13824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13824:
Attachment: (was: SOLR-13824.patch)
> JSON Request API ignores prematurely closing curly brace.
> --
>
> Key: SOLR-13824
> URL: https://issues.apache.org/jira/browse/SOLR-13824
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JSON Request API
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13824.patch, SOLR-13824.patch
>
>
> {code:java}
> json={query:"content:foo", facet:{zz:{field:id}}}
> {code}
> this works fine, but if we mistype {{}}} instead of {{,}}
> {code:java}
> json={query:"content:foo"} facet:{zz:{field:id}}}
> {code}
> It's captured only partially, here's we have under debug
> {code:java}
> "json":{"query":"content:foo"},
> {code}
> I suppose it should throw an error with 400 code.
--
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
[jira] [Updated] (SOLR-13824) JSON Request API ignores prematurely closing curly brace.
[
https://issues.apache.org/jira/browse/SOLR-13824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13824:
Attachment: SOLR-13824.patch
> JSON Request API ignores prematurely closing curly brace.
> --
>
> Key: SOLR-13824
> URL: https://issues.apache.org/jira/browse/SOLR-13824
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JSON Request API
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13824.patch, SOLR-13824.patch
>
>
> {code:java}
> json={query:"content:foo", facet:{zz:{field:id}}}
> {code}
> this works fine, but if we mistype {{}}} instead of {{,}}
> {code:java}
> json={query:"content:foo"} facet:{zz:{field:id}}}
> {code}
> It's captured only partially, here's we have under debug
> {code:java}
> "json":{"query":"content:foo"},
> {code}
> I suppose it should throw an error with 400 code.
--
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
[jira] [Commented] (SOLR-13403) Terms component fails for DatePointField
[ https://issues.apache.org/jira/browse/SOLR-13403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16952769#comment-16952769 ] Mikhail Khludnev commented on SOLR-13403: - patch makes sense > Terms component fails for DatePointField > > > Key: SOLR-13403 > URL: https://issues.apache.org/jira/browse/SOLR-13403 > Project: Solr > Issue Type: Bug > Components: SearchComponents - other >Reporter: Munendra S N >Assignee: Munendra S N >Priority: Major > Attachments: SOLR-13403.patch, SOLR-13403.patch, SOLR-13403.patch > > > Getting terms for PointFields except DatePointField. For DatePointField, the > request fails NPE -- 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
[jira] [Updated] (SOLR-13824) JSON Request API ignores prematurely closing curly brace.
[
https://issues.apache.org/jira/browse/SOLR-13824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13824:
Attachment: SOLR-13824.patch
> JSON Request API ignores prematurely closing curly brace.
> --
>
> Key: SOLR-13824
> URL: https://issues.apache.org/jira/browse/SOLR-13824
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JSON Request API
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13824.patch, SOLR-13824.patch
>
>
> {code:java}
> json={query:"content:foo", facet:{zz:{field:id}}}
> {code}
> this works fine, but if we mistype {{}}} instead of {{,}}
> {code:java}
> json={query:"content:foo"} facet:{zz:{field:id}}}
> {code}
> It's captured only partially, here's we have under debug
> {code:java}
> "json":{"query":"content:foo"},
> {code}
> I suppose it should throw an error with 400 code.
--
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
[jira] [Updated] (SOLR-13824) JSON Request API ignores prematurely closing curly brace.
[
https://issues.apache.org/jira/browse/SOLR-13824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13824:
Attachment: (was: SOLR-13824.patch)
> JSON Request API ignores prematurely closing curly brace.
> --
>
> Key: SOLR-13824
> URL: https://issues.apache.org/jira/browse/SOLR-13824
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JSON Request API
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13824.patch
>
>
> {code:java}
> json={query:"content:foo", facet:{zz:{field:id}}}
> {code}
> this works fine, but if we mistype {{}}} instead of {{,}}
> {code:java}
> json={query:"content:foo"} facet:{zz:{field:id}}}
> {code}
> It's captured only partially, here's we have under debug
> {code:java}
> "json":{"query":"content:foo"},
> {code}
> I suppose it should throw an error with 400 code.
--
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
[jira] [Updated] (SOLR-13824) JSON Request API ignores prematurely closing curly brace.
[
https://issues.apache.org/jira/browse/SOLR-13824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13824:
Attachment: SOLR-13824.patch
> JSON Request API ignores prematurely closing curly brace.
> --
>
> Key: SOLR-13824
> URL: https://issues.apache.org/jira/browse/SOLR-13824
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JSON Request API
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13824.patch, SOLR-13824.patch
>
>
> {code:java}
> json={query:"content:foo", facet:{zz:{field:id}}}
> {code}
> this works fine, but if we mistype {{}}} instead of {{,}}
> {code:java}
> json={query:"content:foo"} facet:{zz:{field:id}}}
> {code}
> It's captured only partially, here's we have under debug
> {code:java}
> "json":{"query":"content:foo"},
> {code}
> I suppose it should throw an error with 400 code.
--
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
[jira] [Commented] (SOLR-13824) JSON Request API ignores prematurely closing curly brace.
[
https://issues.apache.org/jira/browse/SOLR-13824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16950962#comment-16950962
]
Mikhail Khludnev commented on SOLR-13824:
-
Nice failures, ha?
Thank you, [~munendrasn] for your feedback. I'll go through points one-by one
this week.
> JSON Request API ignores prematurely closing curly brace.
> --
>
> Key: SOLR-13824
> URL: https://issues.apache.org/jira/browse/SOLR-13824
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JSON Request API
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13824.patch
>
>
> {code:java}
> json={query:"content:foo", facet:{zz:{field:id}}}
> {code}
> this works fine, but if we mistype {{}}} instead of {{,}}
> {code:java}
> json={query:"content:foo"} facet:{zz:{field:id}}}
> {code}
> It's captured only partially, here's we have under debug
> {code:java}
> "json":{"query":"content:foo"},
> {code}
> I suppose it should throw an error with 400 code.
--
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
