[jira] [Updated] (LUCENE-7416) BooleanQuery rewrite optimizations
[ https://issues.apache.org/jira/browse/LUCENE-7416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Spyros Kapnissis updated LUCENE-7416: - Attachment: LUCENE-7146.patch A patch for review, with corresponding tests. > BooleanQuery rewrite optimizations > -- > > Key: LUCENE-7416 > URL: https://issues.apache.org/jira/browse/LUCENE-7416 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Affects Versions: master (7.0) >Reporter: Spyros Kapnissis >Priority: Minor > Attachments: LUCENE-7146.patch > > > A couple of BooleanQuery rewrites / optimizations. > First, as discussed on the user group, a BooleanQuery with a query that is > both a SHOULD and a FILTER can be rewritten as a single MUST query, but care > must be taken to decrement minShouldMatch by 1. > Another case is if a query is both required (MUST or FILTER) and MUST_NOT at > the same time, it can be converted to a MatchNoDocsQuery (although I haven't > discussed this yet so hopefully I'm not missing something!). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7416) BooleanQuery rewrite optimizations
Spyros Kapnissis created LUCENE-7416: Summary: BooleanQuery rewrite optimizations Key: LUCENE-7416 URL: https://issues.apache.org/jira/browse/LUCENE-7416 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: master (7.0) Reporter: Spyros Kapnissis Priority: Minor A couple of BooleanQuery rewrites / optimizations. First, as discussed on the user group, a BooleanQuery with a query that is both a SHOULD and a FILTER can be rewritten as a single MUST query, but care must be taken to decrement minShouldMatch by 1. Another case is if a query is both required (MUST or FILTER) and MUST_NOT at the same time, it can be converted to a MatchNoDocsQuery (although I haven't discussed this yet so hopefully I'm not missing something!). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7495) Unexpected docvalues type NUMERIC when grouping by a int facet
[
https://issues.apache.org/jira/browse/SOLR-7495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14941011#comment-14941011
]
Spyros Kapnissis commented on SOLR-7495:
Same error with 5.3.1. Changing the grouping field to string type as mentioned
above temporarily resolved the issue for me.
> Unexpected docvalues type NUMERIC when grouping by a int facet
> --
>
> Key: SOLR-7495
> URL: https://issues.apache.org/jira/browse/SOLR-7495
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.3
>Reporter: Fabio Batista da Silva
> Attachments: SOLR-7495.patch
>
>
> Hey All,
> After upgrading from solr 4.10 to 5.1 with solr could
> I'm getting a IllegalStateException when i try to facet a int field.
> IllegalStateException: unexpected docvalues type NUMERIC for field 'year'
> (expected=SORTED). Use UninvertingReader or index with docvalues.
> schema.xml
> {code}
>
>
>
>
>
>
> multiValued="false" required="true"/>
> multiValued="false" required="true"/>
>
>
> stored="true"/>
>
>
>
> />
> sortMissingLast="true"/>
> positionIncrementGap="0"/>
> positionIncrementGap="0"/>
> positionIncrementGap="0"/>
> precisionStep="0" positionIncrementGap="0"/>
> positionIncrementGap="0"/>
> positionIncrementGap="100">
>
>
> words="stopwords.txt" />
>
> maxGramSize="15"/>
>
>
>
> words="stopwords.txt" />
> synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
>
>
>
> positionIncrementGap="100">
>
>
> words="stopwords.txt" />
>
> maxGramSize="15"/>
>
>
>
> words="stopwords.txt" />
> synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
>
>
>
> class="solr.SpatialRecursivePrefixTreeFieldType" geo="true"
> distErrPct="0.025" maxDistErr="0.09" units="degrees" />
>
> id
> name
>
>
> {code}
> query :
> {code}
> http://solr.dev:8983/solr/my_collection/select?wt=json&fl=id&fq=index_type:foobar&group=true&group.field=year_make_model&group.facet=true&facet=true&facet.field=year
> {code}
> Exception :
> {code}
> ull:org.apache.solr.common.SolrException: Exception during facet.field: year
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:627)
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:612)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at org.apache.solr.request.SimpleFacets$2.execute(SimpleFacets.java:566)
> at
> org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:637)
> at
> org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:280)
> at
> org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:106)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:222)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1984)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:829)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:446)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at
> org.e
[jira] [Commented] (SOLR-6131) Remove deprecated Token class from solr.spelling package
[ https://issues.apache.org/jira/browse/SOLR-6131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14017663#comment-14017663 ] Spyros Kapnissis commented on SOLR-6131: Not sure it's that easy. There are a lot of places that it is still being used, even though it's obsolete since version 2.9. Any refactoring has to happen incrementally imo. This patch is specifically for the solr.spelling package. > Remove deprecated Token class from solr.spelling package > > > Key: SOLR-6131 > URL: https://issues.apache.org/jira/browse/SOLR-6131 > Project: Solr > Issue Type: Improvement > Components: spellchecker >Affects Versions: 4.8.1 >Reporter: Spyros Kapnissis >Priority: Minor > Labels: spellchecker > Attachments: NukeToken.patch, SOLR-6131.patch > > > The deprecated Token class is used everywhere in the spelling package. I am > attaching a patch that refactors/replaces all occurrences with the > AttributeSource class. The tests are passing. > Note: the AttributeSource class also replaces Token as a hash key in many > places. Having stricter equals/hashCode requirements than Token, I am a bit > concerned that it could produce some duplicate suggestions, especially in the > case of ConjunctionSolrSpellChecker where merging of the different spell > checking suggestions takes place. If this initial approach is fine, I can > create some extra checks/unit tests for this. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6131) Remove deprecated Token class from solr.spelling package
[ https://issues.apache.org/jira/browse/SOLR-6131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14017385#comment-14017385 ] Spyros Kapnissis commented on SOLR-6131: Hi Ahmet, Yes, I already attached a patch that does that (replaces deprecated Token class with newer TokenStream API's AttributeSource). > Remove deprecated Token class from solr.spelling package > > > Key: SOLR-6131 > URL: https://issues.apache.org/jira/browse/SOLR-6131 > Project: Solr > Issue Type: Improvement > Components: spellchecker >Affects Versions: 4.8.1 >Reporter: Spyros Kapnissis >Priority: Minor > Labels: spellchecker > Attachments: SOLR-6131.patch > > > The deprecated Token class is used everywhere in the spelling package. I am > attaching a patch that refactors/replaces all occurrences with the > AttributeSource class. The tests are passing. > Note: the AttributeSource class also replaces Token as a hash key in many > places. Having stricter equals/hashCode requirements than Token, I am a bit > concerned that it could produce some duplicate suggestions, especially in the > case of ConjunctionSolrSpellChecker where merging of the different spell > checking suggestions takes place. If this initial approach is fine, I can > create some extra checks/unit tests for this. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6131) Remove deprecated Token class from solr.spelling package
[ https://issues.apache.org/jira/browse/SOLR-6131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Spyros Kapnissis updated SOLR-6131: --- Attachment: SOLR-6131.patch > Remove deprecated Token class from solr.spelling package > > > Key: SOLR-6131 > URL: https://issues.apache.org/jira/browse/SOLR-6131 > Project: Solr > Issue Type: Improvement > Components: spellchecker >Affects Versions: 4.8.1 >Reporter: Spyros Kapnissis >Priority: Minor > Labels: spellchecker > Attachments: SOLR-6131.patch > > > The deprecated Token class is used everywhere in the spelling package. I am > attaching a patch that refactors/replaces all occurrences with the > AttributeSource class. The tests are passing. > Note: the AttributeSource class also replaces Token as a hash key in many > places. Having stricter equals/hashCode requirements than Token, I am a bit > concerned that it could produce some duplicate suggestions, especially in the > case of ConjunctionSolrSpellChecker where merging of the different spell > checking suggestions takes place. If this initial approach is fine, I can > create some extra checks/unit tests for this. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6131) Remove deprecated Token class from solr.spelling package
Spyros Kapnissis created SOLR-6131: -- Summary: Remove deprecated Token class from solr.spelling package Key: SOLR-6131 URL: https://issues.apache.org/jira/browse/SOLR-6131 Project: Solr Issue Type: Improvement Components: spellchecker Affects Versions: 4.8.1 Reporter: Spyros Kapnissis Priority: Minor Attachments: SOLR-6131.patch The deprecated Token class is used everywhere in the spelling package. I am attaching a patch that refactors/replaces all occurrences with the AttributeSource class. The tests are passing. Note: the AttributeSource class also replaces Token as a hash key in many places. Having stricter equals/hashCode requirements than Token, I am a bit concerned that it could produce some duplicate suggestions, especially in the case of ConjunctionSolrSpellChecker where merging of the different spell checking suggestions takes place. If this initial approach is fine, I can create some extra checks/unit tests for this. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5905) CollapsingQParserPlugin throws a NPE if required 'field' param is missing
[ https://issues.apache.org/jira/browse/SOLR-5905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Spyros Kapnissis updated SOLR-5905: --- Attachment: SOLR-5905.patch A simple patch to handle this case. > CollapsingQParserPlugin throws a NPE if required 'field' param is missing > - > > Key: SOLR-5905 > URL: https://issues.apache.org/jira/browse/SOLR-5905 > Project: Solr > Issue Type: Bug > Components: query parsers >Affects Versions: 4.7, 5.0 >Reporter: Spyros Kapnissis >Priority: Minor > Attachments: SOLR-5905.patch > > > A NullPointerException is thrown if the required 'field' param is missing (in > the hashCode method). This might confuse the users if they forget or misspell > it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5905) CollapsingQParserPlugin throws a NPE if required 'field' param is missing
Spyros Kapnissis created SOLR-5905: -- Summary: CollapsingQParserPlugin throws a NPE if required 'field' param is missing Key: SOLR-5905 URL: https://issues.apache.org/jira/browse/SOLR-5905 Project: Solr Issue Type: Bug Components: query parsers Affects Versions: 4.7, 5.0 Reporter: Spyros Kapnissis Priority: Minor A NullPointerException is thrown if the required 'field' param is missing (in the hashCode method). This might confuse the users if they forget or misspell it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2767) ClassCastException when using FieldAnalysisResponse and the analyzer list contains the CharMappingFilter (or any CharFilter)
ClassCastException when using FieldAnalysisResponse and the analyzer list contains the CharMappingFilter (or any CharFilter) Key: SOLR-2767 URL: https://issues.apache.org/jira/browse/SOLR-2767 Project: Solr Issue Type: Bug Affects Versions: 3.3, 4.0 Reporter: Spyros Kapnissis I use the FieldAnalysisResponse class in order to gather some information about the analysis process. However, I get a ClassCastException (cannot convert String to NamedList) thrown at AnalysisResponseBase.buildPhases method if I have included the CharMappingFilter in my configuration. It seems that a CharFilter does not create a NamedList, but a String entry in the analysis response. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
