[jira] [Commented] (SOLR-11750) Collection aliases should be easier manage
[ https://issues.apache.org/jira/browse/SOLR-11750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16295661#comment-16295661 ] Scott Stults commented on SOLR-11750: - Exactly right. This is something that I think should be added to the Angular CollectionsController, or somewhere thereabout. > Collection aliases should be easier manage > -- > > Key: SOLR-11750 > URL: https://issues.apache.org/jira/browse/SOLR-11750 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 6.6, 7.0.1, 7.1 >Reporter: Scott Stults >Priority: Minor > > Currently the only way to determine which aliases apply to a collection is to > go into the tree view of the cloud page and look at the contents of the > aliases node. It would be handy to have this information alongside the other > collection details. Also, the delete alias drop-down shows all of the aliases > for all collections, not just the one that applies to the currently viewed > collection. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11750) Collection aliases should be easier manage
Scott Stults created SOLR-11750: --- Summary: Collection aliases should be easier manage Key: SOLR-11750 URL: https://issues.apache.org/jira/browse/SOLR-11750 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: Admin UI Affects Versions: 7.1, 7.0.1, 6.6 Reporter: Scott Stults Priority: Minor Currently the only way to determine which aliases apply to a collection is to go into the tree view of the cloud page and look at the contents of the aliases node. It would be handy to have this information alongside the other collection details. Also, the delete alias drop-down shows all of the aliases for all collections, not just the one that applies to the currently viewed collection. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6603) consider restrictions on what Similarity.coord() can return
[
https://issues.apache.org/jira/browse/LUCENE-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16039695#comment-16039695
]
Scott Stults commented on LUCENE-6603:
--
Has this been made obsolete by LUCENE-7369?
> consider restrictions on what Similarity.coord() can return
> ---
>
> Key: LUCENE-6603
> URL: https://issues.apache.org/jira/browse/LUCENE-6603
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
>
> Today, Similarity.coord() can really return anything, though all of our
> similarities are well-behaved, issues are all about custom ones:
> {code}
>* @param overlap the number of query terms matched in the document
>* @param maxOverlap the total number of terms in the query
>* @return a score factor based on term overlap with the query
>*/
> public float coord(int overlap, int maxOverlap)
> {code}
> But problems arise when a custom similarity implements {{coord(1, 1)}} to
> return something crazy (say 2). In this case their coord impl is ignored (see
> LUCENE-4300). {{coord(1,1)}} is always treated as 1, or things make no sense,
> for example A NOT B would score differently from A (which would be a simple
> termquery and have no BQ around it). Same goes with filters, which should not
> change scoring but would, if we didn't mandate this.
> Now we see the same problem again, with LUCENE-6585. For this optimization to
> work in the current world, it will have to check if {{coord(N,N)}} == 1 in
> order to do it safely. Otherwise it cannot safely collapse conjunctions for
> such custom similarities.
> I would like to enforce that {{coord(N,N)}} is always treated as 1, to
> prevent all these crazy codepaths for wierd, not-so-well-tested cases. So we
> could change the current hack in BooleanWeight.coord():
> {code}
> -- } else if (maxOverlap == 1) {
> ++ } else if (overlap == maxOverlap) {
>return 1f;
> {code}
> Alternatively though, we could change javadocs of Similarity.coord() and add
> a check to BooleanWeight to throw an exception.
> In either case, doing this would be a break, because it would break some
> custom sims out there, at least this one
> (https://mail-archives.apache.org/mod_mbox/lucene-java-user/201208.mbox/%3cf00509b7-8c6b-4496-951b-e89b168d9...@local.ch%3E).
> That one returns {{1/overlap}} which is kinda like averaging the scores, and
> caused us to look into this and open bugs like LUCENE-4297 and LUCENE-4300
> and probably others. But perhaps coord() is not the way such things should be
> done and there is another way instead, to allow BQ to be simpler and more
> efficient.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
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=15812880#comment-15812880
]
Scott Stults commented on SOLR-7495:
[~rcmuir] added that line at the same time as the Insanity wrapper itself as
part of LUCENE-5666, but I'll take a crack at an explanation. There's only a
couple of cases outlined Insanity where we need to wrap the field, essentially
returning null instead of the docValues. When the collector returns null the
stored values of the field are used instead of docValues. Since stored values
are slower than docValues we only want to wrap the particular field type that's
problematic.
> 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
>Assignee: Dennis Gove
> Fix For: 6.4
>
> Attachments: SOLR-7495.patch, SOLR-7495.patch, 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.S
[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=15514067#comment-15514067
]
Scott Stults commented on SOLR-7495:
[~rcmuir] could you weigh in on the approach of the patch? I'd be happy to
tweak it or take a completely different angle if that'll help close this issue.
> 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, 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(ContextHandl
[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=15385813#comment-15385813
]
Scott Stults commented on SOLR-7495:
The patch uploaded in April works for me on the 6.1 branch. Is it not working
for you?
> 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, 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.eclipse.jetty.server.handler.
[jira] [Commented] (SOLR-3916) fl parsing is sensitive to newlines at the end of field names
[
https://issues.apache.org/jira/browse/SOLR-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15381283#comment-15381283
]
Scott Stults commented on SOLR-3916:
Should there be a {{@Test}} annotation on {{testWhitespace()}}? I think some
test runners might do introspection, but all of the other tests in that class
use the annotation and was wondering if that was just an oversight or had
specific meaning.
> fl parsing is sensitive to newlines at the end of field names
> -
>
> Key: SOLR-3916
> URL: https://issues.apache.org/jira/browse/SOLR-3916
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.0-BETA
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 4.0, 4.1, 6.0
>
> Attachments: SOLR-3916.patch
>
>
> As reported by giovanni.bricconi on the user list, there is a bug in "fl"
> parsing that causes solr to get confused when a field name is followed by a
> newline character -- eg: in a requestHandler default like...
> {noformat}
> $
> $
>sku,store_slug$
> $
> {noformat}
> ...this results in solr assuming it should use function parsing to evaluate
> the field name, which can cause missleading errors if the field name can't be
> used in a function (eg: "can not use FieldCache on multivalued field:
> store_slug")
--
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=15379318#comment-15379318
]
Scott Stults commented on SOLR-7495:
The patched test {{testSimpleGroupedFacet}} verifies that this is still an
issue with 6.1. It fails with:
{quote}
Caused by: java.lang.IllegalStateException: unexpected docvalues type NUMERIC
for field 'duration_i1' (expected=SORTED). Use UninvertingReader or index with
docvalues.
{quote}
However, when SimpleFacets.java is also patched the test passes. So this
appears to still be necessary in 6.1.
> 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, 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.eclips
[jira] [Updated] (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:all-tabpanel
]
Scott Stults updated SOLR-7495:
---
Attachment: SOLR-7495.patch
SimpleFacets uses the insanity collector wrapper to return null docValues on
grouping fields that are single-valued numerics. It looks like this also needs
to be done on the facet field as well (when grouping). The attached patch first
checks to see if the grouping field collector needs to be wrapped (that's what
we've been doing) and then a second wrapper is applied if the facet field needs
to be wrapped as well.
The new patch includes the previously attached unit test (now working).
> 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, 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.Sessi
[jira] [Commented] (SOLR-3191) field exclusion from fl
[ https://issues.apache.org/jira/browse/SOLR-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15235622#comment-15235622 ] Scott Stults commented on SOLR-3191: Since this is essentially a wholesale rewrite of SolrReturnFields, would it be easier to manage if it was a separate extension of ReturnFields? That brings up another problem, namely, where we would configure that. We'd gain some flexibility in how the ResponseWriters treat return fields, so maybe that's a good place to select the particular ReturnFields implementation. Kinda spitballing here because I know there is at least one ResponseWriter that requires special handling (CSV) and I suspect GeoJSONResponseWriter might need more (haven't looked yet). > field exclusion from fl > --- > > Key: SOLR-3191 > URL: https://issues.apache.org/jira/browse/SOLR-3191 > Project: Solr > Issue Type: Improvement >Reporter: Luca Cavanna >Priority: Minor > Attachments: SOLR-3191.patch, SOLR-3191.patch, SOLR-3191.patch, > SOLR-3191.patch, SOLR-3191.patch, SOLR-3191.patch > > > I think it would be useful to add a way to exclude field from the Solr > response. If I have for example 100 stored fields and I want to return all of > them but one, it would be handy to list just the field I want to exclude > instead of the 99 fields for inclusion through fl. -- 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] (SOLR-8800) The Latest Release link is out-of-date
Scott Stults created SOLR-8800: -- Summary: The Latest Release link is out-of-date Key: SOLR-8800 URL: https://issues.apache.org/jira/browse/SOLR-8800 Project: Solr Issue Type: Bug Components: website Affects Versions: 5.4.1, 5.5, 5.4 Reporter: Scott Stults Priority: Trivial Navigating from the website to Resources->Docs, under Release Documentation, the link called Latest Release points to 5.3.1 docs. The homepage lists 5.5.0 as the latest. -- 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] [Updated] (SOLR-7597) TestRandomFaceting.testRandomFaceting failure
[
https://issues.apache.org/jira/browse/SOLR-7597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Stults updated SOLR-7597:
---
Attachment: SOLR-7597.patch
This patch checks to make sure delete requests don't exceed max boolean clauses.
During the test we randomly add more documents and randomly delete some. So
it's possible for the number of IDs in the model to grow beyond max booleans,
and it's also possible for us to coincidentally ask for 99% of them to be
deleted.
> TestRandomFaceting.testRandomFaceting failure
> -
>
> Key: SOLR-7597
> URL: https://issues.apache.org/jira/browse/SOLR-7597
> Project: Solr
> Issue Type: Bug
> Components: faceting
>Affects Versions: 5.2, Trunk
>Reporter: Steve Rowe
> Attachments: SOLR-7597.patch
>
>
> Reproduces on trunk and branch_5x:
> {noformat}
> ant test -Dtestcase=TestRandomFaceting -Dtests.method=testRandomFaceting
> -Dtests.seed=2513EC725E45D7D5 -Dtests.slow=true -Dtests.locale=es_CU
> -Dtests.timezone=ROK -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
> {noformat}
> {noformat}
>[junit4] 2> 12030 T11 C18 oasc.SolrException.log ERROR
> org.apache.solr.common.SolrException: org.apache.solr.search.SyntaxError:
> Cannot parse 'id:(OPIM JTRN JUIQ BVUJ JZFO HEIX UXEU IGVD GCIY ZYEV GDJV YTWX
> LMEF IWFQ JLKK CUUN UNRP ZCUP CVDM GHJD WAHV TCDX ZVDY NAJM NRIX JDCL XZWR
> MVKC YXIB VCFT AEDD XYRW TZRV LYKR ODDS LSUF VTNE FPOF ALPR AAOF VAOW LUQW
> OVNK LKWJ MOQE HXPC IHXD GRXC SKBD EFFJ OEJC LPJH MORL KETU CMBS ALPE QSMT
> ROCO ZSFL ELUP MLTC RNXM XIZZ XIBV ZYIN GHRZ MWJK UCOL REOP OYPZ FTGY NJLY
> IYPP GHVN PRCW KUCW LENR ABVU GQWC BFDB QWYK WNGI ZPWD BDNC GYJL GOZA JRSC
> CKEM TJVV KEMQ IHQU HNIQ HLKJ UWEM TCHG EUQI ZUBH RONB BZDN KWJR BQZN IPYD
> OSLQ HCBQ MIZR DPYV YTLV ZVAD SUYR ZXCC ZTYW XWVA NKIL AXOK GJOB MYLO JMUU
> DTDI DFLY TPCE MWOH PXRM JJBG AWIQ QMEG XNEW STED NKPW HJDB QVWQ MDTW JNXX
> BCFL MJPL XPWR XXXB PFMN FWLC CTCI YRNY ZETI KVCG PBAC UJCZ IIWL KQWT WSHW
> OYPB IVEQ OHOC YCAR MZJM SYGM JNHQ USBZ MLMO RIBP VCGN UATJ JLSX XZCR YKVB
> DQTT JLXW XQKA LFGU TKSI ISXG IECJ TSZN ICDA CNLE EOFY MYUJ NFST FKCH RSMU
> XPUK ZAIO SZVS DJAJ BDMV OFQV LVWP BOJB OZWN UTDB GMLY RJGI HBYX ZRLW VMBZ
> JOKG OZSL JDCM FLJZ JIIR VUMR BIKZ OVSU FRKK CLYQ EQTN QKQR AUYT TEHX ESUL
> ERYX YDYZ HRUZ VNJR GUPH RJBB ECJF NEUE FHZS YWZD DTGG KNHF BBIR BNBK FLRO
> BXNC EOVD BCCK IQNX FZGN PMRY JDCB BMEW CCUF XYZN YKDV VMRL KTOO NZAF XMBF
> VYFS AQUV GUFG PRTD YPRM QRGX JXOG MZYE GAQF ICPQ LCPM XXPI OSDZ VTEP RTMB
> DNHW FNZH DGGZ QICW XZZD WAZV RKVP WUCK SIOJ TWDE XWON PGJM GDRU KRYM YHXA
> SKTW UNCV YWJS KRXO IXFL VZFQ YIKQ RIWZ XJSM AWNU VIRQ YTJR DNGD AIDE GAVB
> NAYK ACJM JXOP GHKW BDGQ ORQD VXLF WQAX JZHM GASX CDBH EANO KYDK SPSL TFHV
> HFHI AYBX HCTT HOYE YWDJ YFDB YFNQ ZGNF DSSV SCUT IPLI NHZL HYED VTGA DGQT
> NRDA KMFR LIVF HGCH ZXKV OZHF ETKX HEQX JUYP UVRJ FSRL EUOY XAER JMJK TQQE
> SZRD FTFS ZHSH AXGC LLOF DQFO ORPW EBTN RXRE WUCC SACF TQQM ECTU VIBW YRHJ
> YANS QYYC DLFW KFZP QPTA GTYN DLSH HEBE BKQR ZKNC ADVM KOBU TJEC RUYU DBPW
> PPLF QOAE NSZQ YPLN ROMQ ZXDM FZDP IAWX XLHC PAKI CQSX QTOE KLLR QYVM EENH
> SGBP BNCT PJRU ONVH BKTC QBSA NIDU PQYZ ESRO HPSN DICT VMUU RXLC BCKG XPHV
> SJDA BWBB GTBV ZDTW VGEL PMLP QBJJ AFLF FBNX LFCU OYBD PXSQ UCLB KOEZ JZHT
> JDGF XNUP GUVM BJVC ZLFS OYBK YCAP LWDW ZAAP SNIA QWLY OAIB CVZH EPWB WPJK
> NEBO QEQQ DIQS FYYT REAY IHSC HTMF IYBF GNWP AOPO COLA HVDT MBCU HEHJ JVZE
> WDZA GZMD HSNQ WBGQ EDAS JCVP TFHW KCLS FBDZ YADX GWAF UNMF YAAB MAYF SEVC
> JXQR MMHM CLNC JZYG OYXT MGSB TTPW AOEK OKPO DJOU MBOL WNML QNMN SNLI EFRM
> ZTDE NFBW BABV MZYB UQZR NFWU GOTZ VJIB VMSB REON BNLD KIMC RABW WFYS GQVX
> SKEC YGZY XRTP YEEK JIBD HUDU JEPT VEYH JYQK TMKK PAWS JITH PMAO TPTZ WEYZ
> DDUJ IGIN PLJT UVCI WHUD FAOA TMDV YBDF SGHO ULJY HOIY VLJU FRLE GCJJ TSQG
> CAFT HCLB YMKE ASHE YLCO KOLP KVWS EMQL ELDN KWSF KTEG SMOB ZEWF CPQG JRIC
> CHNN GPTI XJBP KUGV SBPS QYIG EJBW UYKD EMYP YVVP CRLR HYFS ODEV LHUB MTEP
> CXOY QETZ RAQK CZBD ZGHU WMEP LBUU OKPM VZMV EDKB ONHB FVBQ VIVC ETEM NCSI
> ZYEL KTHU HVYM HNFW YLEB HOPD GSBH VJVE FFVD SEAX ZRJH DQSF VEUR WUDN BYNW
> EBET YPVJ SPYS UYQR PUYQ CJLU VTHG FBNW TXOE AYSJ IVBU CUDZ QJLL XDQC VAEU
> RGLA BHFZ WAJW ANBX GBPB NEVF PFOX ONQB HXQH DRQH VCSE GIAZ CGAA UZPL LDMW
> VQDV YSOG LTDO VEOA IKRM GGTX ERKK RDFP ZPSU ZUPA FCYI CJLK HWJS UNNF QAWB
> GPYN FOLP VSZK JDGE YNLI KUUZ LZPP NNQU PSLS OUUR BNIZ FAIU CCZB DDIA UZYF
> CDOS DRJD SJBA UMNM FUWT BBHG UJYC VNVK LKJJ KKAE RFLP RRJU UBZL XGLA FAER
> AKIZ IXIA HIVQ YFOC MUPX ICIU HSFN HJGW GXFU CHEP EJYJ LHOR DORN XRSI JKXX
> PXDS WSHT NYUX SCGQ JFJX WNZM HHIC IREW ZHFF JAEN WIYL POZR RKHB XQGY LTDM
> SLLM ILGO UMQS PKBN VZCA QIGT KPSW BWAR RNBY IHTO HHPU FOSA AHCE KEBI WGBP
> SZIH QZSA PWIC EIUL
[jira] [Commented] (SOLR-7597) TestRandomFaceting.testRandomFaceting failure
[
https://issues.apache.org/jira/browse/SOLR-7597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010069#comment-15010069
]
Scott Stults commented on SOLR-7597:
Would it be okay to hardcode a limit on the number of ids to delete (less than
1024) or should we stick in something like
{{h.getCore().getSolrConfig().booleanQueryMaxClauseCount}}?
> TestRandomFaceting.testRandomFaceting failure
> -
>
> Key: SOLR-7597
> URL: https://issues.apache.org/jira/browse/SOLR-7597
> Project: Solr
> Issue Type: Bug
> Components: faceting
>Affects Versions: 5.2, Trunk
>Reporter: Steve Rowe
>
> Reproduces on trunk and branch_5x:
> {noformat}
> ant test -Dtestcase=TestRandomFaceting -Dtests.method=testRandomFaceting
> -Dtests.seed=2513EC725E45D7D5 -Dtests.slow=true -Dtests.locale=es_CU
> -Dtests.timezone=ROK -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
> {noformat}
> {noformat}
>[junit4] 2> 12030 T11 C18 oasc.SolrException.log ERROR
> org.apache.solr.common.SolrException: org.apache.solr.search.SyntaxError:
> Cannot parse 'id:(OPIM JTRN JUIQ BVUJ JZFO HEIX UXEU IGVD GCIY ZYEV GDJV YTWX
> LMEF IWFQ JLKK CUUN UNRP ZCUP CVDM GHJD WAHV TCDX ZVDY NAJM NRIX JDCL XZWR
> MVKC YXIB VCFT AEDD XYRW TZRV LYKR ODDS LSUF VTNE FPOF ALPR AAOF VAOW LUQW
> OVNK LKWJ MOQE HXPC IHXD GRXC SKBD EFFJ OEJC LPJH MORL KETU CMBS ALPE QSMT
> ROCO ZSFL ELUP MLTC RNXM XIZZ XIBV ZYIN GHRZ MWJK UCOL REOP OYPZ FTGY NJLY
> IYPP GHVN PRCW KUCW LENR ABVU GQWC BFDB QWYK WNGI ZPWD BDNC GYJL GOZA JRSC
> CKEM TJVV KEMQ IHQU HNIQ HLKJ UWEM TCHG EUQI ZUBH RONB BZDN KWJR BQZN IPYD
> OSLQ HCBQ MIZR DPYV YTLV ZVAD SUYR ZXCC ZTYW XWVA NKIL AXOK GJOB MYLO JMUU
> DTDI DFLY TPCE MWOH PXRM JJBG AWIQ QMEG XNEW STED NKPW HJDB QVWQ MDTW JNXX
> BCFL MJPL XPWR XXXB PFMN FWLC CTCI YRNY ZETI KVCG PBAC UJCZ IIWL KQWT WSHW
> OYPB IVEQ OHOC YCAR MZJM SYGM JNHQ USBZ MLMO RIBP VCGN UATJ JLSX XZCR YKVB
> DQTT JLXW XQKA LFGU TKSI ISXG IECJ TSZN ICDA CNLE EOFY MYUJ NFST FKCH RSMU
> XPUK ZAIO SZVS DJAJ BDMV OFQV LVWP BOJB OZWN UTDB GMLY RJGI HBYX ZRLW VMBZ
> JOKG OZSL JDCM FLJZ JIIR VUMR BIKZ OVSU FRKK CLYQ EQTN QKQR AUYT TEHX ESUL
> ERYX YDYZ HRUZ VNJR GUPH RJBB ECJF NEUE FHZS YWZD DTGG KNHF BBIR BNBK FLRO
> BXNC EOVD BCCK IQNX FZGN PMRY JDCB BMEW CCUF XYZN YKDV VMRL KTOO NZAF XMBF
> VYFS AQUV GUFG PRTD YPRM QRGX JXOG MZYE GAQF ICPQ LCPM XXPI OSDZ VTEP RTMB
> DNHW FNZH DGGZ QICW XZZD WAZV RKVP WUCK SIOJ TWDE XWON PGJM GDRU KRYM YHXA
> SKTW UNCV YWJS KRXO IXFL VZFQ YIKQ RIWZ XJSM AWNU VIRQ YTJR DNGD AIDE GAVB
> NAYK ACJM JXOP GHKW BDGQ ORQD VXLF WQAX JZHM GASX CDBH EANO KYDK SPSL TFHV
> HFHI AYBX HCTT HOYE YWDJ YFDB YFNQ ZGNF DSSV SCUT IPLI NHZL HYED VTGA DGQT
> NRDA KMFR LIVF HGCH ZXKV OZHF ETKX HEQX JUYP UVRJ FSRL EUOY XAER JMJK TQQE
> SZRD FTFS ZHSH AXGC LLOF DQFO ORPW EBTN RXRE WUCC SACF TQQM ECTU VIBW YRHJ
> YANS QYYC DLFW KFZP QPTA GTYN DLSH HEBE BKQR ZKNC ADVM KOBU TJEC RUYU DBPW
> PPLF QOAE NSZQ YPLN ROMQ ZXDM FZDP IAWX XLHC PAKI CQSX QTOE KLLR QYVM EENH
> SGBP BNCT PJRU ONVH BKTC QBSA NIDU PQYZ ESRO HPSN DICT VMUU RXLC BCKG XPHV
> SJDA BWBB GTBV ZDTW VGEL PMLP QBJJ AFLF FBNX LFCU OYBD PXSQ UCLB KOEZ JZHT
> JDGF XNUP GUVM BJVC ZLFS OYBK YCAP LWDW ZAAP SNIA QWLY OAIB CVZH EPWB WPJK
> NEBO QEQQ DIQS FYYT REAY IHSC HTMF IYBF GNWP AOPO COLA HVDT MBCU HEHJ JVZE
> WDZA GZMD HSNQ WBGQ EDAS JCVP TFHW KCLS FBDZ YADX GWAF UNMF YAAB MAYF SEVC
> JXQR MMHM CLNC JZYG OYXT MGSB TTPW AOEK OKPO DJOU MBOL WNML QNMN SNLI EFRM
> ZTDE NFBW BABV MZYB UQZR NFWU GOTZ VJIB VMSB REON BNLD KIMC RABW WFYS GQVX
> SKEC YGZY XRTP YEEK JIBD HUDU JEPT VEYH JYQK TMKK PAWS JITH PMAO TPTZ WEYZ
> DDUJ IGIN PLJT UVCI WHUD FAOA TMDV YBDF SGHO ULJY HOIY VLJU FRLE GCJJ TSQG
> CAFT HCLB YMKE ASHE YLCO KOLP KVWS EMQL ELDN KWSF KTEG SMOB ZEWF CPQG JRIC
> CHNN GPTI XJBP KUGV SBPS QYIG EJBW UYKD EMYP YVVP CRLR HYFS ODEV LHUB MTEP
> CXOY QETZ RAQK CZBD ZGHU WMEP LBUU OKPM VZMV EDKB ONHB FVBQ VIVC ETEM NCSI
> ZYEL KTHU HVYM HNFW YLEB HOPD GSBH VJVE FFVD SEAX ZRJH DQSF VEUR WUDN BYNW
> EBET YPVJ SPYS UYQR PUYQ CJLU VTHG FBNW TXOE AYSJ IVBU CUDZ QJLL XDQC VAEU
> RGLA BHFZ WAJW ANBX GBPB NEVF PFOX ONQB HXQH DRQH VCSE GIAZ CGAA UZPL LDMW
> VQDV YSOG LTDO VEOA IKRM GGTX ERKK RDFP ZPSU ZUPA FCYI CJLK HWJS UNNF QAWB
> GPYN FOLP VSZK JDGE YNLI KUUZ LZPP NNQU PSLS OUUR BNIZ FAIU CCZB DDIA UZYF
> CDOS DRJD SJBA UMNM FUWT BBHG UJYC VNVK LKJJ KKAE RFLP RRJU UBZL XGLA FAER
> AKIZ IXIA HIVQ YFOC MUPX ICIU HSFN HJGW GXFU CHEP EJYJ LHOR DORN XRSI JKXX
> PXDS WSHT NYUX SCGQ JFJX WNZM HHIC IREW ZHFF JAEN WIYL POZR RKHB XQGY LTDM
> SLLM ILGO UMQS PKBN VZCA QIGT KPSW BWAR RNBY IHTO HHPU FOSA AHCE KEBI WGBP
> SZIH QZSA PWIC EIUL CXLA LONX DKCC LSSD YITB HHVL MDLR XFNZ QDLR AWVK JVVX
> CQUD JHBL HEBJ HPQY NBFA PZIX FJHM PDPC GYZV YKKY OGAE RQWY FVXG QPBP PJHD
> WASM IXHB XPCW RPE
[jira] [Commented] (SOLR-3191) field exclusion from fl
[ https://issues.apache.org/jira/browse/SOLR-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15004086#comment-15004086 ] Scott Stults commented on SOLR-3191: Right. The reason I ask is, aliases would be a decent alternative for folks who need field names like "1_product" should we start enforcing recommended field name restrictions in the schema. But there are other places in the response where we need to render a field name, like in facets and highlighting (I don't know the details of how that's done), so allowing funky aliases could have side effects. There are other tickets specifically about leading digits in field names (SOLR-7070, SOLR-3407), so I like [~ehatcher]'s suggestion of keeping this focused on the exclusion list aspect and addressing field name enforcement/warning elsewhere. > field exclusion from fl > --- > > Key: SOLR-3191 > URL: https://issues.apache.org/jira/browse/SOLR-3191 > Project: Solr > Issue Type: Improvement >Reporter: Luca Cavanna >Priority: Minor > Attachments: SOLR-3191.patch, SOLR-3191.patch, SOLR-3191.patch, > SOLR-3191.patch > > > I think it would be useful to add a way to exclude field from the Solr > response. If I have for example 100 stored fields and I want to return all of > them but one, it would be handy to list just the field I want to exclude > instead of the 99 fields for inclusion through fl. -- 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-3191) field exclusion from fl
[ https://issues.apache.org/jira/browse/SOLR-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002827#comment-15002827 ] Scott Stults commented on SOLR-3191: I'd definitely be up for trimming out funky field name checks in the tests. Applying field name restrictions just in fl might lead to the situation where data is searchable but not returnable, so should the enforcement portion go to a more central location? Also, should field aliases be restricted in exactly the same way as real field names? > field exclusion from fl > --- > > Key: SOLR-3191 > URL: https://issues.apache.org/jira/browse/SOLR-3191 > Project: Solr > Issue Type: Improvement >Reporter: Luca Cavanna >Priority: Minor > Attachments: SOLR-3191.patch, SOLR-3191.patch, SOLR-3191.patch, > SOLR-3191.patch > > > I think it would be useful to add a way to exclude field from the Solr > response. If I have for example 100 stored fields and I want to return all of > them but one, it would be handy to list just the field I want to exclude > instead of the 99 fields for inclusion through fl. -- 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] [Updated] (SOLR-8147) FieldFacetAccumulator constructor throws too many exceptions
[ https://issues.apache.org/jira/browse/SOLR-8147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Stults updated SOLR-8147: --- Attachment: SOLR-8147.patch This patch is like the last one except it's using IOException rather than SolrException. And yeah, let's keep this Jira short and sweet and open a separate one for moving the checks. > FieldFacetAccumulator constructor throws too many exceptions > > > Key: SOLR-8147 > URL: https://issues.apache.org/jira/browse/SOLR-8147 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 5.0, Trunk >Reporter: Scott Stults >Assignee: Christine Poerschke >Priority: Trivial > Fix For: 5.0, Trunk > > Attachments: SOLR-8147.patch, SOLR-8147.patch > > > The constructor and static create method in FieldFacetAccumulator don't need > to throw IOException, just SolrException. -- 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-8147) FieldFacetAccumulator constructor throws too many exceptions
[ https://issues.apache.org/jira/browse/SOLR-8147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14972855#comment-14972855 ] Scott Stults commented on SOLR-8147: You're right: SolrException isn't an IOException, and the latter is probably more appropriate given the class hierarchy. As far as moving the hasDocValues() check though, I'm conflicted. On the one hand it would be better to catch the problem as early as possible. On the other, locating the check closer to where it's needed reduces code complexity. Which do you think is more valuable in this case? > FieldFacetAccumulator constructor throws too many exceptions > > > Key: SOLR-8147 > URL: https://issues.apache.org/jira/browse/SOLR-8147 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 5.0, Trunk >Reporter: Scott Stults >Priority: Trivial > Fix For: 5.0, Trunk > > Attachments: SOLR-8147.patch > > > The constructor and static create method in FieldFacetAccumulator don't need > to throw IOException, just SolrException. -- 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] [Updated] (SOLR-3191) field exclusion from fl
[ https://issues.apache.org/jira/browse/SOLR-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Stults updated SOLR-3191: --- Attachment: SOLR-3191.patch I updated this patch to work on trunk. A couple of things that didn't seem to work with the last patch were: * When a field is requested both in its bare form as well as with an alias (e.g. "fl=id,myid:id") the bare form was discarded * When fl only contains invalid transformers and aliased exclusion globs, the behavior was expected to be as if * were requested. I was able to get the first case to work by adding the requested aliases to a separate list and then applying the RenameFieldTransformer copy argument selectively. The second case seems really fringe so the best course might be to open it as a separate Jira later if necessary. > field exclusion from fl > --- > > Key: SOLR-3191 > URL: https://issues.apache.org/jira/browse/SOLR-3191 > Project: Solr > Issue Type: Improvement >Reporter: Luca Cavanna >Priority: Minor > Attachments: SOLR-3191.patch, SOLR-3191.patch, SOLR-3191.patch, > SOLR-3191.patch > > > I think it would be useful to add a way to exclude field from the Solr > response. If I have for example 100 stored fields and I want to return all of > them but one, it would be handy to list just the field I want to exclude > instead of the 99 fields for inclusion through fl. -- 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] (LUCENE-4743) ComplexPhraseQuery highlight problem after rewriting using ComplexPhraseQuery.rewrite(IndexReader)
[ https://issues.apache.org/jira/browse/LUCENE-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14949892#comment-14949892 ] Scott Stults commented on LUCENE-4743: -- Looking at the query structure, this could be related to LUCENE-2287 (problems highlighting nested span queries). > ComplexPhraseQuery highlight problem after rewriting using > ComplexPhraseQuery.rewrite(IndexReader) > -- > > Key: LUCENE-4743 > URL: https://issues.apache.org/jira/browse/LUCENE-4743 > Project: Lucene - Core > Issue Type: Bug > Components: core/search, modules/highlighter, modules/queryparser >Affects Versions: 3.6 >Reporter: Jason Nacional > Labels: complexqueryparser, newbie, queryparser > > Just want to ask an assistance using ComplexPhraseQuery. I mean, when it > comes to highlighting the hits are not correct. I also started using > ComplexPhraseQueryParser to support complex proximity searches. -- 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] [Updated] (SOLR-8147) FieldFacetAccumulator constructor throws too many exceptions
[ https://issues.apache.org/jira/browse/SOLR-8147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Stults updated SOLR-8147: --- Attachment: SOLR-8147.patch Patch removes IOException and just leaves SolrException for the constructor and create method. > FieldFacetAccumulator constructor throws too many exceptions > > > Key: SOLR-8147 > URL: https://issues.apache.org/jira/browse/SOLR-8147 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 5.0, Trunk >Reporter: Scott Stults >Priority: Trivial > Fix For: 5.0, Trunk > > Attachments: SOLR-8147.patch > > > The constructor and static create method in FieldFacetAccumulator don't need > to throw IOException, just SolrException. -- 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] (SOLR-8147) FieldFacetAccumulator constructor throws too many exceptions
Scott Stults created SOLR-8147: -- Summary: FieldFacetAccumulator constructor throws too many exceptions Key: SOLR-8147 URL: https://issues.apache.org/jira/browse/SOLR-8147 Project: Solr Issue Type: Improvement Components: SearchComponents - other Affects Versions: 5.0, Trunk Reporter: Scott Stults Priority: Trivial Fix For: Trunk, 5.0 The constructor and static create method in FieldFacetAccumulator don't need to throw IOException, just SolrException. -- 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] [Updated] (SOLR-4647) Grouping is broken on docvalues-only fields
[ https://issues.apache.org/jira/browse/SOLR-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Stults updated SOLR-4647: --- Attachment: SOLR-4647.patch FieldType can interpret BytesRef correctly if you pass it SchemaField in the toObject call. Subclasses override that like in StrField, where toObject returns term.utf8ToString. The attached patch takes that approach. There's also a unit test on string fields that aren't stored or indexed, but have docValues. The test groups and sorts by that docValues-only field. > Grouping is broken on docvalues-only fields > --- > > Key: SOLR-4647 > URL: https://issues.apache.org/jira/browse/SOLR-4647 > Project: Solr > Issue Type: Bug >Affects Versions: 4.2 >Reporter: Adrien Grand > Labels: newdev > Attachments: SOLR-4647.patch > > > There are a few places where grouping uses > FieldType.toObject(SchemaField.createField(String, float)) to translate a > String field value to an Object. The problem is that createField returns null > when the field is neither stored nor indexed, even if it has doc values. > An option to fix it could be to use the ValueSource instead to resolve the > Object value (similarily to NumericFacets). -- 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] (LUCENE-6744) equals methods should compare classes directly, not use instanceof
[
https://issues.apache.org/jira/browse/LUCENE-6744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947564#comment-14947564
]
Scott Stults commented on LUCENE-6744:
--
Java 7 is the documented minimum language level for Solr, so I think it's okay
to use the Objects class for its static equals(Object a, Object b) method.
(While we're at it we might even consider using its hash(Object...) function.)
That would make ConstValueSource.equals look something like this:
{code}
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
ConstValueSource that = (ConstValueSource) o;
return Objects.equals(constant, that.constant) &&
Objects.equals(dv, that.dv);
}
{code}
Moreover, if we want to jump into Objects usage with both feet we can change
hashCode to this:
{code}
@Override
public int hashCode() {
return Objects.hash(constant, dv);
}
{code}
> equals methods should compare classes directly, not use instanceof
> --
>
> Key: LUCENE-6744
> URL: https://issues.apache.org/jira/browse/LUCENE-6744
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Hoss Man
> Labels: newdev
>
> from a 2015-07-12 email to the dev list from Fuxiang Chen...
> {noformat}
> We have found some inconsistencies in the overriding of the equals() method
> in some files with respect to the conforming to the contract structure
> based on the Java Specification.
> Affected files:
> 1) ConstValueSource.java
> 2) DoubleConstValueSource.java
> 3) FixedBitSet.java
> 4) GeohashFunction.java
> 5) LongBitSet.java
> 6) SpanNearQuery.java
> 7) StringDistanceFunction.java
> 8) ValueSourceRangeFilter.java
> 9) VectorDistanceFunction.java
> The above files all uses instanceof in the overridden equals() method in
> comparing two objects.
> According to the Java Specification, the equals() method must be reflexive,
> symmetric, transitive and consistent. In the case of symmetric, it is
> stated that x.equals(y) should return true if and only if y.equals(x)
> returns true. Using instanceof is asymmetric and is not a valid symmetric
> contract.
> A more preferred way will be to compare the classes instead. i.e. if
> (this.getClass() != o.getClass()).
> However, if compiling the source code using JDK 7 and above, and if
> developers still prefer to use instanceof, you can make use of the static
> methods of Objects such as Objects.equals(this.id, that.id). (Making use of
> the static methods of Objects is currently absent in the methods.) It will
> be easier to override the equals() method and will ensure that the
> overridden equals() method will fulfill the contract rules.
> {noformat}
--
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] (LUCENE-2287) Unexpected terms are highlighted within nested SpanQuery instances
[
https://issues.apache.org/jira/browse/LUCENE-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947362#comment-14947362
]
Scott Stults commented on LUCENE-2287:
--
Thanks Shawn and David. FYI the tests in LUCENE-5455 are actually a superset of
the tests attached here and they fail appropriately on 5x. I'll stay tuned!
> Unexpected terms are highlighted within nested SpanQuery instances
> --
>
> Key: LUCENE-2287
> URL: https://issues.apache.org/jira/browse/LUCENE-2287
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/highlighter
>Affects Versions: 2.9.1
> Environment: Linux, Solaris, Windows
>Reporter: Michael Goddard
>Priority: Minor
> Attachments: LUCENE-2287.patch, LUCENE-2287.patch, LUCENE-2287.patch,
> LUCENE-2287.patch, LUCENE-2287.patch, LUCENE-2287.patch
>
> Original Estimate: 336h
> Remaining Estimate: 336h
>
> I haven't yet been able to resolve why I'm seeing spurious highlighting in
> nested SpanQuery instances. Briefly, the issue is illustrated by the second
> instance of "Lucene" being highlighted in the test below, when it doesn't
> satisfy the inner span. There's been some discussion about this on the
> java-dev list, and I'm opening this issue now because I have made some
> initial progress on this.
> This new test, added to the HighlighterTest class in lucene_2_9_1,
> illustrates this:
> /*
> * Ref: http://www.lucidimagination.com/blog/2009/07/18/the-spanquery/
> */
> public void testHighlightingNestedSpans2() throws Exception {
> String theText = "The Lucene was made by Doug Cutting and Lucene great
> Hadoop was"; // Problem
> //String theText = "The Lucene was made by Doug Cutting and the great
> Hadoop was"; // Works okay
> String fieldName = "SOME_FIELD_NAME";
> SpanNearQuery spanNear = new SpanNearQuery(new SpanQuery[] {
> new SpanTermQuery(new Term(fieldName, "lucene")),
> new SpanTermQuery(new Term(fieldName, "doug")) }, 5, true);
> Query query = new SpanNearQuery(new SpanQuery[] { spanNear,
> new SpanTermQuery(new Term(fieldName, "hadoop")) }, 4, true);
> String expected = "The Lucene was made by Doug Cutting and
> Lucene great Hadoop was";
> //String expected = "The Lucene was made by Doug Cutting and
> the great Hadoop was";
> String observed = highlightField(query, fieldName, theText);
> System.out.println("Expected: \"" + expected + "\n" + "Observed: \"" +
> observed);
> assertEquals("Why is that second instance of the term \"Lucene\"
> highlighted?", expected, observed);
> }
> Is this an issue that's arisen before? I've been reading through the source
> to QueryScorer, WeightedSpanTerm, WeightedSpanTermExtractor, Spans, and
> NearSpansOrdered, but haven't found the solution yet. Initially, I thought
> that the extractWeightedSpanTerms method in WeightedSpanTermExtractor should
> be called on each clause of a SpanNearQuery or SpanOrQuery, but that didn't
> get me too far.
--
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] (LUCENE-2287) Unexpected terms are highlighted within nested SpanQuery instances
[
https://issues.apache.org/jira/browse/LUCENE-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947050#comment-14947050
]
Scott Stults commented on LUCENE-2287:
--
LUCENE-5455 has a few tests that should be added here once this patch is
cleaned up.
There are a few hurdles in cleaning this up though. The first is that this
patch was based on a *really* old version and I can't seem to find anything in
SVN or git older than 3.1. The second is that Spans are quite a bit different.
By the way, I've tried the unit tests in both issues and they still fail in
5.3+. The issue seems to be in
WeightedSpanTermExtractor.extractWeightedSpanTerms(). It first builds a list of
all position spans, and then it adds all of those position spans to a map of
the term irrespective of whether that term was used in that position span.
Mike's patch addresses this by keeping a separate list of position spans per
term.
The thing that's *not* fixed by the patch is the notion of when to stop
recursing into the spans. I tried several methods of inspecting and classifying
the spans but I either end up with too many positions (resulting in too many
term highlights) or too few.
[~ romseygeek], why is this so hard? Can't we just use the same methods the
searcher uses? Maybe create a new collector and re-search the incoming doc?
> Unexpected terms are highlighted within nested SpanQuery instances
> --
>
> Key: LUCENE-2287
> URL: https://issues.apache.org/jira/browse/LUCENE-2287
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/highlighter
>Affects Versions: 2.9.1
> Environment: Linux, Solaris, Windows
>Reporter: Michael Goddard
>Priority: Minor
> Attachments: LUCENE-2287.patch, LUCENE-2287.patch, LUCENE-2287.patch,
> LUCENE-2287.patch, LUCENE-2287.patch, LUCENE-2287.patch
>
> Original Estimate: 336h
> Remaining Estimate: 336h
>
> I haven't yet been able to resolve why I'm seeing spurious highlighting in
> nested SpanQuery instances. Briefly, the issue is illustrated by the second
> instance of "Lucene" being highlighted in the test below, when it doesn't
> satisfy the inner span. There's been some discussion about this on the
> java-dev list, and I'm opening this issue now because I have made some
> initial progress on this.
> This new test, added to the HighlighterTest class in lucene_2_9_1,
> illustrates this:
> /*
> * Ref: http://www.lucidimagination.com/blog/2009/07/18/the-spanquery/
> */
> public void testHighlightingNestedSpans2() throws Exception {
> String theText = "The Lucene was made by Doug Cutting and Lucene great
> Hadoop was"; // Problem
> //String theText = "The Lucene was made by Doug Cutting and the great
> Hadoop was"; // Works okay
> String fieldName = "SOME_FIELD_NAME";
> SpanNearQuery spanNear = new SpanNearQuery(new SpanQuery[] {
> new SpanTermQuery(new Term(fieldName, "lucene")),
> new SpanTermQuery(new Term(fieldName, "doug")) }, 5, true);
> Query query = new SpanNearQuery(new SpanQuery[] { spanNear,
> new SpanTermQuery(new Term(fieldName, "hadoop")) }, 4, true);
> String expected = "The Lucene was made by Doug Cutting and
> Lucene great Hadoop was";
> //String expected = "The Lucene was made by Doug Cutting and
> the great Hadoop was";
> String observed = highlightField(query, fieldName, theText);
> System.out.println("Expected: \"" + expected + "\n" + "Observed: \"" +
> observed);
> assertEquals("Why is that second instance of the term \"Lucene\"
> highlighted?", expected, observed);
> }
> Is this an issue that's arisen before? I've been reading through the source
> to QueryScorer, WeightedSpanTerm, WeightedSpanTermExtractor, Spans, and
> NearSpansOrdered, but haven't found the solution yet. Initially, I thought
> that the extractWeightedSpanTerms method in WeightedSpanTermExtractor should
> be called on each clause of a SpanNearQuery or SpanOrQuery, but that didn't
> get me too far.
--
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] [Comment Edited] (LUCENE-2287) Unexpected terms are highlighted within nested SpanQuery instances
[
https://issues.apache.org/jira/browse/LUCENE-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947050#comment-14947050
]
Scott Stults edited comment on LUCENE-2287 at 10/7/15 3:40 PM:
---
LUCENE-5455 has a few tests that should be added here once this patch is
cleaned up.
There are a few hurdles in cleaning this up though. The first is that this
patch was based on a *really* old version and I can't seem to find anything in
SVN or git older than 3.1. The second is that Spans are quite a bit different.
By the way, I've tried the unit tests in both issues and they still fail in
5.3+. The issue seems to be in
WeightedSpanTermExtractor.extractWeightedSpanTerms(). It first builds a list of
all position spans, and then it adds all of those position spans to a map of
the term irrespective of whether that term was used in that position span.
Mike's patch addresses this by keeping a separate list of position spans per
term.
The thing that's *not* fixed by the patch is the notion of when to stop
recursing into the spans. I tried several methods of inspecting and classifying
the spans but I either end up with too many positions (resulting in too many
term highlights) or too few.
[~romseygeek], why is this so hard? Can't we just use the same methods the
searcher uses? Maybe create a new collector and re-search the incoming doc?
was (Author: sstults):
LUCENE-5455 has a few tests that should be added here once this patch is
cleaned up.
There are a few hurdles in cleaning this up though. The first is that this
patch was based on a *really* old version and I can't seem to find anything in
SVN or git older than 3.1. The second is that Spans are quite a bit different.
By the way, I've tried the unit tests in both issues and they still fail in
5.3+. The issue seems to be in
WeightedSpanTermExtractor.extractWeightedSpanTerms(). It first builds a list of
all position spans, and then it adds all of those position spans to a map of
the term irrespective of whether that term was used in that position span.
Mike's patch addresses this by keeping a separate list of position spans per
term.
The thing that's *not* fixed by the patch is the notion of when to stop
recursing into the spans. I tried several methods of inspecting and classifying
the spans but I either end up with too many positions (resulting in too many
term highlights) or too few.
[~ romseygeek], why is this so hard? Can't we just use the same methods the
searcher uses? Maybe create a new collector and re-search the incoming doc?
> Unexpected terms are highlighted within nested SpanQuery instances
> --
>
> Key: LUCENE-2287
> URL: https://issues.apache.org/jira/browse/LUCENE-2287
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/highlighter
>Affects Versions: 2.9.1
> Environment: Linux, Solaris, Windows
>Reporter: Michael Goddard
>Priority: Minor
> Attachments: LUCENE-2287.patch, LUCENE-2287.patch, LUCENE-2287.patch,
> LUCENE-2287.patch, LUCENE-2287.patch, LUCENE-2287.patch
>
> Original Estimate: 336h
> Remaining Estimate: 336h
>
> I haven't yet been able to resolve why I'm seeing spurious highlighting in
> nested SpanQuery instances. Briefly, the issue is illustrated by the second
> instance of "Lucene" being highlighted in the test below, when it doesn't
> satisfy the inner span. There's been some discussion about this on the
> java-dev list, and I'm opening this issue now because I have made some
> initial progress on this.
> This new test, added to the HighlighterTest class in lucene_2_9_1,
> illustrates this:
> /*
> * Ref: http://www.lucidimagination.com/blog/2009/07/18/the-spanquery/
> */
> public void testHighlightingNestedSpans2() throws Exception {
> String theText = "The Lucene was made by Doug Cutting and Lucene great
> Hadoop was"; // Problem
> //String theText = "The Lucene was made by Doug Cutting and the great
> Hadoop was"; // Works okay
> String fieldName = "SOME_FIELD_NAME";
> SpanNearQuery spanNear = new SpanNearQuery(new SpanQuery[] {
> new SpanTermQuery(new Term(fieldName, "lucene")),
> new SpanTermQuery(new Term(fieldName, "doug")) }, 5, true);
> Query query = new SpanNearQuery(new SpanQuery[] { spanNear,
> new SpanTermQuery(new Term(fieldName, "hadoop")) }, 4, true);
> String expected = "The Lucene was made by Doug Cutting and
> Lucene great Hadoop was";
> //String expected = "The Lucene was made by Doug Cutting and
> the great Hadoop was";
> String observed = highlightField(query, fieldName, theText);
> System.out.println("Expected: \"" + expected + "\n" + "Observed: \"" +
> observed);
> assertEquals("Why is that second instance of the term \"Lucene\"
>
[jira] [Commented] (LUCENE-5455) Nested SpanNear queries lose positional highlights
[ https://issues.apache.org/jira/browse/LUCENE-5455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946983#comment-14946983 ] Scott Stults commented on LUCENE-5455: -- This is a duplicate of LUCENE-2287, but the added detail of the tests is valuable and describes the problem cases in more detail than the original issue. > Nested SpanNear queries lose positional highlights > -- > > Key: LUCENE-5455 > URL: https://issues.apache.org/jira/browse/LUCENE-5455 > Project: Lucene - Core > Issue Type: Bug > Components: modules/highlighter >Affects Versions: 4.3.1, 4.6.1 >Reporter: Steve Davids > Fix For: 4.9, Trunk > > Attachments: LUCENE-5455-Tests.patch > > > Given text of: "x y z x z x a" > With a query of: spanNear([spanNear([text:x, text:y, text:z], 0, true), > text:a], 10, false) > Resulting highlight: x y z x z x > a > Expected highlight: x y z x z x a > This is caused because WeightedSpanTermExtractor.extractWeightedSpanTerms > takes the SpanQuery and flattens all terms and uses the positions from the > outermost SpanNear clause (ignoring the nested SpanNear positions). I believe > this could be resolved with a little recursion - walking the span query tree > in the extractWeightedSpanTerms method. -- 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] (LUCENE-2508) Consolidate Highlighter implementations and a major refactor of the non-termvector highlighter
[ https://issues.apache.org/jira/browse/LUCENE-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13937464#comment-13937464 ] Scott Stults commented on LUCENE-2508: -- This is great! IIRC, one of the todo's in the FVH was to properly integrate it with the existing highlighter. One thing I'm wondering is whether this should be expanded to take in the postings highlighter, or make that integration a follow-on issue. (For one minor example, DefaultPassageFormatter has an HTML escape function that can be shared.) > Consolidate Highlighter implementations and a major refactor of the > non-termvector highlighter > -- > > Key: LUCENE-2508 > URL: https://issues.apache.org/jira/browse/LUCENE-2508 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/highlighter > Environment: irrelevant >Reporter: Edward Drapkin >Priority: Minor > Labels: highlight, search > Fix For: 4.8 > > Attachments: LUCENE-2508.patch > > Original Estimate: 336h > Remaining Estimate: 336h > > Originally, I had planned to create a contrib module to allow people to > highlight multiple documents in parallel, but after talking to Uwe in IRC > about it, I realized that it was pretty useless. However, I was already > sitting on an iterative highlighting algorithm that was much faster (my tests > show 20% - 40%) and more accurate and, based on that same IRC conversation, I > decided to not let all the work that I had done go to waste and try to > contribute it back again. Uwe had mentioned that "More like this" detected > term vectors when called and use the term vector implementation when > possible, if I recall correctly, so I decided to do that. > The patch that I've attached is my first stab at this. It's not nearly > complete and full disclosure dictates that I say that it's not fully > documented and there are not any unit tests written. I wanted to go ahead > and open an issue to get some feedback on the approach that I've taken as > well as the fact that it exists will be a proverbial kick in my pants to > continue working on it. > In short, what I've changed: > * Completely rewritten the non-tv highlighter to be faster and cleaner. > There is some small loss in functionality for now, namely the loss of the > GradientHighlighter (I just haven't done this yet) and the lack of exposure > of TermFragments and their scores (I can expose this if it is deemed > necessary, this is one of the things I'd like feedback on). > * Moved org.apache.lucene.search.vectorhighlight and > org.apache.lucene.search.highlight to a single package with a unified > interface, search.highlight (with two sub-packages: > search.highlight.termvector and search.highlight.iterative, respectively). > * Unified the highlighted term formatting into a single interface: > highlighter/Formatter and both highlighters use this now. > What I need to do before I personally would consider this finished: > * Finish documentation, most specifically on TermVectorHighlighter. I > haven't done this now as I expect things to change up quite a bit before > they're finalized and I really hate writing documentation that goes to waste, > but I do intend to complete this bullet :) > * "Flesh out" the API of search.highlight.Highlighter as it's very barebones > right now > * Continue removing and consolidating duplicate functionality, like I've done > with the highlighted word tag generation. > What I think I need feedback on, before I can proceed: > * FastTermVectorHighlighter and the iterative highlighters need completely > different sets of information in order to work. The approach I've taken is > exposing a vectorHighlight method in the unified interface and a > iterativeHighlight method, as well as a single highlight method that takes > all the information needed for either of them and I'm unsure if this is the > best way to do this. > * The naming of things; I'm not sure if this is a big issue, or even an issue > at all, but I'd like to not break any conventions that may exist that I'm > unaware of. > * How big of a deal is exposing the particular score of a segment from the > highlighting interface and does this need to be extended into the term vector > highlighting as well? > * There are a lot of methods in the tv implementation that are marked > depracted; since this release will almost definitely break backwards > compatibility anyway, are these safe to remove? > * Any other input anyone else may have :) > I'm going to continue to work on things that I can work on, at least unless > someone tells me I'm wasting my time and will look forward to hearing you > guys' feedback! :) > As a sidenote because it does
[jira] [Commented] (SOLR-1726) Deep Paging and Large Results Improvements
[ https://issues.apache.org/jira/browse/SOLR-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791495#comment-13791495 ] Scott Stults commented on SOLR-1726: Dmitry, I think "scrolling" would help in the case of Hadoop integration, such as pulling a few hundred thousand docs based off of a query to the local node so that you can do an aggregated calculation with Pig or M/R. > Deep Paging and Large Results Improvements > -- > > Key: SOLR-1726 > URL: https://issues.apache.org/jira/browse/SOLR-1726 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 4.6 > > Attachments: CommonParams.java, QParser.java, QueryComponent.java, > ResponseBuilder.java, SOLR-1726.patch, SOLR-1726.patch, > SolrIndexSearcher.java, TopDocsCollector.java, TopScoreDocCollector.java > > > There are possibly ways to improve collections of "deep paging" by passing > Solr/Lucene more information about the last page of results seen, thereby > saving priority queue operations. See LUCENE-2215. > There may also be better options for retrieving large numbers of rows at a > time that are worth exploring. LUCENE-2127. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3159) Upgrade to Jetty 8
[ https://issues.apache.org/jira/browse/SOLR-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13567049#comment-13567049 ] Scott Stults commented on SOLR-3159: It looks like the SolrJetty wiki page needs some love. Should that be tracked here or in a separate issue? > Upgrade to Jetty 8 > -- > > Key: SOLR-3159 > URL: https://issues.apache.org/jira/browse/SOLR-3159 > Project: Solr > Issue Type: Task >Reporter: Ryan McKinley >Assignee: Ryan McKinley >Priority: Minor > Fix For: 4.0-ALPHA > > Attachments: SOLR-3159-maven.patch > > > Solr is currently tested (and bundled) with a patched jetty-6 version. > Ideally we can release and test with a standard version. > Jetty-6 (at codehaus) is just maintenance now. New development and > improvements are now hosted at eclipse. Assuming performance is equivalent, > I think we should switch to Jetty 8. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
[jira] [Updated] (SOLR-3825) Log document IDs when they are retrieved
[ https://issues.apache.org/jira/browse/SOLR-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Stults updated SOLR-3825: --- Attachment: SOLR-3825.1.patch This patch goes on after the previous one to change the raw docIDs to the unique ID defined in the schema > Log document IDs when they are retrieved > > > Key: SOLR-3825 > URL: https://issues.apache.org/jira/browse/SOLR-3825 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Reporter: Scott Stults >Assignee: Grant Ingersoll >Priority: Trivial > Attachments: SOLR-3825.1.patch, SOLR-3825.patch > > > During relevancy tuning it's important to know exactly which documents the > client has seen. Right now the only way to get that list is to splice into > the HTTP traffic. Preferably the IDs could be logged along with the query. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
[jira] [Commented] (SOLR-3825) Log document IDs when they are retrieved
[ https://issues.apache.org/jira/browse/SOLR-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453652#comment-13453652 ] Scott Stults commented on SOLR-3825: I updated the patch to incorporate these. > Log document IDs when they are retrieved > > > Key: SOLR-3825 > URL: https://issues.apache.org/jira/browse/SOLR-3825 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Reporter: Scott Stults >Assignee: Grant Ingersoll >Priority: Trivial > Attachments: SOLR-3825.patch > > > During relevancy tuning it's important to know exactly which documents the > client has seen. Right now the only way to get that list is to splice into > the HTTP traffic. Preferably the IDs could be logged along with the query. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
[jira] [Updated] (SOLR-3825) Log document IDs when they are retrieved
[ https://issues.apache.org/jira/browse/SOLR-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Stults updated SOLR-3825: --- Attachment: (was: SOLR-3825.patch) > Log document IDs when they are retrieved > > > Key: SOLR-3825 > URL: https://issues.apache.org/jira/browse/SOLR-3825 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Reporter: Scott Stults >Assignee: Grant Ingersoll >Priority: Trivial > Attachments: SOLR-3825.patch > > > During relevancy tuning it's important to know exactly which documents the > client has seen. Right now the only way to get that list is to splice into > the HTTP traffic. Preferably the IDs could be logged along with the query. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
[jira] [Updated] (SOLR-3825) Log document IDs when they are retrieved
[ https://issues.apache.org/jira/browse/SOLR-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Stults updated SOLR-3825: --- Attachment: SOLR-3825.patch > Log document IDs when they are retrieved > > > Key: SOLR-3825 > URL: https://issues.apache.org/jira/browse/SOLR-3825 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Reporter: Scott Stults >Assignee: Grant Ingersoll >Priority: Trivial > Attachments: SOLR-3825.patch > > > During relevancy tuning it's important to know exactly which documents the > client has seen. Right now the only way to get that list is to splice into > the HTTP traffic. Preferably the IDs could be logged along with the query. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
[jira] [Updated] (SOLR-3825) Log document IDs when they are retrieved
[ https://issues.apache.org/jira/browse/SOLR-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Stults updated SOLR-3825: --- Attachment: SOLR-3825.patch > Log document IDs when they are retrieved > > > Key: SOLR-3825 > URL: https://issues.apache.org/jira/browse/SOLR-3825 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Reporter: Scott Stults >Priority: Trivial > Attachments: SOLR-3825.patch > > > During relevancy tuning it's important to know exactly which documents the > client has seen. Right now the only way to get that list is to splice into > the HTTP traffic. Preferably the IDs could be logged along with the query. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
[jira] [Created] (SOLR-3825) Log document IDs when they are retrieved
Scott Stults created SOLR-3825: -- Summary: Log document IDs when they are retrieved Key: SOLR-3825 URL: https://issues.apache.org/jira/browse/SOLR-3825 Project: Solr Issue Type: Improvement Components: SearchComponents - other Reporter: Scott Stults Priority: Trivial During relevancy tuning it's important to know exactly which documents the client has seen. Right now the only way to get that list is to splice into the HTTP traffic. Preferably the IDs could be logged along with the query. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
[jira] [Updated] (LUCENE-4351) Upgrade Spatial4j to 0.3
[ https://issues.apache.org/jira/browse/LUCENE-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Stults updated LUCENE-4351: - Attachment: LUCENE-4351_Spatial4j_0_3.patch Updated the Eclipse classpath entry > Upgrade Spatial4j to 0.3 > > > Key: LUCENE-4351 > URL: https://issues.apache.org/jira/browse/LUCENE-4351 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial >Reporter: David Smiley >Assignee: David Smiley > Fix For: 4.0 > > Attachments: LUCENE-4351_Spatial4j_0_3.patch, > LUCENE-4351_Spatial4j_0_3.patch > > > This version of Spatial4j has various API level improvements. It features > dateline wrap for polygons. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
