[jira] [Closed] (LUCENE-7863) Don't repeat postings (and perhaps positions) on ReverseWF, EdgeNGram, etc
[
https://issues.apache.org/jira/browse/LUCENE-7863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev closed LUCENE-7863.
Lucene Fields: (was: New)
> Don't repeat postings (and perhaps positions) on ReverseWF, EdgeNGram, etc
>
>
> Key: LUCENE-7863
> URL: https://issues.apache.org/jira/browse/LUCENE-7863
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/index
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: LUCENE-7863.hazard, LUCENE-7863.patch,
> LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch,
> LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch,
> LUCENE-7863.patch, bench-byte-array-long.out, bench-byte-array2.out,
> benchmark-1m.out, byterefshash-bench.txt
>
>
> h2. Context
> \*suffix and \*infix\* searches on large indexes.
> h2. Problem
> Obviously applying {{ReversedWildcardFilter}} doubles an index size, and I'm
> shuddering to think about EdgeNGrams...
> h2. Proposal
> _DR_-Y- postings
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-7863) Don't repeat postings (and perhaps positions) on ReverseWF, EdgeNGram, etc
[
https://issues.apache.org/jira/browse/LUCENE-7863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev resolved LUCENE-7863.
--
Resolution: Won't Fix
> Don't repeat postings (and perhaps positions) on ReverseWF, EdgeNGram, etc
>
>
> Key: LUCENE-7863
> URL: https://issues.apache.org/jira/browse/LUCENE-7863
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/index
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: LUCENE-7863.hazard, LUCENE-7863.patch,
> LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch,
> LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch,
> LUCENE-7863.patch, bench-byte-array-long.out, bench-byte-array2.out,
> benchmark-1m.out, byterefshash-bench.txt
>
>
> h2. Context
> \*suffix and \*infix\* searches on large indexes.
> h2. Problem
> Obviously applying {{ReversedWildcardFilter}} doubles an index size, and I'm
> shuddering to think about EdgeNGrams...
> h2. Proposal
> _DR_-Y- postings
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Closed] (LUCENE-9360) might be NEEDED. ToParentDocValues uses advanceExact() of underneath DocValues
[
https://issues.apache.org/jira/browse/LUCENE-9360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev closed LUCENE-9360.
> might be NEEDED. ToParentDocValues uses advanceExact() of underneath DocValues
> --
>
> Key: LUCENE-9360
> URL: https://issues.apache.org/jira/browse/LUCENE-9360
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Mikhail Khludnev
>Priority: Major
>
> Currently {{ToParentDocvalues.advanceExact()}} propagates it to
> {{DocValues.advance()}} as advised at LUCENE-7871. It causes some problem at
> LUCENE-9328 and seems not really reasonable. The later jira has patch
> attached which resolves this. The questions is why(not)?
> cc [~jpountz]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9360) might be NEEDED. ToParentDocValues uses advanceExact() of underneath DocValues
[
https://issues.apache.org/jira/browse/LUCENE-9360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev resolved LUCENE-9360.
--
Resolution: Won't Fix
will be addressed under enclosing issue
> might be NEEDED. ToParentDocValues uses advanceExact() of underneath DocValues
> --
>
> Key: LUCENE-9360
> URL: https://issues.apache.org/jira/browse/LUCENE-9360
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Mikhail Khludnev
>Priority: Major
>
> Currently {{ToParentDocvalues.advanceExact()}} propagates it to
> {{DocValues.advance()}} as advised at LUCENE-7871. It causes some problem at
> LUCENE-9328 and seems not really reasonable. The later jira has patch
> attached which resolves this. The questions is why(not)?
> cc [~jpountz]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Closed] (LUCENE-9357) AssertingSorted(Set|Numeric)DocValues should be unwrappable
[
https://issues.apache.org/jira/browse/LUCENE-9357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev closed LUCENE-9357.
> AssertingSorted(Set|Numeric)DocValues should be unwrappable
> ---
>
> Key: LUCENE-9357
> URL: https://issues.apache.org/jira/browse/LUCENE-9357
> Project: Lucene - Core
> Issue Type: Sub-task
> Components: modules/test-framework
>Reporter: Mikhail Khludnev
>Priority: Minor
>
> # Obviously singular docValues might mimic multivalued ones via
> {{DocValues.singleton()}}. However, some algorithms prefers to
> {{DocValues.unwrap()}} them if possible.
> # AssertingDocValues blocks this unwrapping slightly changing codepath for
> singular DVs.
> h3. AS IS
> {{AssertingDV -> Singleton -> SingularDV}}
> h3. TODO
> {{Singleton -> AssertingDV -> SingularDV}}
> I think it's trivial, worthwhile and 0% risk. Are there any concerns?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9357) AssertingSorted(Set|Numeric)DocValues should be unwrappable
[
https://issues.apache.org/jira/browse/LUCENE-9357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev resolved LUCENE-9357.
--
Resolution: Won't Fix
will be addressed in enclosing issue
> AssertingSorted(Set|Numeric)DocValues should be unwrappable
> ---
>
> Key: LUCENE-9357
> URL: https://issues.apache.org/jira/browse/LUCENE-9357
> Project: Lucene - Core
> Issue Type: Sub-task
> Components: modules/test-framework
>Reporter: Mikhail Khludnev
>Priority: Minor
>
> # Obviously singular docValues might mimic multivalued ones via
> {{DocValues.singleton()}}. However, some algorithms prefers to
> {{DocValues.unwrap()}} them if possible.
> # AssertingDocValues blocks this unwrapping slightly changing codepath for
> singular DVs.
> h3. AS IS
> {{AssertingDV -> Singleton -> SingularDV}}
> h3. TODO
> {{Singleton -> AssertingDV -> SingularDV}}
> I think it's trivial, worthwhile and 0% risk. Are there any concerns?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Deleted] (SOLR-15050) Проводка Москвич 2140
[ https://issues.apache.org/jira/browse/SOLR-15050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev deleted SOLR-15050: > Проводка Москвич 2140 > - > > Key: SOLR-15050 > URL: https://issues.apache.org/jira/browse/SOLR-15050 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Environment: ||Основные|| > |Марка|Москвич| > |Модель|2140| > |Тип|Автомобильные провода| > |Производитель |Wire& aвтопроводка| > |Страна производитель|Украина| > |Тип запчасти|Оригинал| > |Тип техники|Легковой автомобиль| > |Код запчасти|1082| > |Состояние|Новое| > https://avto-pro.com.ua/p1136095013-provodka-moskvich-2140.html >Reporter: Vladimir >Priority: Major > Labels: Проводка > > !2365641414_w640_h640_2365641414.jpg|width=179,height=179! > Проводка на Москвич 2140 > 1. Жгут проводов основной. > 2. Жгут проводов задняя часть. > [https://avto-pro.com.ua/p1136095013-provodka-moskvich-2140.html] > Проводка от Каменец-Подольского производителя, это всегда гарантия качества, > доступные цены и быстрая доставка. > Будем рады сотрудничать, как с частными лицами, предпринимателями так и с > предприятиями. > ** -- 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=17249741#comment-17249741 ] Mikhail Khludnev commented on LUCENE-9021: -- Thanks, [~pbruski_]. It seems we've done here. I'm wondering why javacc can't optimize it itself. > 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 >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.8 > > Attachments: LUCENE-9021.patch > > Time Spent: 1h > 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-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: - Fix Version/s: 8.8 Assignee: Mikhail Khludnev Resolution: Fixed Status: Resolved (was: Patch Available) > 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 >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.8 > > Attachments: LUCENE-9021.patch > > Time Spent: 1h > 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] (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=17248362#comment-17248362
]
Mikhail Khludnev commented on LUCENE-9021:
--
Pushed to master. Thanks, [~pbruski_]. Would you mind to take care for PR
against {{branch_8x}}?
> 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: 40m
> 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] [Issue Comment Deleted] (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: - Comment: was deleted (was: Commit 6dfb55d5956bb27a05a3bc184df10705fe835ad8 in lucene-solr's branch refs/heads/revert-962-jira/LUCENE-9021 from Mikhail Khludnev [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6dfb55d ] Revert "LUCENE-9021 QueryParser: re-use the LookaheadSuccess exception (#962)" This reverts commit ccf3e604537e884e25d33dc9d921cc5e5e1fa284. ) > 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: 40m > 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] (SOLR-8673) o.a.s.search.facet classes not public/extendable
[
https://issues.apache.org/jira/browse/SOLR-8673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-8673:
---
Assignee: Mikhail Khludnev
Resolution: Fixed
Status: Resolved (was: Patch Available)
> o.a.s.search.facet classes not public/extendable
>
>
> Key: SOLR-8673
> URL: https://issues.apache.org/jira/browse/SOLR-8673
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Affects Versions: 5.4.1
>Reporter: Markus Jelsma
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.8
>
> Attachments: SOLR-8673.patch, SOLR-8673.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> It is not easy to create a custom JSON facet function. A simple function
> based on AvgAgg quickly results in the following compilation failures:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile)
> on project openindex-solr: Compilation failure: Compilation failure:
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[22,36]
> org.apache.solr.search.facet.FacetContext is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[23,36]
> org.apache.solr.search.facet.FacetDoubleMerger is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[40,32]
> cannot find symbol
> [ERROR] symbol: class FacetContext
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[49,39]
> cannot find symbol
> [ERROR] symbol: class FacetDoubleMerger
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[54,43]
> cannot find symbol
> [ERROR] symbol: class Context
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg.Merger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[41,16]
> cannot find symbol
> [ERROR] symbol: class AvgSlotAcc
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[46,12]
> incompatible types: i.o.s.search.facet.CustomAvgAgg.Merger cannot be
> converted to org.apache.solr.search.facet.FacetMerger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[53,5]
> method does not override or implement a method from a supertype
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[60,5]
> method does not override or implement a method from a supertype
> {code}
> It seems lots of classes are tucked away in FacetModule, which we can't reach
> from outside.
> Originates from this thread:
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201602.mbox/%3ccab_8yd9ldbg_0zxm_h1igkfm6bqeypd5ilyy7tty8cztscv...@mail.gmail.com%3E
> ( also available at
> https://lists.apache.org/thread.html/9fddcad3136ec908ce1c57881f8d3069e5d153f08b71f80f3e18d995%401455019826%40%3Csolr-user.lucene.apache.org%3E
> )
--
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-8673) o.a.s.search.facet classes not public/extendable
[
https://issues.apache.org/jira/browse/SOLR-8673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-8673:
---
Fix Version/s: (was: 6.2)
(was: 7.0)
8.8
> o.a.s.search.facet classes not public/extendable
>
>
> Key: SOLR-8673
> URL: https://issues.apache.org/jira/browse/SOLR-8673
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Affects Versions: 5.4.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 8.8
>
> Attachments: SOLR-8673.patch, SOLR-8673.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> It is not easy to create a custom JSON facet function. A simple function
> based on AvgAgg quickly results in the following compilation failures:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile)
> on project openindex-solr: Compilation failure: Compilation failure:
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[22,36]
> org.apache.solr.search.facet.FacetContext is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[23,36]
> org.apache.solr.search.facet.FacetDoubleMerger is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[40,32]
> cannot find symbol
> [ERROR] symbol: class FacetContext
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[49,39]
> cannot find symbol
> [ERROR] symbol: class FacetDoubleMerger
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[54,43]
> cannot find symbol
> [ERROR] symbol: class Context
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg.Merger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[41,16]
> cannot find symbol
> [ERROR] symbol: class AvgSlotAcc
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[46,12]
> incompatible types: i.o.s.search.facet.CustomAvgAgg.Merger cannot be
> converted to org.apache.solr.search.facet.FacetMerger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[53,5]
> method does not override or implement a method from a supertype
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[60,5]
> method does not override or implement a method from a supertype
> {code}
> It seems lots of classes are tucked away in FacetModule, which we can't reach
> from outside.
> Originates from this thread:
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201602.mbox/%3ccab_8yd9ldbg_0zxm_h1igkfm6bqeypd5ilyy7tty8cztscv...@mail.gmail.com%3E
> ( also available at
> https://lists.apache.org/thread.html/9fddcad3136ec908ce1c57881f8d3069e5d153f08b71f80f3e18d995%401455019826%40%3Csolr-user.lucene.apache.org%3E
> )
--
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-8673) o.a.s.search.facet classes not public/extendable
[
https://issues.apache.org/jira/browse/SOLR-8673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245843#comment-17245843
]
Mikhail Khludnev edited comment on SOLR-8673 at 12/8/20, 1:49 PM:
--
[https://builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.x/1027/testReport/org.apache.solr.search.function/AggValueSourceTest/]
https://builds.apache.org/job/Lucene/job/Lucene-Solr-NightlyTests-master/lastCompletedBuild/testReport/org.apache.solr.search.function/AggValueSourceTest/
Fixed.
was (Author: mkhludnev):
[https://builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.x/1027/testReport/org.apache.solr.search.function/AggValueSourceTest/]
Fixed.
> o.a.s.search.facet classes not public/extendable
>
>
> Key: SOLR-8673
> URL: https://issues.apache.org/jira/browse/SOLR-8673
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Affects Versions: 5.4.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 6.2, 7.0
>
> Attachments: SOLR-8673.patch, SOLR-8673.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> It is not easy to create a custom JSON facet function. A simple function
> based on AvgAgg quickly results in the following compilation failures:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile)
> on project openindex-solr: Compilation failure: Compilation failure:
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[22,36]
> org.apache.solr.search.facet.FacetContext is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[23,36]
> org.apache.solr.search.facet.FacetDoubleMerger is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[40,32]
> cannot find symbol
> [ERROR] symbol: class FacetContext
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[49,39]
> cannot find symbol
> [ERROR] symbol: class FacetDoubleMerger
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[54,43]
> cannot find symbol
> [ERROR] symbol: class Context
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg.Merger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[41,16]
> cannot find symbol
> [ERROR] symbol: class AvgSlotAcc
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[46,12]
> incompatible types: i.o.s.search.facet.CustomAvgAgg.Merger cannot be
> converted to org.apache.solr.search.facet.FacetMerger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[53,5]
> method does not override or implement a method from a supertype
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[60,5]
> method does not override or implement a method from a supertype
> {code}
> It seems lots of classes are tucked away in FacetModule, which we can't reach
> from outside.
> Originates from this thread:
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201602.mbox/%3ccab_8yd9ldbg_0zxm_h1igkfm6bqeypd5ilyy7tty8cztscv...@mail.gmail.com%3E
> ( also available at
> https://lists.apache.org/thread.html/9fddcad3136ec908ce1c57881f8d3069e5d153f08b71f80f3e18d995%401455019826%40%3Csolr-user.lucene.apache.org%3E
> )
--
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-8673) o.a.s.search.facet classes not public/extendable
[
https://issues.apache.org/jira/browse/SOLR-8673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245843#comment-17245843
]
Mikhail Khludnev commented on SOLR-8673:
[https://builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.x/1027/testReport/org.apache.solr.search.function/AggValueSourceTest/]
Fixed.
> o.a.s.search.facet classes not public/extendable
>
>
> Key: SOLR-8673
> URL: https://issues.apache.org/jira/browse/SOLR-8673
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Affects Versions: 5.4.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 6.2, 7.0
>
> Attachments: SOLR-8673.patch, SOLR-8673.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> It is not easy to create a custom JSON facet function. A simple function
> based on AvgAgg quickly results in the following compilation failures:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile)
> on project openindex-solr: Compilation failure: Compilation failure:
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[22,36]
> org.apache.solr.search.facet.FacetContext is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[23,36]
> org.apache.solr.search.facet.FacetDoubleMerger is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[40,32]
> cannot find symbol
> [ERROR] symbol: class FacetContext
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[49,39]
> cannot find symbol
> [ERROR] symbol: class FacetDoubleMerger
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[54,43]
> cannot find symbol
> [ERROR] symbol: class Context
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg.Merger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[41,16]
> cannot find symbol
> [ERROR] symbol: class AvgSlotAcc
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[46,12]
> incompatible types: i.o.s.search.facet.CustomAvgAgg.Merger cannot be
> converted to org.apache.solr.search.facet.FacetMerger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[53,5]
> method does not override or implement a method from a supertype
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[60,5]
> method does not override or implement a method from a supertype
> {code}
> It seems lots of classes are tucked away in FacetModule, which we can't reach
> from outside.
> Originates from this thread:
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201602.mbox/%3ccab_8yd9ldbg_0zxm_h1igkfm6bqeypd5ilyy7tty8cztscv...@mail.gmail.com%3E
> ( also available at
> https://lists.apache.org/thread.html/9fddcad3136ec908ce1c57881f8d3069e5d153f08b71f80f3e18d995%401455019826%40%3Csolr-user.lucene.apache.org%3E
> )
--
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-8673) o.a.s.search.facet classes not public/extendable
[
https://issues.apache.org/jira/browse/SOLR-8673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245647#comment-17245647
]
Mikhail Khludnev edited comment on SOLR-8673 at 12/8/20, 7:31 AM:
--
Sorry to hear that, [~thelabdude]. I'm on it.
was (Author: mkhludnev):
Sorry to hear that, @thelabdude. I'm on it.
> o.a.s.search.facet classes not public/extendable
>
>
> Key: SOLR-8673
> URL: https://issues.apache.org/jira/browse/SOLR-8673
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Affects Versions: 5.4.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 6.2, 7.0
>
> Attachments: SOLR-8673.patch, SOLR-8673.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> It is not easy to create a custom JSON facet function. A simple function
> based on AvgAgg quickly results in the following compilation failures:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile)
> on project openindex-solr: Compilation failure: Compilation failure:
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[22,36]
> org.apache.solr.search.facet.FacetContext is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[23,36]
> org.apache.solr.search.facet.FacetDoubleMerger is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[40,32]
> cannot find symbol
> [ERROR] symbol: class FacetContext
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[49,39]
> cannot find symbol
> [ERROR] symbol: class FacetDoubleMerger
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[54,43]
> cannot find symbol
> [ERROR] symbol: class Context
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg.Merger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[41,16]
> cannot find symbol
> [ERROR] symbol: class AvgSlotAcc
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[46,12]
> incompatible types: i.o.s.search.facet.CustomAvgAgg.Merger cannot be
> converted to org.apache.solr.search.facet.FacetMerger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[53,5]
> method does not override or implement a method from a supertype
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[60,5]
> method does not override or implement a method from a supertype
> {code}
> It seems lots of classes are tucked away in FacetModule, which we can't reach
> from outside.
> Originates from this thread:
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201602.mbox/%3ccab_8yd9ldbg_0zxm_h1igkfm6bqeypd5ilyy7tty8cztscv...@mail.gmail.com%3E
> ( also available at
> https://lists.apache.org/thread.html/9fddcad3136ec908ce1c57881f8d3069e5d153f08b71f80f3e18d995%401455019826%40%3Csolr-user.lucene.apache.org%3E
> )
--
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-8673) o.a.s.search.facet classes not public/extendable
[
https://issues.apache.org/jira/browse/SOLR-8673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245647#comment-17245647
]
Mikhail Khludnev edited comment on SOLR-8673 at 12/8/20, 7:30 AM:
--
Sorry to hear that, @thelabdude. I'm on it.
was (Author: mkhludnev):
Sorry to hear that, @thekabdude. I'm on it.
> o.a.s.search.facet classes not public/extendable
>
>
> Key: SOLR-8673
> URL: https://issues.apache.org/jira/browse/SOLR-8673
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Affects Versions: 5.4.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 6.2, 7.0
>
> Attachments: SOLR-8673.patch, SOLR-8673.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> It is not easy to create a custom JSON facet function. A simple function
> based on AvgAgg quickly results in the following compilation failures:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile)
> on project openindex-solr: Compilation failure: Compilation failure:
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[22,36]
> org.apache.solr.search.facet.FacetContext is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[23,36]
> org.apache.solr.search.facet.FacetDoubleMerger is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[40,32]
> cannot find symbol
> [ERROR] symbol: class FacetContext
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[49,39]
> cannot find symbol
> [ERROR] symbol: class FacetDoubleMerger
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[54,43]
> cannot find symbol
> [ERROR] symbol: class Context
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg.Merger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[41,16]
> cannot find symbol
> [ERROR] symbol: class AvgSlotAcc
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[46,12]
> incompatible types: i.o.s.search.facet.CustomAvgAgg.Merger cannot be
> converted to org.apache.solr.search.facet.FacetMerger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[53,5]
> method does not override or implement a method from a supertype
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[60,5]
> method does not override or implement a method from a supertype
> {code}
> It seems lots of classes are tucked away in FacetModule, which we can't reach
> from outside.
> Originates from this thread:
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201602.mbox/%3ccab_8yd9ldbg_0zxm_h1igkfm6bqeypd5ilyy7tty8cztscv...@mail.gmail.com%3E
> ( also available at
> https://lists.apache.org/thread.html/9fddcad3136ec908ce1c57881f8d3069e5d153f08b71f80f3e18d995%401455019826%40%3Csolr-user.lucene.apache.org%3E
> )
--
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-8673) o.a.s.search.facet classes not public/extendable
[
https://issues.apache.org/jira/browse/SOLR-8673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245647#comment-17245647
]
Mikhail Khludnev commented on SOLR-8673:
Sorry to hear that, @thekabdude. I'm on it.
> o.a.s.search.facet classes not public/extendable
>
>
> Key: SOLR-8673
> URL: https://issues.apache.org/jira/browse/SOLR-8673
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Affects Versions: 5.4.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 6.2, 7.0
>
> Attachments: SOLR-8673.patch, SOLR-8673.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> It is not easy to create a custom JSON facet function. A simple function
> based on AvgAgg quickly results in the following compilation failures:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile)
> on project openindex-solr: Compilation failure: Compilation failure:
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[22,36]
> org.apache.solr.search.facet.FacetContext is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[23,36]
> org.apache.solr.search.facet.FacetDoubleMerger is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[40,32]
> cannot find symbol
> [ERROR] symbol: class FacetContext
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[49,39]
> cannot find symbol
> [ERROR] symbol: class FacetDoubleMerger
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[54,43]
> cannot find symbol
> [ERROR] symbol: class Context
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg.Merger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[41,16]
> cannot find symbol
> [ERROR] symbol: class AvgSlotAcc
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[46,12]
> incompatible types: i.o.s.search.facet.CustomAvgAgg.Merger cannot be
> converted to org.apache.solr.search.facet.FacetMerger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[53,5]
> method does not override or implement a method from a supertype
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[60,5]
> method does not override or implement a method from a supertype
> {code}
> It seems lots of classes are tucked away in FacetModule, which we can't reach
> from outside.
> Originates from this thread:
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201602.mbox/%3ccab_8yd9ldbg_0zxm_h1igkfm6bqeypd5ilyy7tty8cztscv...@mail.gmail.com%3E
> ( also available at
> https://lists.apache.org/thread.html/9fddcad3136ec908ce1c57881f8d3069e5d153f08b71f80f3e18d995%401455019826%40%3Csolr-user.lucene.apache.org%3E
> )
--
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-8673) o.a.s.search.facet classes not public/extendable
[
https://issues.apache.org/jira/browse/SOLR-8673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240343#comment-17240343
]
Mikhail Khludnev commented on SOLR-8673:
[~TimOwen], I'm steadily getting back to development. I noticed that patch
verification works only for github PR. Would you mind to move patch to github,
and link here. Thanks. Appreciate.
> o.a.s.search.facet classes not public/extendable
>
>
> Key: SOLR-8673
> URL: https://issues.apache.org/jira/browse/SOLR-8673
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Affects Versions: 5.4.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 6.2, 7.0
>
> Attachments: SOLR-8673.patch, SOLR-8673.patch
>
>
> It is not easy to create a custom JSON facet function. A simple function
> based on AvgAgg quickly results in the following compilation failures:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile)
> on project openindex-solr: Compilation failure: Compilation failure:
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[22,36]
> org.apache.solr.search.facet.FacetContext is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[23,36]
> org.apache.solr.search.facet.FacetDoubleMerger is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[40,32]
> cannot find symbol
> [ERROR] symbol: class FacetContext
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[49,39]
> cannot find symbol
> [ERROR] symbol: class FacetDoubleMerger
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[54,43]
> cannot find symbol
> [ERROR] symbol: class Context
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg.Merger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[41,16]
> cannot find symbol
> [ERROR] symbol: class AvgSlotAcc
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[46,12]
> incompatible types: i.o.s.search.facet.CustomAvgAgg.Merger cannot be
> converted to org.apache.solr.search.facet.FacetMerger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[53,5]
> method does not override or implement a method from a supertype
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[60,5]
> method does not override or implement a method from a supertype
> {code}
> It seems lots of classes are tucked away in FacetModule, which we can't reach
> from outside.
> Originates from this thread:
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201602.mbox/%3ccab_8yd9ldbg_0zxm_h1igkfm6bqeypd5ilyy7tty8cztscv...@mail.gmail.com%3E
> ( also available at
> https://lists.apache.org/thread.html/9fddcad3136ec908ce1c57881f8d3069e5d153f08b71f80f3e18d995%401455019826%40%3Csolr-user.lucene.apache.org%3E
> )
--
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=17240342#comment-17240342 ] Mikhail Khludnev commented on LUCENE-9021: -- Ready to commit. I see PR have passed precommit check, but it the patch has conflict. I kindly appreciate if it's resolved. > 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] (SOLR-8673) o.a.s.search.facet classes not public/extendable
[
https://issues.apache.org/jira/browse/SOLR-8673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-8673:
---
Status: Patch Available (was: Open)
> o.a.s.search.facet classes not public/extendable
>
>
> Key: SOLR-8673
> URL: https://issues.apache.org/jira/browse/SOLR-8673
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Affects Versions: 5.4.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 6.2, 7.0
>
> Attachments: SOLR-8673.patch, SOLR-8673.patch
>
>
> It is not easy to create a custom JSON facet function. A simple function
> based on AvgAgg quickly results in the following compilation failures:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile)
> on project openindex-solr: Compilation failure: Compilation failure:
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[22,36]
> org.apache.solr.search.facet.FacetContext is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[23,36]
> org.apache.solr.search.facet.FacetDoubleMerger is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[40,32]
> cannot find symbol
> [ERROR] symbol: class FacetContext
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[49,39]
> cannot find symbol
> [ERROR] symbol: class FacetDoubleMerger
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[54,43]
> cannot find symbol
> [ERROR] symbol: class Context
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg.Merger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[41,16]
> cannot find symbol
> [ERROR] symbol: class AvgSlotAcc
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[46,12]
> incompatible types: i.o.s.search.facet.CustomAvgAgg.Merger cannot be
> converted to org.apache.solr.search.facet.FacetMerger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[53,5]
> method does not override or implement a method from a supertype
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[60,5]
> method does not override or implement a method from a supertype
> {code}
> It seems lots of classes are tucked away in FacetModule, which we can't reach
> from outside.
> Originates from this thread:
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201602.mbox/%3ccab_8yd9ldbg_0zxm_h1igkfm6bqeypd5ilyy7tty8cztscv...@mail.gmail.com%3E
> ( also available at
> https://lists.apache.org/thread.html/9fddcad3136ec908ce1c57881f8d3069e5d153f08b71f80f3e18d995%401455019826%40%3Csolr-user.lucene.apache.org%3E
> )
--
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-8673) o.a.s.search.facet classes not public/extendable
[
https://issues.apache.org/jira/browse/SOLR-8673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226927#comment-17226927
]
Mikhail Khludnev commented on SOLR-8673:
I think it's good. However, it's worth to add a dummy descendant class in
tests, just to ensure that extension from other package is possible.
> o.a.s.search.facet classes not public/extendable
>
>
> Key: SOLR-8673
> URL: https://issues.apache.org/jira/browse/SOLR-8673
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Affects Versions: 5.4.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 6.2, 7.0
>
> Attachments: SOLR-8673.patch
>
>
> It is not easy to create a custom JSON facet function. A simple function
> based on AvgAgg quickly results in the following compilation failures:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile)
> on project openindex-solr: Compilation failure: Compilation failure:
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[22,36]
> org.apache.solr.search.facet.FacetContext is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[23,36]
> org.apache.solr.search.facet.FacetDoubleMerger is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[40,32]
> cannot find symbol
> [ERROR] symbol: class FacetContext
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[49,39]
> cannot find symbol
> [ERROR] symbol: class FacetDoubleMerger
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[54,43]
> cannot find symbol
> [ERROR] symbol: class Context
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg.Merger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[41,16]
> cannot find symbol
> [ERROR] symbol: class AvgSlotAcc
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[46,12]
> incompatible types: i.o.s.search.facet.CustomAvgAgg.Merger cannot be
> converted to org.apache.solr.search.facet.FacetMerger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[53,5]
> method does not override or implement a method from a supertype
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[60,5]
> method does not override or implement a method from a supertype
> {code}
> It seems lots of classes are tucked away in FacetModule, which we can't reach
> from outside.
> Originates from this thread:
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201602.mbox/%3ccab_8yd9ldbg_0zxm_h1igkfm6bqeypd5ilyy7tty8cztscv...@mail.gmail.com%3E
> ( also available at
> https://lists.apache.org/thread.html/9fddcad3136ec908ce1c57881f8d3069e5d153f08b71f80f3e18d995%401455019826%40%3Csolr-user.lucene.apache.org%3E
> )
--
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-14821) docValuesTermsFilter should support single-valued docValues fields
[ https://issues.apache.org/jira/browse/SOLR-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-14821: Description: SOLR-13890 introduced a post-filter implementation for docValuesTermsFilter in TermsQParserPlugin. But now it supports only multi-valued docValues fields (i.e. SORTED_SET type DocValues) It doesn't work for single-valued docValues fields (i.e. SORTED type DocValues), though it should. was: https://issues.apache.org/jira/browse/SOLR-13890 introduced a post-filter implementation for docValuesTermsFilter in TermsQParserPlugin. But now it supports only multi-valued docValues fields (i.e. SORTED_SET type DocValues) It doesn't work for single-valued docValues fields (i.e. SORTED type DocValues), though it should. > docValuesTermsFilter should support single-valued docValues fields > -- > > Key: SOLR-14821 > URL: https://issues.apache.org/jira/browse/SOLR-14821 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Reporter: Anatolii Siuniaev >Priority: Minor > > SOLR-13890 introduced a post-filter implementation for docValuesTermsFilter > in TermsQParserPlugin. But now it supports only multi-valued docValues > fields (i.e. SORTED_SET type DocValues) > It doesn't work for single-valued docValues fields (i.e. SORTED type > DocValues), though it should. -- 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-9328) Sorting by DocValues while grouping is slower than old good FieldCache
[ https://issues.apache.org/jira/browse/LUCENE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9328: - Issue Type: Bug (was: Improvement) > Sorting by DocValues while grouping is slower than old good FieldCache > -- > > Key: LUCENE-9328 > URL: https://issues.apache.org/jira/browse/LUCENE-9328 > Project: Lucene - Core > Issue Type: Bug > Components: modules/grouping >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Minor > Attachments: LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, > LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, > LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, > LUCENE-9328.patch > > Time Spent: 2h 20m > Remaining Estimate: 0h > > That's why > https://issues.apache.org/jira/browse/LUCENE-7701?focusedCommentId=17084365=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17084365 -- 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-14540) Ref Guide: Document how-to for Block Join Facets via Query DSL
[ https://issues.apache.org/jira/browse/SOLR-14540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17187273#comment-17187273 ] Mikhail Khludnev commented on SOLR-14540: - https://github.com/apache/lucene-solr/pull/1805 edits are appreciated > Ref Guide: Document how-to for Block Join Facets via Query DSL > -- > > Key: SOLR-14540 > URL: https://issues.apache.org/jira/browse/SOLR-14540 > Project: Solr > Issue Type: Improvement >Reporter: Mikhail Khludnev >Priority: Major > Fix For: 8.7 > > Time Spent: 10m > Remaining Estimate: 0h > > Solr has an old good feature > https://lucene.apache.org/solr/guide/8_5/faceting.html#tagging-and-excluding-filters. > I'd like to document similar solution/snippet for > https://lucene.apache.org/solr/guide/8_5/json-faceting-domain-changes.html#block-join-domain-changes > in Query DSL. This solution combines several elements, so it's not clear > where to put it. Does it deserve separate page or just a paragraph somewhere? > Snippet is already > [there|https://issues.apache.org/jira/browse/SOLR-14419?focusedCommentId=17112869=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17112869] > it just needs some tweaks. -- 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-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17172345#comment-17172345
]
Mikhail Khludnev commented on SOLR-14557:
-
Trap syntax prevails at
[https://lucene.apache.org/solr/guide/8_6/local-parameters-in-queries.html],
however the safer one is mentioned there as well. I think it make sense to ban
{{\\{!prefix}}}syntax from 9.0.
> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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] [Closed] (SOLR-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev closed SOLR-14557.
---
> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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] [Issue Comment Deleted] (SOLR-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14557:
Comment: was deleted
(was: Right. {{\{!v="syntax"}}} works as well since it has explicit terminator.
)
> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17171720#comment-17171720
]
Mikhail Khludnev commented on SOLR-14557:
-
Right. {{\{!v="syntax"}}} works as well since it has explicit terminator.
> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17171721#comment-17171721
]
Mikhail Khludnev commented on SOLR-14557:
-
Right. {{\{!v="syntax"}}} works as well since it has explicit terminator.
> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170183#comment-17170183
]
Mikhail Khludnev edited comment on SOLR-14557 at 8/3/20, 4:45 PM:
--
Prefix form of local params is quite vulnerable to syntax variations. For
example {{filter(..)}} is in a way better position: it encloses full syntax
recursively, and have explicit terminator symbol. Nether of these is true for
\{{\{!prefix local=param}synta)(}}
I see it as a coolhack made years ago and brought much pain for us later. It
would be better if -json- explicit structured syntax for queries was introduced
right there.
was (Author: mkhludnev):
Prefix form of local params is quite vulnerable to syntax variations. For
example {{filter(..)}} is in a way better position: it encloses full syntax
recursively, and have explicit terminator symbol. Nether of these is true for
{{{!prefix local=param}synta)(}}
I see it as a coolhack made years ago and brought much pain for us later. It
would be better if -json- explicit structured syntax for queries was introduced
right there.
> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170183#comment-17170183
]
Mikhail Khludnev commented on SOLR-14557:
-
Prefix form of local params is quite vulnerable to syntax variations. For
example {{filter(..)}} is in a way better position: it encloses full syntax
recursively, and have explicit terminator symbol. Nether of these is true for
{{{!prefix local=param}synta)(}}
I see it as a coolhack made years ago and brought much pain for us later. It
would be better if -json- explicit structured syntax for queries was introduced
right there.
> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14557:
Resolution: Won't Fix
Status: Resolved (was: Patch Available)
> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17169645#comment-17169645
]
Mikhail Khludnev commented on SOLR-14557:
-
Ok. There are two places where local params are parsed:
# QParser.parseLocalParams() when string starts with curly brace {
# JavaCC QueryParser.jj SOLR-4093
SOLR-11501 banned edismax from the former option. But the former option is
unable to handle {{\{!parser}(foo)}} that might seem like a bug, but after
thinking a little I've though it's reasonable. Think about {{(\{!term}foo)}},
it should be parsed to {{foo}} undoubtedly, but {{\{!term}(foo)}} behavior
quite depended on subordinate parser, TermQParser should receive parenthesis,
but LuceneQParser probably shouldn't.
So, I resolved it just by advising customer for tweaking syntax:
Before 7.2 {{\{!join ...}(... )}} -> after 7.2 {{\_query_:"\{!join ...
defType=edixmax}."}}
Sorry for the noise.
> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev reassigned SOLR-14557:
---
Assignee: Mikhail Khludnev
> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158692#comment-17158692
]
Mikhail Khludnev edited comment on SOLR-14557 at 7/15/20, 8:25 PM:
---
it seems to me that quite essential case like {{defType=lucene=
\{!lucene}(space matters)}} is broken. WDYT?
was (Author: mkhludnev):
it seems to me that quite essential case like {{defType=lucene=
{!lucene}(space matters)}} is broken. WDYT?
> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158692#comment-17158692
]
Mikhail Khludnev commented on SOLR-14557:
-
it seems to me that quite essential case like {{defType=lucene=
{!lucene}(space matters)}} is broken. WDYT?
> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14557:
Summary: Unable to parse local params followed by parenthesis like
{!lucene}(gigabyte) (was: eDisMax parser unable to parse {!lucene}(gigabyte))
> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-11501) Depending on the parser, QParser should not parse local-params
[
https://issues.apache.org/jira/browse/SOLR-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158689#comment-17158689
]
Mikhail Khludnev commented on SOLR-11501:
-
ok. Regarding [^SOLR-11501-breaker.patch], {{defType=edismax=*
_query_={!lucene df=text_sw}(gigabyte)}} worked before, because edismax
didn't attempted to parse local params here, parser was switched early, and
{{QParser.prarseLocalParams()}} just stripped the prefix.
Now, edismax tries to parse it and fails. Followup SOLR-14557.
> Depending on the parser, QParser should not parse local-params
> --
>
> Key: SOLR-11501
> URL: https://issues.apache.org/jira/browse/SOLR-11501
> Project: Solr
> Issue Type: Improvement
> Components: query parsers
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR-11501-breaker.patch,
> SOLR_11501_limit_local_params_parsing.patch,
> SOLR_11501_limit_local_params_parsing.patch
>
>
> Solr should not parse local-params (and thus be able to switch the query
> parser) in certain circumstances. _Perhaps_ it is when the QParser.getParser
> is passed "lucene" for the {{defaultParser}}? This particular approach is
> just a straw-man; I suspect certain valid embedded queries could no longer
> work if this is done incorrectly. Whatever the solution, I don't think we
> should assume 'q' is special, as it's valid and useful to build up queries
> containing user input in other ways, e.g. {{q= +field:value +\{!dismax
> v=$qq\}=user input}} and we want to protect the user input there
> similarly from unwelcome query parsing switching.
--
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-14540) Ref Guide: Document how-to for Block Join Facets via Query DSL
[ https://issues.apache.org/jira/browse/SOLR-14540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152295#comment-17152295 ] Mikhail Khludnev commented on SOLR-14540: - Thanks, [~ctargett] > Ref Guide: Document how-to for Block Join Facets via Query DSL > -- > > Key: SOLR-14540 > URL: https://issues.apache.org/jira/browse/SOLR-14540 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Priority: Major > Fix For: 8.7 > > > Solr has an old good feature > https://lucene.apache.org/solr/guide/8_5/faceting.html#tagging-and-excluding-filters. > I'd like to document similar solution/snippet for > https://lucene.apache.org/solr/guide/8_5/json-faceting-domain-changes.html#block-join-domain-changes > in Query DSL. This solution combines several elements, so it's not clear > where to put it. Does it deserve separate page or just a paragraph somewhere? > Snippet is already > [there|https://issues.apache.org/jira/browse/SOLR-14419?focusedCommentId=17112869=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17112869] > it just needs some tweaks. -- 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-14540) Ref Guide: Document how-to for Block Join Facets via Query DSL
[ https://issues.apache.org/jira/browse/SOLR-14540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-14540: Fix Version/s: 8.7 > Ref Guide: Document how-to for Block Join Facets via Query DSL > -- > > Key: SOLR-14540 > URL: https://issues.apache.org/jira/browse/SOLR-14540 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Priority: Major > Fix For: 8.7 > > > Solr has an old good feature > https://lucene.apache.org/solr/guide/8_5/faceting.html#tagging-and-excluding-filters. > I'd like to document similar solution/snippet for > https://lucene.apache.org/solr/guide/8_5/json-faceting-domain-changes.html#block-join-domain-changes > in Query DSL. This solution combines several elements, so it's not clear > where to put it. Does it deserve separate page or just a paragraph somewhere? > Snippet is already > [there|https://issues.apache.org/jira/browse/SOLR-14419?focusedCommentId=17112869=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17112869] > it just needs some tweaks. -- 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-11501) Depending on the parser, QParser should not parse local-params
[
https://issues.apache.org/jira/browse/SOLR-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152100#comment-17152100
]
Mikhail Khludnev edited comment on SOLR-11501 at 7/6/20, 3:34 PM:
--
[^SOLR-11501-breaker.patch]Attached two tests, both are green before this
commit. The one with enclosed parenthesis {{uf=\* \_query_=\{!lucene
df=text_sw}(gigabyte)}} fails after this commit. (Note: this commit and
reproducer was found by [~anatolii_siuniaev]). Interesting there's a
straightforward fix attached to SOLR-14557, however it fixes lucene parser jj
grammar.
was (Author: mkhludnev):
Attached two tests, both are green before this commit. The one with enclosed
parenthesis {{uf=\* \_query_=\{!lucene df=text_sw}(gigabyte)}} fails after
this commit. (Note: this commit and reproducer was found by
[~anatolii_siuniaev]). Interesting there's a straightforward fix attached to
SOLR-14557, however it fixes lucene parser jj grammar.
> Depending on the parser, QParser should not parse local-params
> --
>
> Key: SOLR-11501
> URL: https://issues.apache.org/jira/browse/SOLR-11501
> Project: Solr
> Issue Type: Improvement
> Components: query parsers
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR-11501-breaker.patch,
> SOLR_11501_limit_local_params_parsing.patch,
> SOLR_11501_limit_local_params_parsing.patch
>
>
> Solr should not parse local-params (and thus be able to switch the query
> parser) in certain circumstances. _Perhaps_ it is when the QParser.getParser
> is passed "lucene" for the {{defaultParser}}? This particular approach is
> just a straw-man; I suspect certain valid embedded queries could no longer
> work if this is done incorrectly. Whatever the solution, I don't think we
> should assume 'q' is special, as it's valid and useful to build up queries
> containing user input in other ways, e.g. {{q= +field:value +\{!dismax
> v=$qq\}=user input}} and we want to protect the user input there
> similarly from unwelcome query parsing switching.
--
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-11501) Depending on the parser, QParser should not parse local-params
[
https://issues.apache.org/jira/browse/SOLR-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152100#comment-17152100
]
Mikhail Khludnev edited comment on SOLR-11501 at 7/6/20, 3:33 PM:
--
Attached two tests, both are green before this commit. The one with enclosed
parenthesis {{uf=\* \_query_=\{!lucene df=text_sw}(gigabyte)}} fails after
this commit. (Note: this commit and reproducer was found by
[~anatolii_siuniaev]). Interesting there's a straightforward fix attached to
SOLR-14557, however it fixes lucene parser jj grammar.
was (Author: mkhludnev):
Attached two tests, both are green before this commit. The one with enclosed
parenthesis {{uf=* _query_=\{!lucene df=text_sw}(gigabyte)}} fails after this
commit. (Note: this commit and reproducer was found by [~anatolii_siuniaev]).
Interesting there's a straightforward fix attached to SOLR-14557, however it
fixes lucene parser jj grammar.
> Depending on the parser, QParser should not parse local-params
> --
>
> Key: SOLR-11501
> URL: https://issues.apache.org/jira/browse/SOLR-11501
> Project: Solr
> Issue Type: Improvement
> Components: query parsers
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR-11501-breaker.patch,
> SOLR_11501_limit_local_params_parsing.patch,
> SOLR_11501_limit_local_params_parsing.patch
>
>
> Solr should not parse local-params (and thus be able to switch the query
> parser) in certain circumstances. _Perhaps_ it is when the QParser.getParser
> is passed "lucene" for the {{defaultParser}}? This particular approach is
> just a straw-man; I suspect certain valid embedded queries could no longer
> work if this is done incorrectly. Whatever the solution, I don't think we
> should assume 'q' is special, as it's valid and useful to build up queries
> containing user input in other ways, e.g. {{q= +field:value +\{!dismax
> v=$qq\}=user input}} and we want to protect the user input there
> similarly from unwelcome query parsing switching.
--
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-11501) Depending on the parser, QParser should not parse local-params
[
https://issues.apache.org/jira/browse/SOLR-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152100#comment-17152100
]
Mikhail Khludnev edited comment on SOLR-11501 at 7/6/20, 3:32 PM:
--
Attached two tests, both are green before this commit. The one with enclosed
parenthesis {{uf=* _query_=\{!lucene df=text_sw}(gigabyte)}} fails after this
commit. (Note: this commit and reproducer was found by [~anatolii_siuniaev]).
Interesting there's a straightforward fix attached to SOLR-14557, however it
fixes lucene parser jj grammar.
was (Author: mkhludnev):
Attached two tests, both are green before this commit. The one with enclosed
parenthesis {{uf=* _query_={!lucene df=text_sw}(gigabyte)}} fails after this
commit. (Note: this commit and reproducer was found by [~anatolii_siuniaev]).
Interesting there's a straightforward fix attached to SOLR-14557, however it
fixes lucene parser jj grammar.
> Depending on the parser, QParser should not parse local-params
> --
>
> Key: SOLR-11501
> URL: https://issues.apache.org/jira/browse/SOLR-11501
> Project: Solr
> Issue Type: Improvement
> Components: query parsers
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR-11501-breaker.patch,
> SOLR_11501_limit_local_params_parsing.patch,
> SOLR_11501_limit_local_params_parsing.patch
>
>
> Solr should not parse local-params (and thus be able to switch the query
> parser) in certain circumstances. _Perhaps_ it is when the QParser.getParser
> is passed "lucene" for the {{defaultParser}}? This particular approach is
> just a straw-man; I suspect certain valid embedded queries could no longer
> work if this is done incorrectly. Whatever the solution, I don't think we
> should assume 'q' is special, as it's valid and useful to build up queries
> containing user input in other ways, e.g. {{q= +field:value +\{!dismax
> v=$qq\}=user input}} and we want to protect the user input there
> similarly from unwelcome query parsing switching.
--
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-11501) Depending on the parser, QParser should not parse local-params
[
https://issues.apache.org/jira/browse/SOLR-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152100#comment-17152100
]
Mikhail Khludnev commented on SOLR-11501:
-
Attached two tests, both are green before this commit. The one with enclosed
parenthesis {{uf=* _query_={!lucene df=text_sw}(gigabyte)}} fails after this
commit. (Note: this commit and reproducer was found by [~anatolii_siuniaev]).
Interesting there's a straightforward fix attached to SOLR-14557, however it
fixes lucene parser jj grammar.
> Depending on the parser, QParser should not parse local-params
> --
>
> Key: SOLR-11501
> URL: https://issues.apache.org/jira/browse/SOLR-11501
> Project: Solr
> Issue Type: Improvement
> Components: query parsers
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR-11501-breaker.patch,
> SOLR_11501_limit_local_params_parsing.patch,
> SOLR_11501_limit_local_params_parsing.patch
>
>
> Solr should not parse local-params (and thus be able to switch the query
> parser) in certain circumstances. _Perhaps_ it is when the QParser.getParser
> is passed "lucene" for the {{defaultParser}}? This particular approach is
> just a straw-man; I suspect certain valid embedded queries could no longer
> work if this is done incorrectly. Whatever the solution, I don't think we
> should assume 'q' is special, as it's valid and useful to build up queries
> containing user input in other ways, e.g. {{q= +field:value +\{!dismax
> v=$qq\}=user input}} and we want to protect the user input there
> similarly from unwelcome query parsing switching.
--
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-11501) Depending on the parser, QParser should not parse local-params
[
https://issues.apache.org/jira/browse/SOLR-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-11501:
Attachment: SOLR-11501-breaker.patch
> Depending on the parser, QParser should not parse local-params
> --
>
> Key: SOLR-11501
> URL: https://issues.apache.org/jira/browse/SOLR-11501
> Project: Solr
> Issue Type: Improvement
> Components: query parsers
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR-11501-breaker.patch,
> SOLR_11501_limit_local_params_parsing.patch,
> SOLR_11501_limit_local_params_parsing.patch
>
>
> Solr should not parse local-params (and thus be able to switch the query
> parser) in certain circumstances. _Perhaps_ it is when the QParser.getParser
> is passed "lucene" for the {{defaultParser}}? This particular approach is
> just a straw-man; I suspect certain valid embedded queries could no longer
> work if this is done incorrectly. Whatever the solution, I don't think we
> should assume 'q' is special, as it's valid and useful to build up queries
> containing user input in other ways, e.g. {{q= +field:value +\{!dismax
> v=$qq\}=user input}} and we want to protect the user input there
> similarly from unwelcome query parsing switching.
--
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-14557) eDisMax parser unable to parse {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149687#comment-17149687
]
Mikhail Khludnev edited comment on SOLR-14557 at 7/1/20, 8:30 PM:
--
Attached pretty straightforward fix for the grammar
{noformat}
| )* (~["=","}"])+ ( "=" ( |
("'" (<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}")+ (~[")","
","\t","\n","{","^"])* >
+| )* (~["=","}"])+ ( "=" (
| ("'" (<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}" "(") (~[")","
","\t","\n","{","^"])* ")" >
|
}
@@ -253,6 +254,7 @@ Query Clause(String field) throws SyntaxError : {
| (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
+ | (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
{noformat}
Opinions?
was (Author: mkhludnev):
Attached pretty straightforward fix for the grammar
{noformat}
| )* (~["=","}"])+ ( "=" ( | ("'"
(<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}")+ (~[")","
","\t","\n","{","^"])* >
+| )* (~["=","}"])+ ( "=" (
| ("'" (<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}" "(") (~[")","
","\t","\n","{","^"])* ")" >
|
}
@@ -253,6 +254,7 @@ Query Clause(String field) throws SyntaxError : {
| q=Query(field) [ boost= ]
| ( { flags=startFilter(); } q=Query(field) [
boost= ] { q=getFilter(q); restoreFlags(flags); } )
| (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
+ | (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
{noformat}
Opinions?
> eDisMax parser unable to parse {!lucene}(gigabyte)
> --
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) eDisMax parser unable to parse {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149687#comment-17149687
]
Mikhail Khludnev edited comment on SOLR-14557 at 7/1/20, 8:29 PM:
--
Attached pretty straightforward fix for the grammar
{noformat}
| )* (~["=","}"])+ ( "=" ( | ("'"
(<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}")+ (~[")","
","\t","\n","{","^"])* >
+| )* (~["=","}"])+ ( "=" (
| ("'" (<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}" "(") (~[")","
","\t","\n","{","^"])* ")" >
|
}
@@ -253,6 +254,7 @@ Query Clause(String field) throws SyntaxError : {
| q=Query(field) [ boost= ]
| ( { flags=startFilter(); } q=Query(field) [
boost= ] { q=getFilter(q); restoreFlags(flags); } )
| (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
+ | (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
{noformat}
Opinions?
was (Author: mkhludnev):
Attached pretty straightforward fix for the grammar
{quote}
| )* (~["=","}"])+ ( "=" ( | ("'"
(<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}")+ (~[")","
","\t","\n","{","^"])* >
+| )* (~["=","}"])+ ( "=" (
| ("'" (<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}" "(") (~[")","
","\t","\n","{","^"])* ")" >
|
}
@@ -253,6 +254,7 @@ Query Clause(String field) throws SyntaxError : {
| q=Query(field) [ boost= ]
| ( { flags=startFilter(); } q=Query(field) [
boost= ] { q=getFilter(q); restoreFlags(flags); } )
| (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
+ | (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
{quote}
Opinions?
> eDisMax parser unable to parse {!lucene}(gigabyte)
> --
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) eDisMax parser unable to parse {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149687#comment-17149687
]
Mikhail Khludnev edited comment on SOLR-14557 at 7/1/20, 8:28 PM:
--
Attached pretty straightforward fix for the grammar
{quote}
| )* (~["=","}"])+ ( "=" ( | ("'"
(<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}")+ (~[")","
","\t","\n","{","^"])* >
+| )* (~["=","}"])+ ( "=" (
| ("'" (<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}" "(") (~[")","
","\t","\n","{","^"])* ")" >
|
}
@@ -253,6 +254,7 @@ Query Clause(String field) throws SyntaxError : {
| q=Query(field) [ boost= ]
| ( { flags=startFilter(); } q=Query(field) [
boost= ] { q=getFilter(q); restoreFlags(flags); } )
| (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
+ | (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
{quote}
Opinions?
was (Author: mkhludnev):
Attached pretty straightforward fix for the grammar
{code}
| )* (~["=","}"])+ ( "=" ( | ("'"
(<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}")+ (~[")","
","\t","\n","{","^"])* >
+| )* (~["=","}"])+ ( "=" (
| ("'" (<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}" "(") (~[")","
","\t","\n","{","^"])* ")" >
|
}
@@ -253,6 +254,7 @@ Query Clause(String field) throws SyntaxError : {
| q=Query(field) [ boost= ]
| ( { flags=startFilter(); } q=Query(field) [
boost= ] { q=getFilter(q); restoreFlags(flags); } )
| (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
+ | (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
{code}
Opinions?
> eDisMax parser unable to parse {!lucene}(gigabyte)
> --
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) eDisMax parser unable to parse {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149687#comment-17149687
]
Mikhail Khludnev commented on SOLR-14557:
-
Attached pretty straightforward fix for the grammar
{code}
| )* (~["=","}"])+ ( "=" ( | ("'"
(<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}")+ (~[")","
","\t","\n","{","^"])* >
+| )* (~["=","}"])+ ( "=" (
| ("'" (<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}" "(") (~[")","
","\t","\n","{","^"])* ")" >
|
}
@@ -253,6 +254,7 @@ Query Clause(String field) throws SyntaxError : {
| q=Query(field) [ boost= ]
| ( { flags=startFilter(); } q=Query(field) [
boost= ] { q=getFilter(q); restoreFlags(flags); } )
| (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
+ | (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
{code}
Opinions?
> eDisMax parser unable to parse {!lucene}(gigabyte)
> --
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) eDisMax parser unable to parse {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14557:
Attachment: SOLR-14557.patch
Status: Patch Available (was: Patch Available)
> eDisMax parser unable to parse {!lucene}(gigabyte)
> --
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14539:
Assignee: Mikhail Khludnev
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Fix For: 8.6
>
> Attachments: SOLR-14539.patch, SOLR-14539.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
> many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
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-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148847#comment-17148847
]
Mikhail Khludnev edited comment on SOLR-14539 at 6/30/20, 10:00 PM:
master
https://gitbox.apache.org/repos/asf?p=lucene-solr.git;a=commitdiff;h=f647400e31c0fb238744cece8d3943bc15253ec7
8x
https://gitbox.apache.org/repos/asf?p=lucene-solr.git;a=commitdiff;h=d81e01cfccd90e76e00131ad2750bcca8edbdbf8
was (Author: mkhludnev):
master
https://gitbox.apache.org/repos/asf?p=lucene-solr.git;a=commitdiff;h=f647400e31c0fb238744cece8d3943bc15253ec7
8x
https://gitbox.apache.org/repos/asf?p=lucene-solr.git;a=commitdiff;h=d81e01cfccd90e76e00131ad2750bcca8edbdbf8
Although, I'm not sure if it got into 8.6.
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Fix For: 8.6
>
> Attachments: SOLR-14539.patch, SOLR-14539.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
> many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
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-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14539:
Comment: was deleted
(was: | (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 8s{color}
| {color:red} SOLR-14539 does not apply to master. Rebase required? Wrong
Branch? See
https://wiki.apache.org/solr/HowToContribute#Creating_the_patch_file for help.
{color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-14539 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/13006747/SOLR-14539.patch |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/771/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
)
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Fix For: 8.6
>
> Attachments: SOLR-14539.patch, SOLR-14539.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
> many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
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-14609) TestJsonFacetsWithNestedObjects Has Unused Imports
[ https://issues.apache.org/jira/browse/SOLR-14609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148871#comment-17148871 ] Mikhail Khludnev commented on SOLR-14609: - Hi, [~atri]. I broke it in SOLR-14539 > TestJsonFacetsWithNestedObjects Has Unused Imports > -- > > Key: SOLR-14609 > URL: https://issues.apache.org/jira/browse/SOLR-14609 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Atri Sharma >Assignee: Atri Sharma >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] [Commented] (SOLR-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148847#comment-17148847
]
Mikhail Khludnev commented on SOLR-14539:
-
master
https://gitbox.apache.org/repos/asf?p=lucene-solr.git;a=commitdiff;h=f647400e31c0fb238744cece8d3943bc15253ec7
8x
https://gitbox.apache.org/repos/asf?p=lucene-solr.git;a=commitdiff;h=d81e01cfccd90e76e00131ad2750bcca8edbdbf8
Although, I'm not sure if it got into 8.6.
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Fix For: 8.6
>
> Attachments: SOLR-14539.patch, SOLR-14539.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
> many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
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-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148844#comment-17148844
]
Mikhail Khludnev commented on SOLR-14539:
-
Thanks, [~atris], fixed 8x myself.
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Fix For: 8.6
>
> Attachments: SOLR-14539.patch, SOLR-14539.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
> many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
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-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14539:
Attachment: SOLR-14539.patch
Status: Patch Available (was: Patch Available)
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Fix For: 8.6
>
> Attachments: SOLR-14539.patch, SOLR-14539.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
> many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
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-14557) eDisMax parser unable to parse {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14557:
Attachment: SOLR-14557.patch
Status: Patch Available (was: Patch Available)
> eDisMax parser unable to parse {!lucene}(gigabyte)
> --
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) eDisMax parser unable to parse {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14557:
Attachment: (was: SOLR-14557.patch)
> eDisMax parser unable to parse {!lucene}(gigabyte)
> --
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) eDisMax parser unable to parse {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148478#comment-17148478
]
Mikhail Khludnev edited comment on SOLR-14557 at 6/30/20, 9:46 AM:
---
Note that local params pattern doesn't include closing parenthesis
{code}
| )* (~["=","}"])+ ( "=" ( | ("'"
(<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}")+ (~[")","
","\t","\n","{","^"])* >
{code}
If I include it like
{code}
(~[")"," ","\t","\n","{","^"])* ([")"])? >
{code}
It fixes my test {{\{!lucene}(gigabyte)}}, but breaks another parenthesis
{{(\{!lucene}gigabyte)}}.
was (Author: mkhludnev):
Note that local params pattern doesn't include closing parenthesis
{code}
| )* (~["=","}"])+ ( "=" ( | ("'"
(<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}")+ (~[")","
","\t","\n","{","^"])* >
{code}
If I include it like
{code}
(~[")"," ","\t","\n","{","^"])* ([")"])? >
{code}
It fixes my test {{\{!lucene}(gigabyte)}}, but breaks another parenthesis
{{(\{!lucne}gigabyte)}}.
> eDisMax parser unable to parse {!lucene}(gigabyte)
> --
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) eDisMax parser unable to parse subparser followed by parenthesis
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148480#comment-17148480
]
Mikhail Khludnev commented on SOLR-14557:
-
[~sarowe], [~ysee...@gmail.com], wdyt?
> eDisMax parser unable to parse subparser followed by parenthesis
>
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) eDisMax parser unable to parse {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14557:
Summary: eDisMax parser unable to parse {!lucene}(gigabyte) (was: eDisMax
parser unable to parse subparser followed by parenthesis)
> eDisMax parser unable to parse {!lucene}(gigabyte)
> --
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) eDisMax parser unable to parse subparser followed by parenthesis
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14557:
Attachment: SOLR-14557.patch
Status: Patch Available (was: Patch Available)
Note that local params pattern doesn't include closing parenthesis
{code}
| )* (~["=","}"])+ ( "=" ( | ("'"
(<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}")+ (~[")","
","\t","\n","{","^"])* >
{code}
If I include it like
{code}
(~[")"," ","\t","\n","{","^"])* ([")"])? >
{code}
It fixes my test {{\{!lucene}(gigabyte)}}, but breaks another parenthesis
{{(\{!lucne}gigabyte)}}.
> eDisMax parser unable to parse subparser followed by parenthesis
>
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14539:
Fix Version/s: 8.6
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Fix For: 8.6
>
> Attachments: SOLR-14539.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
> many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
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-14557) eDisMax parser unable to parse subparser followed by parenthesis
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14557:
Status: Patch Available (was: Open)
> eDisMax parser unable to parse subparser followed by parenthesis
>
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) eDisMax parser unable to parse subparser followed by parenthesis
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14557:
Attachment: SOLR-14557.patch
Status: Open (was: Open)
attaching reproducer
> eDisMax parser unable to parse subparser followed by parenthesis
>
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) eDisMax parser unable to parse subparser followed by parenthesis
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14557:
Summary: eDisMax parser unable to parse subparser followed by parenthesis
(was: eDisMax parser switch + braces regression)
> eDisMax parser unable to parse subparser followed by parenthesis
>
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147449#comment-17147449
]
Mikhail Khludnev commented on SOLR-14539:
-
Hi, [~dsmiley].
Absolutely https://github.com/apache/lucene-solr/pull/1628
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Attachments: SOLR-14539.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
> many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
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-9328) Sorting by DocValues while grouping is slower than old good FieldCache
[ https://issues.apache.org/jira/browse/LUCENE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147307#comment-17147307 ] Mikhail Khludnev commented on LUCENE-9328: -- Updating ref guide with the sad truth https://github.com/apache/lucene-solr/pull/1625/files > Sorting by DocValues while grouping is slower than old good FieldCache > -- > > Key: LUCENE-9328 > URL: https://issues.apache.org/jira/browse/LUCENE-9328 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/grouping >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Minor > Attachments: LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, > LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, > LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, > LUCENE-9328.patch > > Time Spent: 2h > Remaining Estimate: 0h > > That's why > https://issues.apache.org/jira/browse/LUCENE-7701?focusedCommentId=17084365=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17084365 -- 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-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147300#comment-17147300
]
Mikhail Khludnev commented on SOLR-14539:
-
I believe the failure above ^ is caused by SOLR-14588. Beside of that, I this
this one is ready to go.
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Attachments: SOLR-14539.patch
>
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
> many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
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-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14539:
Status: Patch Available (was: Open)
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Attachments: SOLR-14539.patch
>
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
> many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
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-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147119#comment-17147119
]
Mikhail Khludnev commented on SOLR-14539:
-
Hi, [~caomanhdat], would you mind to have a look. I want to bring it into 8.6.
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Attachments: SOLR-14539.patch
>
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
> many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
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-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14539:
Attachment: SOLR-14539.patch
Status: Open (was: Open)
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Attachments: SOLR-14539.patch
>
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
> many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
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-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14539:
Description:
It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
-Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
many values-. *UPD* Already done.
Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
facet exclusion in block-join facets.
was:
It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
-Let {{{!bool .. }...}} repeat {{{!filters ..}..}} trick resolve parameter
refs to many values-. *UPD* Already done.
Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
facet exclusion in block-join facets.
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
> many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
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-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14539:
Description:
It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
-Let {{{!bool .. }...}} repeat {{{!filters ..}..}} trick resolve parameter
refs to many values-. *UPD* Already done.
Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
facet exclusion in block-join facets.
was:
It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
Let {{\{!bool .. }...}} repeat {{\{!filters ..}..}} trick resolve parameter
refs to many values. Now if there are many params under the same name it picks
the first one that awkward.
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let {{{!bool .. }...}} repeat {{{!filters ..}..}} trick resolve parameter
> refs to many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
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-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14539:
Summary: Query DSL: Introducing {!bool excludeTags=foo,bar} (was: Query
DSL {!bool filter=$ref} to resolve multiple param values )
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> Let {{\{!bool .. }...}} repeat {{\{!filters ..}..}} trick resolve parameter
> refs to many values. Now if there are many params under the same name it
> picks the first one that awkward.
--
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-14601) Using [child] and [subquery] DocTransformer / FieldList
[
https://issues.apache.org/jira/browse/SOLR-14601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147117#comment-17147117
]
Mikhail Khludnev commented on SOLR-14601:
-
{quote}child has only three allowed parameters: parentFilter,childFilter and
limit.
{quote}
I've checked
[https://lucene.apache.org/solr/guide/8_5/transforming-result-documents.html#child-childdoctransformerfactory]
it says that there's fl in child. Has it been changed since it was documented?
[~dsmiley], wdyt?
> Using [child] and [subquery] DocTransformer / FieldList
> ---
>
> Key: SOLR-14601
> URL: https://issues.apache.org/jira/browse/SOLR-14601
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SearchComponents - other
>Affects Versions: master (9.0), 8.5.2
> Environment: Docker Container 8.5.2 from Docker Hub
> Already existing in 9.0.0
>Reporter: Thomas Taroni
>Priority: Major
>
> If you are using in the fl parameter something like that and
> luceneMatchVersion is higher or equals then 8.0.0 :
> fl=*,[child],customer:[subquery] or
> fl=*,customer:[subquery],[child]
> It ends Up in any case in the following error (BadRequest) inside the
> SubQueryAugmenterFactory:
> {code:java}
> // code placeholder
> if (conflictMap.containsKey(field)) {
> throw new SolrException(ErrorCode.BAD_REQUEST,"[subquery] name "+field+" is
> uplicated");
> } else {
> conflictMap.put(field, true);
> }
> {code}
> It looks like that the following Snippet in ChildDocTransformerFactory(8.5.2
> and 9.0.0) already have added that field to the context.
> {code:java}
> // code placeholder 8.5.2
> String childReturnFields = params.get("fl");
> SolrReturnFields childSolrReturnFields;
> if(childReturnFields != null) {
> childSolrReturnFields = new SolrReturnFields(childReturnFields, req);
> } else if(req.getSchema().getDefaultLuceneMatchVersion().major < 8) {
> // ensure backwards for versions prior to SOLR 8
> childSolrReturnFields = new SolrReturnFields();
> } else {
> childSolrReturnFields = new SolrReturnFields(req);
> }
> {code}
> {code:java}
> // code placeholder master 9.0.0
> String childReturnFields = params.get("fl");
> SolrReturnFields childSolrReturnFields;
> if (childReturnFields != null) {
> childSolrReturnFields = new SolrReturnFields(childReturnFields, req);
> } else {
> childSolrReturnFields = new SolrReturnFields(req);
> }
> {code}
> It looks like childReturnFields includes also the customer:[subquery],
> eventually is a good idea to remove fields from other AugmenterFactories like
> [shard] or [subquery] from the childReturnFields variable
>
--
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-14601) Using [child] and [subquery] DocTransformer / FieldList
[
https://issues.apache.org/jira/browse/SOLR-14601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147076#comment-17147076
]
Mikhail Khludnev commented on SOLR-14601:
-
Hi, [~Thomas Taroni], is it possible to specify {{fl}} inside of {{[child
fl...}}] ?
> Using [child] and [subquery] DocTransformer / FieldList
> ---
>
> Key: SOLR-14601
> URL: https://issues.apache.org/jira/browse/SOLR-14601
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SearchComponents - other
>Affects Versions: master (9.0), 8.5.2
> Environment: Docker Container 8.5.2 from Docker Hub
> Already existing in 9.0.0
>Reporter: Thomas Taroni
>Priority: Major
>
> If you are using in the fl parameter something like that and
> luceneMatchVersion is higher or equals then 8.0.0 :
> fl=*,[child],customer:[subquery] or
> fl=*,customer:[subquery],[child]
> It ends Up in any case in the following error (BadRequest) inside the
> SubQueryAugmenterFactory:
> {code:java}
> // code placeholder
> if (conflictMap.containsKey(field)) {
> throw new SolrException(ErrorCode.BAD_REQUEST,"[subquery] name "+field+" is
> uplicated");
> } else {
> conflictMap.put(field, true);
> }
> {code}
> It looks like that the following Snippet in ChildDocTransformerFactory(8.5.2
> and 9.0.0) already have added that field to the context.
> {code:java}
> // code placeholder 8.5.2
> String childReturnFields = params.get("fl");
> SolrReturnFields childSolrReturnFields;
> if(childReturnFields != null) {
> childSolrReturnFields = new SolrReturnFields(childReturnFields, req);
> } else if(req.getSchema().getDefaultLuceneMatchVersion().major < 8) {
> // ensure backwards for versions prior to SOLR 8
> childSolrReturnFields = new SolrReturnFields();
> } else {
> childSolrReturnFields = new SolrReturnFields(req);
> }
> {code}
> {code:java}
> // code placeholder master 9.0.0
> String childReturnFields = params.get("fl");
> SolrReturnFields childSolrReturnFields;
> if (childReturnFields != null) {
> childSolrReturnFields = new SolrReturnFields(childReturnFields, req);
> } else {
> childSolrReturnFields = new SolrReturnFields(req);
> }
> {code}
> It looks like childReturnFields includes also the customer:[subquery],
> eventually is a good idea to remove fields from other AugmenterFactories like
> [shard] or [subquery] from the childReturnFields variable
>
--
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-14585) Check the current user in SysV init script
[ https://issues.apache.org/jira/browse/SOLR-14585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17146304#comment-17146304 ] Mikhail Khludnev commented on SOLR-14585: - [~cpoerschke], WDYT? > Check the current user in SysV init script > -- > > Key: SOLR-14585 > URL: https://issues.apache.org/jira/browse/SOLR-14585 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: scripts and tools >Affects Versions: 8.5.2 >Reporter: Roman Kosenko >Priority: Minor > Labels: sysinit, systemd > Attachments: init.d-solr.diff > > > While SOLR-14410 is still open I propose a quick fix/improvement for init.d > script - check the current user and, if it is the same as RUNAS user, then > don't execute "su". > > Background: > Systemd has backward compatibility with SysV and able to run scripts from > /etc/init.d, but SELinux policies in many distros encourage changing user > before this stage and prohibits executing of "su" binary, so it would be > logical to do this at systemd level > (/etc/systemd/system/solr.service.d/override.conf). In this case, the current > init.d script for Solr is missing one very trivial check - `"$RUNAS" != > "$USER"`. See the diff-file in the attachment. -- 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-9328) Sorting by DocValues while grouping is slower than old good FieldCache
[ https://issues.apache.org/jira/browse/LUCENE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9328: - Summary: Sorting by DocValues while grouping is slower than old good FieldCache (was: SortingGroupHead to reuse DocValues) > Sorting by DocValues while grouping is slower than old good FieldCache > -- > > Key: LUCENE-9328 > URL: https://issues.apache.org/jira/browse/LUCENE-9328 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/grouping >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Minor > Attachments: LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, > LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, > LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, > LUCENE-9328.patch > > Time Spent: 1h 50m > Remaining Estimate: 0h > > That's why > https://issues.apache.org/jira/browse/LUCENE-7701?focusedCommentId=17084365=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17084365 -- 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-14585) Check the current user in SysV init script
[ https://issues.apache.org/jira/browse/SOLR-14585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17144675#comment-17144675 ] Mikhail Khludnev commented on SOLR-14585: - I'm happy to merge this oneliner if we have another pair of eyes confirming that it doesn't hurt. > Check the current user in SysV init script > -- > > Key: SOLR-14585 > URL: https://issues.apache.org/jira/browse/SOLR-14585 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: scripts and tools >Affects Versions: 8.5.2 >Reporter: Roman Kosenko >Priority: Minor > Labels: sysinit, systemd > Attachments: init.d-solr.diff > > > While SOLR-14410 is still open I propose a quick fix/improvement for init.d > script - check the current user and, if it is the same as RUNAS user, then > don't execute "su". > > Background: > Systemd has backward compatibility with SysV and able to run scripts from > /etc/init.d, but SELinux policies in many distros encourage changing user > before this stage and prohibits executing of "su" binary, so it would be > logical to do this at systemd level > (/etc/systemd/system/solr.service.d/override.conf). In this case, the current > init.d script for Solr is missing one very trivial check - `"$RUNAS" != > "$USER"`. See the diff-file in the attachment. -- 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-9328) SortingGroupHead to reuse DocValues
[
https://issues.apache.org/jira/browse/LUCENE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17138772#comment-17138772
]
Mikhail Khludnev commented on LUCENE-9328:
--
Recently, the following wrong statement brought up in te mailing list
{quote}From the DocValues documentation
([https://lucene.apache.org/solr/guide/8_3/docvalues.html]), it mentions that
this approach promises to make lookups for faceting, sorting and grouping much
faster.
{quote}
I suppose until it's resolved, I propose to remove grouping from the list of
beneficiaries. WDYT?
> SortingGroupHead to reuse DocValues
> ---
>
> Key: LUCENE-9328
> URL: https://issues.apache.org/jira/browse/LUCENE-9328
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/grouping
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Minor
> Attachments: LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch,
> LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch,
> LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch,
> LUCENE-9328.patch
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> That's why
> https://issues.apache.org/jira/browse/LUCENE-7701?focusedCommentId=17084365=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17084365
--
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-14557) eDisMax parser switch + braces regression
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17133301#comment-17133301
]
Mikhail Khludnev edited comment on SOLR-14557 at 6/11/20, 2:38 PM:
---
Thanks for response , [~dsmiley].
# it seems like bug in syntax parsing
# I trust users
# they have many old queries in curly braces where they switch different parses
(mostly \{!join}) arbitrarily, so defType isn't an option
# it seems I achieved what uf does via luceneMatchVersion = 4.5 in config
that's I'v got SOLR-11501 notes. So, uf doesn't bring any value to me. Or it
should?
# So everything seems working (switching \{!parser} inside of edismax query)
until users add {{(}} braces {{)}}.
So, old query doesn't work for them. It seems like a bug outside of SOLR-11501
or loosely related to it.
was (Author: mkhludnev):
Thanks for response , [~dsmiley].
# it seems like bug in syntax parsing
# I trust users
# they have many old queries in curly braces where they switch different parses
(mostly \{!join}) arbitrarily, so defType isn't an option
# it seems I achieved what uf does via luceneMatchVersion = 4.5 in config
that's I'v got SOLR-11501 notes. So, uf doesn't bring any value to me. Or it
should?
# So everything seems working (switching \{!parser} inside of edismax query)
until users add {{(}}braces{{)}}.
So, old query doesn't work for them. It seems like a bug outside of SOLR-11501
or loosely related to it.
> eDisMax parser switch + braces regression
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) eDisMax parser switch + braces regression
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17133301#comment-17133301
]
Mikhail Khludnev commented on SOLR-14557:
-
Thanks for response , [~dsmiley].
# it seems like bug in syntax parsing
# I trust users
# they have many old queries in curly braces where they switch different parses
(mostly \{!join}) arbitrarily, so defType isn't an option
# it seems I achieved what uf does via luceneMatchVersion = 4.5 in config
that's I'v got SOLR-11501 notes. So, uf doesn't bring any value to me. Or it
should?
# So everything seems working (switching \{!parser} inside of edismax query)
until users add {{(}}braces{{)}}.
So, old query doesn't work for them. It seems like a bug outside of SOLR-11501
or loosely related to it.
> eDisMax parser switch + braces regression
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) eDisMax parser switch + braces regression
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17133301#comment-17133301
]
Mikhail Khludnev edited comment on SOLR-14557 at 6/11/20, 2:38 PM:
---
Thanks for response , [~dsmiley].
# it seems like bug in syntax parsing
# I trust users
# they have many old queries in curly braces where they switch different parses
(mostly \{!join}) arbitrarily, so defType isn't an option
# it seems I achieved what uf does via luceneMatchVersion = 4.5 in config
that's I'v got SOLR-11501 notes. So, uf doesn't bring any value to me. Or it
should?
# So everything seems working (switching \{!parser} inside of edismax query)
until users add {{(}}braces{{)}}.
So, old query doesn't work for them. It seems like a bug outside of SOLR-11501
or loosely related to it.
was (Author: mkhludnev):
Thanks for response , [~dsmiley].
# it seems like bug in syntax parsing
# I trust users
# they have many old queries in curly braces where they switch different parses
(mostly \{!join}) arbitrarily, so defType isn't an option
# it seems I achieved what uf does via luceneMatchVersion = 4.5 in config
that's I'v got SOLR-11501 notes. So, uf doesn't bring any value to me. Or it
should?
# So everything seems working (switching \{!parser} inside of edismax query)
until users add {{(}}braces{{)}}.
So, old query doesn't work for them. It seems like a bug outside of SOLR-11501
or loosely related to it.
> eDisMax parser switch + braces regression
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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] [Resolved] (SOLR-14442) bin/solr to attempt jstack before killing hung Solr instance
[
https://issues.apache.org/jira/browse/SOLR-14442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev resolved SOLR-14442.
-
Fix Version/s: 8.6
Resolution: Fixed
> bin/solr to attempt jstack before killing hung Solr instance
>
>
> Key: SOLR-14442
> URL: https://issues.apache.org/jira/browse/SOLR-14442
> Project: Solr
> Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 8.6
>
> Attachments: SOLR-14442.patch, SOLR-14442.patch, SOLR-14442.patch,
> screenshot-1.png
>
>
> If a Solr instance did not respond to the 'stop' command in a timely manner
> then the {{bin/solr}} script will attempt to forcefully kill it:
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/solr/bin/solr#L859]
> Gathering of information (e.g. a jstack of the java process) before the kill
> command may be helpful in determining why the instance did not stop as
> expected.
--
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-14557) eDisMax parser switch + braces regression
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14557:
Summary: eDisMax parser switch + braces regression (was: eDisMax
(regression))
> eDisMax parser switch + braces regression
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) eDisMax (regression)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14557:
Description:
h2. Solr 4.5
{{/select?defType=edismax=\{!lucene}(foo)=true}}
goes like
{code}
\{!lucene}(foo)
content:foo
LuceneQParser
{code}
fine
h2. Solr 8.2
with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
it's a question of migrating existing queries.
{{/select?defType=edismax=\{!lucene}(foo)=true}}
goes like
{code}
"querystring":"\{!lucene}(foo)",
"parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
"QParser":"ExtendedDismaxQParser",
{code}
blah...
but removing braces in 8.2 works perfectly fine
{code}
"querystring":"\{!lucene}foo",
"parsedquery":"+content:foo",
"parsedquery_toString":"+content:foo",
"QParser":"ExtendedDismaxQParser",
{code}
was:
h2. Solr 4.5
{{/select?defType=edismax={!lucene}(foo)=true}}
goes like
{code}
{!lucene}(foo)
content:foo
LuceneQParser
{code}
fine
h2. Solr 8.2
with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
it's a question of migrating existing queries.
{{/select?defType=edismax={!lucene}(foo)=true}}
goes like
{code}
"querystring":"{!lucene}(foo)",
"parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
"QParser":"ExtendedDismaxQParser",
{code}
blah...
but removing braces in 8.2 works perfectly fine
{code}
"querystring":"{!lucene}foo",
"parsedquery":"+content:foo",
"parsedquery_toString":"+content:foo",
"QParser":"ExtendedDismaxQParser",
{code}
> eDisMax (regression)
>
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14557) eDisMax (regression)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14557:
Description:
h2. Solr 4.5
{{/select?defType=edismax={!lucene}(foo)=true}}
goes like
{code}
{!lucene}(foo)
content:foo
LuceneQParser
{code}
fine
h2. Solr 8.2
with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
it's a question of migrating existing queries.
{{/select?defType=edismax={!lucene}(foo)=true}}
goes like
{code}
"querystring":"{!lucene}(foo)",
"parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
"QParser":"ExtendedDismaxQParser",
{code}
blah...
but removing braces in 8.2 works perfectly fine
{code}
"querystring":"{!lucene}foo",
"parsedquery":"+content:foo",
"parsedquery_toString":"+content:foo",
"QParser":"ExtendedDismaxQParser",
{code}
was:
h2. Solr 4.5
{{/select?defType=edismax={!lucene}(foo)=true}}
goes like
{code}
{!lucene}(foo)
content:foo
LuceneQParser
{code}
fine
h2. Solr 8.2
with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
it's a question of migrating existing queries.
{{/select?defType=edismax={!lucene}(foo)=true}}
goes like
{code}
"querystring":"{!lucene}(foo)",
"parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
"QParser":"ExtendedDismaxQParser",
{code}
blah...
but removing braces in 8.2 works perfectly fine
{code}
"querystring":"{!lucene}foo",
"parsedquery":"+content:foo",
"parsedquery_toString":"+content:foo",
"QParser":"ExtendedDismaxQParser",
{code}
> eDisMax (regression)
>
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
>
> h2. Solr 4.5
> {{/select?defType=edismax={!lucene}(foo)=true}}
> goes like
> {code}
> {!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax={!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
>"QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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] [Created] (SOLR-14557) eDisMax regression
Mikhail Khludnev created SOLR-14557:
---
Summary: eDisMax regression
Key: SOLR-14557
URL: https://issues.apache.org/jira/browse/SOLR-14557
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: query parsers
Reporter: Mikhail Khludnev
h2. Solr 4.5
{{/select?defType=edismax={!lucene}(foo)=true}}
goes like
{code}
{!lucene}(foo)
content:foo
LuceneQParser
{code}
fine
h2. Solr 8.2
with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
it's a question of migrating existing queries.
{{/select?defType=edismax={!lucene}(foo)=true}}
goes like
{code}
"querystring":"{!lucene}(foo)",
"parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
"QParser":"ExtendedDismaxQParser",
{code}
blah...
but removing braces in 8.2 works perfectly fine
{code}
"querystring":"{!lucene}foo",
"parsedquery":"+content:foo",
"parsedquery_toString":"+content:foo",
"QParser":"ExtendedDismaxQParser",
{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-14557) eDisMax (regression)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14557:
Summary: eDisMax (regression) (was: eDisMax regression)
> eDisMax (regression)
>
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
>
> h2. Solr 4.5
> {{/select?defType=edismax={!lucene}(foo)=true}}
> goes like
> {code}
> {!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax={!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
>"QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {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-14539) Query DSL {!bool filter=$ref} to resolve multiple param values
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17127392#comment-17127392
]
Mikhail Khludnev commented on SOLR-14539:
-
it's also worth to pull {{excludeTags}} from {{\{!filters ... }.. }} as well.
> Query DSL {!bool filter=$ref} to resolve multiple param values
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> Let {{\{!bool .. }...}} repeat {{\{!filters ..}..}} trick resolve parameter
> refs to many values. Now if there are many params under the same name it
> picks the first one that awkward.
--
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-14419) Query DLS {"param":"ref"}
[
https://issues.apache.org/jira/browse/SOLR-14419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14419:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Query DLS {"param":"ref"}
> -
>
> Key: SOLR-14419
> URL: https://issues.apache.org/jira/browse/SOLR-14419
> Project: Solr
> Issue Type: Improvement
> Components: JSON Request API
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.6
>
> Attachments: SOLR-14419-refguide.patch, SOLR-14419.patch,
> SOLR-14419.patch, SOLR-14419.patch
>
>
> What we can do with plain params:
> {{q=\{!parent which=$prnts}...=type:parent}}
> obviously I want to have something like this in Query DSL:
> {code}
> { "query": { "parents":{ "which":{"param":"prnts"}, "query":"..."}}
> "params": {
> "prnts":"type:parent"
>}
> }
> {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-14442) bin/solr to attempt jstack before killing hung Solr instance
[
https://issues.apache.org/jira/browse/SOLR-14442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17127328#comment-17127328
]
Mikhail Khludnev commented on SOLR-14442:
-
oh.. I forgot to add CHANGES.txt, will fix it soon.
> bin/solr to attempt jstack before killing hung Solr instance
>
>
> Key: SOLR-14442
> URL: https://issues.apache.org/jira/browse/SOLR-14442
> Project: Solr
> Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-14442.patch, SOLR-14442.patch, SOLR-14442.patch,
> screenshot-1.png
>
>
> If a Solr instance did not respond to the 'stop' command in a timely manner
> then the {{bin/solr}} script will attempt to forcefully kill it:
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/solr/bin/solr#L859]
> Gathering of information (e.g. a jstack of the java process) before the kill
> command may be helpful in determining why the instance did not stop as
> expected.
--
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] (SOLR-14540) Ref Guide: Document how-to for Block Join Facets via Query DSL
Mikhail Khludnev created SOLR-14540: --- Summary: Ref Guide: Document how-to for Block Join Facets via Query DSL Key: SOLR-14540 URL: https://issues.apache.org/jira/browse/SOLR-14540 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Mikhail Khludnev Solr has an old good feature https://lucene.apache.org/solr/guide/8_5/faceting.html#tagging-and-excluding-filters. I'd like to document similar solution/snippet for https://lucene.apache.org/solr/guide/8_5/json-faceting-domain-changes.html#block-join-domain-changes in Query DSL. This solution combines several elements, so it's not clear where to put it. Does it deserve separate page or just a paragraph somewhere? Snippet is already [there|https://issues.apache.org/jira/browse/SOLR-14419?focusedCommentId=17112869=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17112869] it just needs some tweaks. -- 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-14540) Ref Guide: Document how-to for Block Join Facets via Query DSL
[ https://issues.apache.org/jira/browse/SOLR-14540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17127120#comment-17127120 ] Mikhail Khludnev commented on SOLR-14540: - [~ctargett], can you suggest where to put his snippet in the ref guide? > Ref Guide: Document how-to for Block Join Facets via Query DSL > -- > > Key: SOLR-14540 > URL: https://issues.apache.org/jira/browse/SOLR-14540 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Priority: Major > > Solr has an old good feature > https://lucene.apache.org/solr/guide/8_5/faceting.html#tagging-and-excluding-filters. > I'd like to document similar solution/snippet for > https://lucene.apache.org/solr/guide/8_5/json-faceting-domain-changes.html#block-join-domain-changes > in Query DSL. This solution combines several elements, so it's not clear > where to put it. Does it deserve separate page or just a paragraph somewhere? > Snippet is already > [there|https://issues.apache.org/jira/browse/SOLR-14419?focusedCommentId=17112869=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17112869] > it just needs some tweaks. -- 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] (SOLR-14539) Query DSL {!bool filter=$ref} to resolve multiple param values
Mikhail Khludnev created SOLR-14539:
---
Summary: Query DSL {!bool filter=$ref} to resolve multiple param
values
Key: SOLR-14539
URL: https://issues.apache.org/jira/browse/SOLR-14539
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: query parsers
Reporter: Mikhail Khludnev
It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
Let {{\{!bool .. }...}} repeat {{\{!filters ..}..}} trick resolve parameter
refs to many values. Now if there are many params under the same name it picks
the first one that awkward.
--
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-14384) Stack SolrRequestInfo
[
https://issues.apache.org/jira/browse/SOLR-14384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17127093#comment-17127093
]
Mikhail Khludnev commented on SOLR-14384:
-
[~dsmiley], one question. Why leaking SRI just notifies in logs, but recursion
in QParser is guarded with exception?
> Stack SolrRequestInfo
> -
>
> Key: SOLR-14384
> URL: https://issues.apache.org/jira/browse/SOLR-14384
> Project: Solr
> Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Sometimes SolrRequestInfo need to be suspended/overridden with a new one that
> is used temporarily. Examples are in the {{[subquery]}} transformer, and in
> warm of caches, and in QuerySenderListener (another type of warming), maybe
> others. This can be annoying to do correctly, and in at least one place it
> isn't done correctly. SolrRequestInfoSuspender shows some complexity. In
> this issue, [~dsmiley] proposes using a stack internally to SolrRequestInfo
> that is push'ed and pop'ed. It's not the only way to solve this but it's one
> way.
> See linked issues for the context and discussion.
--
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-14518) Add support for partitioned unique agg to JSON facets
[ https://issues.apache.org/jira/browse/SOLR-14518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125661#comment-17125661 ] Mikhail Khludnev commented on SOLR-14518: - [~dan2097] It sounds like a way to go, but I've already made wrong suggestion in the comment above. So, beware. > Add support for partitioned unique agg to JSON facets > - > > Key: SOLR-14518 > URL: https://issues.apache.org/jira/browse/SOLR-14518 > Project: Solr > Issue Type: New Feature > Components: Facet Module >Reporter: Joel Bernstein >Priority: Major > > There are scenarios where documents are partitioned across shards based on > the same field that the *unique* agg is applied to with JSON facets. In this > scenario exact unique counts can be calculated by simply sending the bucket > level unique counts to the aggregator where they can be summed. Suggested > syntax is to add a boolean flag to the unique aggregation function: > *unique*(partitioned_field, true). > The *true* value turns on the "partitioned" unique logic. The default is > false. -- 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
