[jira] [Commented] (SOLR-5972) new statistics facet capabilities to StatsComponent facet - limit, sort and missing.
[ https://issues.apache.org/jira/browse/SOLR-5972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303217#comment-14303217 ] Elran Dvir commented on SOLR-5972: -- Hi all, This patch contains a new statistics result for a field - existInDoc. It returns the number of documents in which the field has a value (not missing). For multivalue fields there is a calculation of existInDoc inside the class UnInvertedField. Since Solr 4.10 there was a fix for a stats calculation of multi valued field which is doc valued. The class handling it is DocValuesStats. I want to support existInDoc calculation also for multi valued - doc valued field. How Should I change DocValuesStats to support this? Thanks. new statistics facet capabilities to StatsComponent facet - limit, sort and missing. Key: SOLR-5972 URL: https://issues.apache.org/jira/browse/SOLR-5972 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: SOLR-5972.patch, SOLR-5972.patch I thought it would be very useful to enable limiting and sorting StatsComponent facet response. I chose to implement it in Stats Component rather than Analytics component because Analytics doesn't support distributed queries yet. The default for limit is -1 - returns all facet values. The default for sort is no sorting. The default for missing is true. So if you use stats component exactly as before, the response won't change as of nowadays. If ask for sort or limit, missing facet value will be the last, as in regular facet. Sort types supported: min, max, sum and countdistinct for stats fields, and count and index for facet fields (all sort types are lower cased). Sort directions asc and desc are supported. Sorting by multiple fields is supported. our example use case will be employees' monthly salaries: The follwing query returns the 10 most expensive employees: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary sum descf.employee_name.stats.facet.limit=10 The follwing query returns the 10 least expensive employees: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary sum ascf.employee_name.stats.facet.limit=10 The follwing query returns the employee that got the highest salary ever: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary max descf.employee_name.stats.facet.limit=1 The follwing query returns the employee that got the lowest salary ever: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary min ascf.employee_name.stats.facet.limit=1 The follwing query returns the 10 first (lexicographically) employees: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=employee_name index ascf.employee_name.stats.facet.limit=10 The follwing query returns the 10 employees that have worked for the longest period: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=employee_name count descf.employee_name.stats.facet.limit=10 The follwing query returns the 10 employee whose salaries vary the most: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary countdistinct descf.employee_name.stats.facet.limit=10 Attached a patch implementing this in StatsComponent. -- 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-1782) stats.facet assumes FieldCache.StringIndex - fails horribly on multivalued fields
[
https://issues.apache.org/jira/browse/SOLR-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14267497#comment-14267497
]
Elran Dvir commented on SOLR-1782:
--
Hi Patanachai,
I am using your patch for stats.facet for multivalue fields above Solr 4.8.
It works perfectly for most cases.
I found a case in which it doesn't work. When the field we facet on is a
numeric field but is not multivalue.
The code fails on:
if (topLevelSortedValues == null) {
topLevelSortedValues = FieldCache.DEFAULT.getTermsIndex(topLevelReader,
name);
and this the exception I get:
(SolrException.java:120) - null:java.lang.IllegalStateException: Type
mismatch:time was indexed as NUMERIC
at
org.apache.lucene.search.FieldCacheImpl.getTermsIndex(FieldCacheImpl.java:1161)
at
org.apache.lucene.search.FieldCacheImpl.getTermsIndex(FieldCacheImpl.java:1145)
at
org.apache.solr.handler.component.FieldFacetStats.facetTermNum(FieldFacetStats.java:152)
at
org.apache.solr.request.UnInvertedField.getStats(UnInvertedField.java:587)
at
org.apache.solr.handler.component.SimpleStats.getStatsFields(StatsComponent.java:514)
at
org.apache.solr.handler.component.StatsComponent.process(StatsComponent.java:64)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1953)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:774)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
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:1086)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
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.HandlerCollection.handle(HandlerCollection.java:154)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:370)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:960)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1021)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
at
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at org.eclipse.jetty.io.nio.SslConnection.handle(SslConnection.java:196)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:804)
So which field cache should I be using for numeric field?
Thanks.
stats.facet assumes FieldCache.StringIndex - fails horribly on multivalued
fields
-
Key: SOLR-1782
URL: https://issues.apache.org/jira/browse/SOLR-1782
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.4
Environment: reproduced on Win2k3 using 1.5.0-dev solr ($Id:
CHANGES.txt 906924 2010-02-05 12:43:11Z noble $)
Reporter: Gerald DeConto
Assignee: Hoss Man
Attachments: SOLR-1782.2.patch, SOLR-1782.2013-01-07.patch,
SOLR-1782.2013-04-10.patch,
[jira] [Created] (SOLR-6921) Stats.field fails on multivalue fields which are doc valued
Elran Dvir created SOLR-6921: Summary: Stats.field fails on multivalue fields which are doc valued Key: SOLR-6921 URL: https://issues.apache.org/jira/browse/SOLR-6921 Project: Solr Issue Type: Bug Affects Versions: 4.8 Reporter: Elran Dvir I am using stats.field on a field with the following definition in schema: field name=myField type=string indexed=true stored=false multiValued=true docValues=true/ I get the following exception: org.apache.solr.common.SolrException: Type mismatch: myField was indexed as SORTED_SET at org.apache.solr.request.UnInvertedField.init(UnInvertedField.java:193) at org.apache.solr.request.UnInvertedField.getUnInvertedField(UnInvertedField.java:703) at org.apache.solr.handler.component.SimpleStats.getStatsFields(StatsComponent.java:513) at org.apache.solr.handler.component.StatsComponent.process(StatsComponent.java:64) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1953) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:774) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) 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:1086) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) 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.HandlerCollection.handle(HandlerCollection.java:154) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:960) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1021) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240) at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) at org.eclipse.jetty.io.nio.SslConnection.handle(SslConnection.java:196) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:804) -- 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-6024) StatsComponent does not work for docValues enabled multiValued fields
[
https://issues.apache.org/jira/browse/SOLR-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14267630#comment-14267630
]
Elran Dvir commented on SOLR-6024:
--
Hi All,
I am trying to apply this patch on Solr 4.8.
I have compilation problems with the class DocValuesStats.
I get the following errors:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on
project solr-core: Compilation failure: Compilation failure:
[ERROR]
/D:/ckp/src/solr_4.8/solr/core/src/java/org/apache/solr/request/DocValuesStats.java:[88,21]
cannot find symbol
[ERROR] symbol: method emptySortedSet()
[ERROR] location: class org.apache.lucene.index.DocValues
[ERROR]
/D:/ckp/src/solr_4.8/solr/core/src/java/org/apache/solr/request/DocValuesStats.java:[116,28]
cannot find symbol
[ERROR] symbol: method emptySortedSet()
[ERROR] location: class org.apache.lucene.index.DocValues
[ERROR]
/D:/ckp/src/solr_4.8/solr/core/src/java/org/apache/solr/request/DocValuesStats.java:[128,28]
cannot find symbol
[ERROR] symbol: method emptySorted()
[ERROR] location: class org.apache.lucene.index.DocValues
[ERROR]
/D:/ckp/src/solr_4.8/solr/core/src/java/org/apache/solr/request/DocValuesStats.java:[139,34]
method lookupOrd in class org.apache.lucene.index.SortedSetDocValues cannot be
applied to given types;
[ERROR] required: long,org.apache.lucene.util.BytesRef
[ERROR] found: int
[ERROR] reason: actual and formal argument lists differ in length
[ERROR]
/D:/ckp/src/solr_4.8/solr/core/src/java/org/apache/solr/request/DocValuesStats.java:[165,55]
cannot find symbol
[ERROR] symbol: method getGlobalOrds(int)
[ERROR] location: variable map of type
org.apache.lucene.index.MultiDocValues.OrdinalMap
[ERROR]
/D:/ckp/src/solr_4.8/solr/core/src/java/org/apache/solr/request/DocValuesStats.java:[183,55]
cannot find symbol
[ERROR] symbol: method getGlobalOrds(int)
[ERROR] location: variable map of type
org.apache.lucene.index.MultiDocValues.OrdinalMap
I guess these methods are implemented in newer versions of Solr/lucene.
How can I fix it in 4.8?
What is the oldest version the patch can be applied to?
Thank you very much.
StatsComponent does not work for docValues enabled multiValued fields
-
Key: SOLR-6024
URL: https://issues.apache.org/jira/browse/SOLR-6024
Project: Solr
Issue Type: Bug
Components: SearchComponents - other
Affects Versions: 4.8
Environment: java version 1.7.0_45
Mac OS X Version 10.7.5
Reporter: Ahmet Arslan
Assignee: Tomás Fernández Löbbe
Labels: StatsComponent, docValues, multiValued
Fix For: 4.10.1, 5.0, Trunk
Attachments: SOLR-6024-branch_4x.patch, SOLR-6024-trunk.patch,
SOLR-6024-trunk.patch, SOLR-6024-trunk.patch, SOLR-6024-trunk.patch,
SOLR-6024-trunk.patch, SOLR-6024.patch, SOLR-6024.patch
Harish Agarwal reported this in solr user mailing list :
http://search-lucene.com/m/QTPaoTJXV1
It is east to re-produce with default example solr setup. Following types are
added example schema.xml. And exampledocs are indexed.
{code:xml}
field name=cat type=string indexed=true stored=true
docValues=true multiValued=true/
field name=popularity type=int indexed=true stored=false
docValues=true multiValued=true/
{code}
When {{docValues=true}} *and* {{multiValued=true}} are used at the same
time, StatsComponent throws :
{noformat}
ERROR org.apache.solr.core.SolrCore – org.apache.solr.common.SolrException:
Type mismatch: popularity was indexed as SORTED_SET
at
org.apache.solr.request.UnInvertedField.init(UnInvertedField.java:193)
at
org.apache.solr.request.UnInvertedField.getUnInvertedField(UnInvertedField.java:699)
at
org.apache.solr.handler.component.SimpleStats.getStatsFields(StatsComponent.java:319)
at
org.apache.solr.handler.component.SimpleStats.getStatsCounts(StatsComponent.java:290)
at
org.apache.solr.handler.component.StatsComponent.process(StatsComponent.java:78)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:221)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1964)
{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] (SOLR-6921) Stats.field fails on multivalue fields which are doc valued
[ https://issues.apache.org/jira/browse/SOLR-6921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14267639#comment-14267639 ] Elran Dvir commented on SOLR-6921: -- Thank you very much. I tried to apply 6024 to Solr 4.8. I see few problems. please see my comment in 6024. Thanks again. Stats.field fails on multivalue fields which are doc valued --- Key: SOLR-6921 URL: https://issues.apache.org/jira/browse/SOLR-6921 Project: Solr Issue Type: Bug Affects Versions: 4.8 Reporter: Elran Dvir I am using stats.field on a field with the following definition in schema: field name=myField type=string indexed=true stored=false multiValued=true docValues=true/ I get the following exception: org.apache.solr.common.SolrException: Type mismatch: myField was indexed as SORTED_SET at org.apache.solr.request.UnInvertedField.init(UnInvertedField.java:193) at org.apache.solr.request.UnInvertedField.getUnInvertedField(UnInvertedField.java:703) at org.apache.solr.handler.component.SimpleStats.getStatsFields(StatsComponent.java:513) at org.apache.solr.handler.component.StatsComponent.process(StatsComponent.java:64) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1953) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:774) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) 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:1086) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) 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.HandlerCollection.handle(HandlerCollection.java:154) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:960) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1021) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240) at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) at org.eclipse.jetty.io.nio.SslConnection.handle(SslConnection.java:196) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:804) -- 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-6666) Dynamic copy fields are considering all dynamic fields, causing a significant performance impact on indexing documents
[
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elran Dvir updated SOLR-:
-
Attachment: SOLR-.patch
Dynamic copy fields are considering all dynamic fields, causing a significant
performance impact on indexing documents
--
Key: SOLR-
URL: https://issues.apache.org/jira/browse/SOLR-
Project: Solr
Issue Type: Improvement
Components: Schema and Analysis, update
Environment: Linux, Solr 4.8, Schema with 70 fields and more than 500
specific CopyFields for dynamic fields, but without wildcards (the fields are
dynamic, the copy directive is not)
Reporter: Liram Vardi
Assignee: Erick Erickson
Attachments: SOLR-.patch, SOLR-.patch
Result:
After applying a fix for this issue, tests which we conducted show more than
40 percent improvement on our insertion performance.
Explanation:
Using JVM profiler, we found a CPU bottleneck during Solr indexing process.
This bottleneck can be found at org.apache.solr.schema.IndexSchema, in the
following method, getCopyFieldsList():
{code:title=getCopyFieldsList() |borderStyle=solid}
final ListCopyField result = new ArrayList();
for (DynamicCopy dynamicCopy : dynamicCopyFields) {
if (dynamicCopy.matches(sourceField)) {
result.add(new CopyField(getField(sourceField),
dynamicCopy.getTargetField(sourceField), dynamicCopy.maxChars));
}
}
ListCopyField fixedCopyFields = copyFieldsMap.get(sourceField);
if (null != fixedCopyFields) {
result.addAll(fixedCopyFields);
}
{code}
This function tries to find for an input source field all its copyFields (All
its destinations which Solr need to move this field).
As you can probably note, the first part of the procedure is the procedure
most “expensive” step (takes O( n ) time while N is the size of the
dynamicCopyFields group).
The next part is just a simple hash extraction, which takes O(1) time.
Our schema contains over then 500 copyFields but only 70 of then are
indexed fields.
We also have one dynamic field with a wildcard ( * ), which catches the
rest of the document fields.
As you can conclude, we have more than 400 copyFields that are based on this
dynamicField but all, except one, are fixed (i.e. does not contain any
wildcard).
From some reason, the copyFields registration procedure defines those 400
fields as DynamicCopyField and then store them in the “dynamicCopyFields”
array,
This step makes getCopyFieldsList() very expensive (in CPU terms) without any
justification: All of those 400 copyFields are not glob and therefore do not
need any complex pattern matching to the input field. They all can be store
at the fixedCopyFields.
Only copyFields with asterisks need this special treatment and they are
(especially on our case) pretty rare.
Therefore, we created a patch which fix this problem by changing the
registerCopyField() procedure.
Test which we conducted show that there is no change in the Indexing results.
Moreover, the fix still successfully passes the class unit tests (i.e.
IndexSchemaTest.java).
--
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-6063) allow core reloading with parameters in core admin
[ https://issues.apache.org/jira/browse/SOLR-6063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14245914#comment-14245914 ] Elran Dvir commented on SOLR-6063: -- Hi all, I am attaching a new version of the patch. When a core is changed from non transient to transient, it has to be closed first. Otherwise, you will get the an exception like this: REFCOUNT ERROR: unreferenced org.apache.solr.core.SolrCore@f922b95 (your_core_name) has a reference count of 1. Thanks. allow core reloading with parameters in core admin --- Key: SOLR-6063 URL: https://issues.apache.org/jira/browse/SOLR-6063 Project: Solr Issue Type: Improvement Reporter: Elran Dvir Attachments: SOLR-6063.patch The patch allows to add parameters to core admin reload command as in create command and it changes the core configuration as indicated in the parameters. Any parameter that is not indicated in the command will be the same as before. For example, the command solr/admin/cores?action=RELOADcore=core0transient=true will change the core to be transient. In my patch, I removed the parameter isTransientCore from the method registerCore in class CoreContainer. I chose to use cd.isTransient() instead. The patch is based on Solr 4.8 Thanks. -- 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-6063) allow core reloading with parameters in core admin
[ https://issues.apache.org/jira/browse/SOLR-6063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-6063: - Attachment: SOLR-6063.patch allow core reloading with parameters in core admin --- Key: SOLR-6063 URL: https://issues.apache.org/jira/browse/SOLR-6063 Project: Solr Issue Type: Improvement Reporter: Elran Dvir Attachments: SOLR-6063.patch, SOLR-6063.patch The patch allows to add parameters to core admin reload command as in create command and it changes the core configuration as indicated in the parameters. Any parameter that is not indicated in the command will be the same as before. For example, the command solr/admin/cores?action=RELOADcore=core0transient=true will change the core to be transient. In my patch, I removed the parameter isTransientCore from the method registerCore in class CoreContainer. I chose to use cd.isTransient() instead. The patch is based on Solr 4.8 Thanks. -- 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-5846) EnumField docValues funtionality
[ https://issues.apache.org/jira/browse/SOLR-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5846: - Attachment: Solr-5846.patch EnumField docValues funtionality Key: SOLR-5846 URL: https://issues.apache.org/jira/browse/SOLR-5846 Project: Solr Issue Type: Improvement Reporter: Elran Dvir Assignee: Shalin Shekhar Mangar Attachments: SOLR-5846.patch, Solr-5846.patch, Solr-5846.patch I have added docValues functionality to EnumField. Please review the patch attached. If there is any problem with it, please let me know. -- 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-5846) EnumField docValues funtionality
[ https://issues.apache.org/jira/browse/SOLR-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14137042#comment-14137042 ] Elran Dvir commented on SOLR-5846: -- Thank you very much for your attention. Attaching new patch with test. I only added docValues=true in schema and rerun existing EnumFieldTest. All tests passed. Is it sufficient? Thanks. EnumField docValues funtionality Key: SOLR-5846 URL: https://issues.apache.org/jira/browse/SOLR-5846 Project: Solr Issue Type: Improvement Reporter: Elran Dvir Assignee: Shalin Shekhar Mangar Attachments: SOLR-5846.patch, Solr-5846.patch, Solr-5846.patch I have added docValues functionality to EnumField. Please review the patch attached. If there is any problem with it, please let me know. -- 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-5846) EnumField docValues funtionality
[ https://issues.apache.org/jira/browse/SOLR-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5846: - Attachment: Solr-5846.patch EnumField docValues funtionality Key: SOLR-5846 URL: https://issues.apache.org/jira/browse/SOLR-5846 Project: Solr Issue Type: Improvement Reporter: Elran Dvir Attachments: SOLR-5846.patch, Solr-5846.patch I have added docValues functionality to EnumField. Please review the patch attached. If there is any problem with it, please let me know. -- 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-5846) EnumField docValues funtionality
[ https://issues.apache.org/jira/browse/SOLR-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14133941#comment-14133941 ] Elran Dvir commented on SOLR-5846: -- Hi all, Did anyone have a chance to take a look at my code? Attached new patch with removal of checkSchemaField logic because since version 4.5 single-valued docvalues fields no longer require 'default' or 'required'. The patch is based on Solr 4.9 Thanks. EnumField docValues funtionality Key: SOLR-5846 URL: https://issues.apache.org/jira/browse/SOLR-5846 Project: Solr Issue Type: Improvement Reporter: Elran Dvir Attachments: SOLR-5846.patch, Solr-5846.patch I have added docValues functionality to EnumField. Please review the patch attached. If there is any problem with it, please let me know. -- 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-6063) allow core reloading with parameters in core admin
[ https://issues.apache.org/jira/browse/SOLR-6063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14133970#comment-14133970 ] Elran Dvir commented on SOLR-6063: -- Hi all, Did anyone have a chance to examine my patch? Thanks. allow core reloading with parameters in core admin --- Key: SOLR-6063 URL: https://issues.apache.org/jira/browse/SOLR-6063 Project: Solr Issue Type: Improvement Reporter: Elran Dvir Attachments: SOLR-6063.patch The patch allows to add parameters to core admin reload command as in create command and it changes the core configuration as indicated in the parameters. Any parameter that is not indicated in the command will be the same as before. For example, the command solr/admin/cores?action=RELOADcore=core0transient=true will change the core to be transient. In my patch, I removed the parameter isTransientCore from the method registerCore in class CoreContainer. I chose to use cd.isTransient() instead. The patch is based on Solr 4.8 Thanks. -- 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-5972) new statistics facet capabilities to StatsComponent facet - limit, sort and missing.
[ https://issues.apache.org/jira/browse/SOLR-5972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5972: - Attachment: SOLR-5972.patch new statistics facet capabilities to StatsComponent facet - limit, sort and missing. Key: SOLR-5972 URL: https://issues.apache.org/jira/browse/SOLR-5972 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: SOLR-5972.patch, SOLR-5972.patch I thought it would be very useful to enable limiting and sorting StatsComponent facet response. I chose to implement it in Stats Component rather than Analytics component because Analytics doesn't support distributed queries yet. The default for limit is -1 - returns all facet values. The default for sort is no sorting. The default for missing is true. So if you use stats component exactly as before, the response won't change as of nowadays. If ask for sort or limit, missing facet value will be the last, as in regular facet. Sort types supported: min, max, sum and countdistinct for stats fields, and count and index for facet fields (all sort types are lower cased). Sort directions asc and desc are supported. Sorting by multiple fields is supported. our example use case will be employees' monthly salaries: The follwing query returns the 10 most expensive employees: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary sum descf.employee_name.stats.facet.limit=10 The follwing query returns the 10 least expensive employees: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary sum ascf.employee_name.stats.facet.limit=10 The follwing query returns the employee that got the highest salary ever: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary max descf.employee_name.stats.facet.limit=1 The follwing query returns the employee that got the lowest salary ever: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary min ascf.employee_name.stats.facet.limit=1 The follwing query returns the 10 first (lexicographically) employees: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=employee_name index ascf.employee_name.stats.facet.limit=10 The follwing query returns the 10 employees that have worked for the longest period: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=employee_name count descf.employee_name.stats.facet.limit=10 The follwing query returns the 10 employee whose salaries vary the most: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary countdistinct descf.employee_name.stats.facet.limit=10 Attached a patch implementing this in StatsComponent. -- 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-5972) new statistics facet capabilities to StatsComponent facet - limit, sort and missing.
[ https://issues.apache.org/jira/browse/SOLR-5972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083916#comment-14083916 ] Elran Dvir commented on SOLR-5972: -- I attached a newer patch with fix of calculation of existInDoc for multivalue fields new statistics facet capabilities to StatsComponent facet - limit, sort and missing. Key: SOLR-5972 URL: https://issues.apache.org/jira/browse/SOLR-5972 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: SOLR-5972.patch, SOLR-5972.patch I thought it would be very useful to enable limiting and sorting StatsComponent facet response. I chose to implement it in Stats Component rather than Analytics component because Analytics doesn't support distributed queries yet. The default for limit is -1 - returns all facet values. The default for sort is no sorting. The default for missing is true. So if you use stats component exactly as before, the response won't change as of nowadays. If ask for sort or limit, missing facet value will be the last, as in regular facet. Sort types supported: min, max, sum and countdistinct for stats fields, and count and index for facet fields (all sort types are lower cased). Sort directions asc and desc are supported. Sorting by multiple fields is supported. our example use case will be employees' monthly salaries: The follwing query returns the 10 most expensive employees: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary sum descf.employee_name.stats.facet.limit=10 The follwing query returns the 10 least expensive employees: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary sum ascf.employee_name.stats.facet.limit=10 The follwing query returns the employee that got the highest salary ever: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary max descf.employee_name.stats.facet.limit=1 The follwing query returns the employee that got the lowest salary ever: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary min ascf.employee_name.stats.facet.limit=1 The follwing query returns the 10 first (lexicographically) employees: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=employee_name index ascf.employee_name.stats.facet.limit=10 The follwing query returns the 10 employees that have worked for the longest period: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=employee_name count descf.employee_name.stats.facet.limit=10 The follwing query returns the 10 employee whose salaries vary the most: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary countdistinct descf.employee_name.stats.facet.limit=10 Attached a patch implementing this in StatsComponent. -- 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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031792#comment-14031792 ] Elran Dvir commented on SOLR-2894: -- I think it's very important to keep pivot's response values as objects. We should consider changing facet's response values from string to object. In objects, there is , ofcourse, more information than strings. For example, there is no ability in Solr to sort by index desc. With objects it can be done in the client. Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.9, 5.0 Attachments: SOLR-2894-mincount-minification.patch, SOLR-2894-reworked.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894_cloud_test.patch, dateToObject.patch, pivot_mincount_problem.sh Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-6063) allow core reloading with parameters in core admin
[ https://issues.apache.org/jira/browse/SOLR-6063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-6063: - Description: The patch allows to add parameters to core admin reload command as in create command and it changes the core configuration as indicated in the parameters. Any parameter that is not indicated in the command will be the same as before. For example, the command solr/admin/cores?action=RELOADcore=core0transient=true will change the core to be transient. In my patch, I removed the parameter isTransientCore from the method registerCore in class CoreContainer. I chose to use cd.isTransient() instead. The patch is based on Solr 4.8 Thanks. was: The patch allows to add parameters to core admin reload command as in create command and it changes the core configuration as indicated in the parameters. Any parameter that is not indicated in the command will be the same as before. For example, the command solr/admin/cores?action=RELOADcore=core0transient=true will change the core to be transient. In my patch, I removed the parameter isTransientCore from the method registerCore in class CoreContainer. I chose to use cd.isTransient() instead. Thanks. allow core reloading with parameters in core admin --- Key: SOLR-6063 URL: https://issues.apache.org/jira/browse/SOLR-6063 Project: Solr Issue Type: Improvement Reporter: Elran Dvir Attachments: SOLR-6063.patch The patch allows to add parameters to core admin reload command as in create command and it changes the core configuration as indicated in the parameters. Any parameter that is not indicated in the command will be the same as before. For example, the command solr/admin/cores?action=RELOADcore=core0transient=true will change the core to be transient. In my patch, I removed the parameter isTransientCore from the method registerCore in class CoreContainer. I chose to use cd.isTransient() instead. The patch is based on Solr 4.8 Thanks. -- 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-6063) allow core reloading with parameters in core admin
Elran Dvir created SOLR-6063: Summary: allow core reloading with parameters in core admin Key: SOLR-6063 URL: https://issues.apache.org/jira/browse/SOLR-6063 Project: Solr Issue Type: Improvement Reporter: Elran Dvir The patch allows to add parameters to core admin reload command as in create command and it changes the core configuration as indicated in the parameters. Any parameter that is not indicated in the command will be the same as before. For example, the command solr/admin/cores?action=RELOADcore=core0transient=true will change the core to be transient. In my patch, I removed the parameter isTransientCore from the method registerCore in class CoreContainer. I chose to use cd.isTransient() instead. Thanks. -- 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-6063) allow core reloading with parameters in core admin
[ https://issues.apache.org/jira/browse/SOLR-6063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-6063: - Attachment: SOLR-6063.patch allow core reloading with parameters in core admin --- Key: SOLR-6063 URL: https://issues.apache.org/jira/browse/SOLR-6063 Project: Solr Issue Type: Improvement Reporter: Elran Dvir Attachments: SOLR-6063.patch The patch allows to add parameters to core admin reload command as in create command and it changes the core configuration as indicated in the parameters. Any parameter that is not indicated in the command will be the same as before. For example, the command solr/admin/cores?action=RELOADcore=core0transient=true will change the core to be transient. In my patch, I removed the parameter isTransientCore from the method registerCore in class CoreContainer. I chose to use cd.isTransient() instead. Thanks. -- 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-5514) atomic update throws exception if the schema contains uuid fields: Invalid UUID String: 'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'
[
https://issues.apache.org/jira/browse/SOLR-5514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13986445#comment-13986445
]
Elran Dvir commented on SOLR-5514:
--
Hi,
Did anyone have a chance to examine my patch?
Thanks.
atomic update throws exception if the schema contains uuid fields: Invalid
UUID String: 'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'
-
Key: SOLR-5514
URL: https://issues.apache.org/jira/browse/SOLR-5514
Project: Solr
Issue Type: Bug
Affects Versions: 4.5.1
Environment: unix and windows
Reporter: Dirk Reuss
Assignee: Shalin Shekhar Mangar
Attachments: SOLR-5514.patch
I am updating an exiting document with the statement
adddocfield name='name' update='set'newvalue/field
All fields are stored and I have several UUID fields. About 10-20% of the
update commands will fail with the message: (example)
Invalid UUID String: 'java.util.UUID:532c9353-d391-4a04-8618-dc2fa1ef8b35'
the point is that java.util.UUID seems to be prepended to the original uuid
stored in the field and when the value is written this error occours.
I tried to check if this specific uuid field was the problem and
added the uuid field in the update xml with(field name='id1'
update='set'...). But the error simply moved to an other uuid field.
here is the original exception:
lst name=responseHeaderint name=status500/intint
name=QTime34/int/lstlst name=errorstr name=msgError while
creating field
'MyUUIDField{type=uuid,properties=indexed,stored,omitTermFreqAndPositions,required,
required=true}' from value
'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'/strstr
name=traceorg.apache.solr.common.SolrException: Error while creating field
'MyUUIDField{type=uuid,properties=indexed,stored,omitTermFreqAndPositions,required,
required=true}' from value
'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'
at org.apache.solr.schema.FieldType.createField(FieldType.java:259)
at org.apache.solr.schema.StrField.createFields(StrField.java:56)
at
org.apache.solr.update.DocumentBuilder.addField(DocumentBuilder.java:47)
at
org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:118)
at
org.apache.solr.update.AddUpdateCommand.getLuceneDocument(AddUpdateCommand.java:77)
at
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:215)
at
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
at
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:556)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:692)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:435)
at
org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:100)
at
org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:247)
at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:174)
at
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
[jira] [Commented] (SOLR-5514) atomic update throws exception if the schema contains uuid fields: Invalid UUID String: 'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'
[
https://issues.apache.org/jira/browse/SOLR-5514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13986465#comment-13986465
]
Elran Dvir commented on SOLR-5514:
--
It happens in my real time environment all the time. After the fix, it seems it
stopped happening.
I tried to create a test case, but I couldn't reproduce the problem.
I think it happens when there is some time between updates, so the older
version of the document is fetched by a searcher and by Update Log.
I think the update shouldn't contain the uuid field. The uuid field comes from
the original document and is merged.
atomic update throws exception if the schema contains uuid fields: Invalid
UUID String: 'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'
-
Key: SOLR-5514
URL: https://issues.apache.org/jira/browse/SOLR-5514
Project: Solr
Issue Type: Bug
Affects Versions: 4.5.1
Environment: unix and windows
Reporter: Dirk Reuss
Assignee: Shalin Shekhar Mangar
Attachments: SOLR-5514.patch
I am updating an exiting document with the statement
adddocfield name='name' update='set'newvalue/field
All fields are stored and I have several UUID fields. About 10-20% of the
update commands will fail with the message: (example)
Invalid UUID String: 'java.util.UUID:532c9353-d391-4a04-8618-dc2fa1ef8b35'
the point is that java.util.UUID seems to be prepended to the original uuid
stored in the field and when the value is written this error occours.
I tried to check if this specific uuid field was the problem and
added the uuid field in the update xml with(field name='id1'
update='set'...). But the error simply moved to an other uuid field.
here is the original exception:
lst name=responseHeaderint name=status500/intint
name=QTime34/int/lstlst name=errorstr name=msgError while
creating field
'MyUUIDField{type=uuid,properties=indexed,stored,omitTermFreqAndPositions,required,
required=true}' from value
'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'/strstr
name=traceorg.apache.solr.common.SolrException: Error while creating field
'MyUUIDField{type=uuid,properties=indexed,stored,omitTermFreqAndPositions,required,
required=true}' from value
'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'
at org.apache.solr.schema.FieldType.createField(FieldType.java:259)
at org.apache.solr.schema.StrField.createFields(StrField.java:56)
at
org.apache.solr.update.DocumentBuilder.addField(DocumentBuilder.java:47)
at
org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:118)
at
org.apache.solr.update.AddUpdateCommand.getLuceneDocument(AddUpdateCommand.java:77)
at
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:215)
at
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
at
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:556)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:692)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:435)
at
org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:100)
at
org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:247)
at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:174)
at
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
[jira] [Commented] (SOLR-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13979420#comment-13979420 ] Elran Dvir commented on SOLR-2894: -- Brett, thanks for your response. Having a mincount of -1 for the shards is correct. The reason is that while a given shard may have a count lower than mincount for a given term, the aggregate total count for that value when combined with the other shards could exceed the mincount, so we do need to know about it. For example, consider a mincount of 10. If we have 3 shards with a count of 5 for a term of Boston, we would still need to know about these because the total count would be 15, and would be higher than the mincount. If mincount of 1 is asked for a field, couldn't it be more efficient? Is mincount of -1 necessary in this case? I would expect the skipRefinementAtThisLevel to be false for the top level pivot facet, and true for each other level. Are you seeing otherwise? No. You are right. If you were to set a facet.limit of 10 for all levels of the pivot, what is the memory usage like? The memory usage in this case is about 200 MB. Thanks again. Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.9, 5.0 Attachments: SOLR-2894-reworked.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, dateToObject.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13978002#comment-13978002 ] Elran Dvir commented on SOLR-2894: -- We have encountered a Java heap memory problem using distributed pivots – perhaps someone can shed some light on it. The scenario is as follows: We run Solr 4.4 (with patch for SOLR-2894) with 20 cores and the maximum java heap size is 1.5 GB. The following query with distributed facet pivot generates an out of memory exception: rows=0 q=*:* facet=true facet.pivot=f1,f2,f3,f4,f5 f.f1.facet.sort=count f.f1.facet.limit=10 f.f1.facet.missing=true f.f1.facet.mincount=1 f.f2.facet.sort=index f.f2.facet.limit=-1 f.f2.facet.missing=true f.f2.facet.mincount=1 f.f3.facet.sort=index f.f3.facet.limit=-1 f.f3.facet.missing=true f.f3.facet.mincount=1 f.f4.facet.sort=index f.f4.facet.limit=-1 f.f4.facet.missing=true f.f4.facet.mincount=1 f.f5.facet.sort=index f.f5.facet.limit=-1 f.f5.facet.missing=true f.f5.facet.mincount=1 shards=127.0.0.1:8983/solr/shard1,127.0.0.1:8983/solr/shard2 Number of docs in each shard: shard1: 16,234 shard2: 169,089 These are the fields terms' distribution: f1: shard1 - 16,046, shard2 - 38 f2: all shards - 232 f3: all shards - 53 f4: all shards - 6 f5: all shards - 10 When we use a maximum java heap size of 8GB, the query finishes. It seems about of 6GB is used for pivoting. It doesn’t seem reasonable that the facet.pivot on 2 cores with 200,000 docs requires that much memory. We tried looking into the code a little and it seems the sharded queries run with facet.pivot.mincount=-1 as part of the refinement process. We also noticed that in this scenario, the parameter skipRefinementAtThisLevel in the method queuePivotRefinementRequests in the class PivotFacetField is false. We think all of this is the cause of the memory consumption – but we couldn't pinpoint the underlying issue. Is there a way to alter the algorithm to consume less memory? If anyone can explain offline the way refinement works here, we would be happy to try and help resolve this. Thank you very much. Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.9, 5.0 Attachments: SOLR-2894-reworked.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, dateToObject.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-5514) atomic update throws exception if the schema contains uuid fields: Invalid UUID String: 'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'
[
https://issues.apache.org/jira/browse/SOLR-5514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13978197#comment-13978197
]
Elran Dvir commented on SOLR-5514:
--
I have encountered the exact same problem as Dirk.
I managed to fix it.
The value of the uuid field is combination of class name, colon and (uuid)
actual value.
I searched in the code where this form of string is created.
The only place I found it is in the method writeVal(Object val) in JavaBinCodec
class.
So I added a special handling for uuid values.
please see patch attached. The patch is based on Solr 4.4, but takes into
considerations changes made in 4.7.
I will be happy to get feedback from you guys.
Thanks.
atomic update throws exception if the schema contains uuid fields: Invalid
UUID String: 'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'
-
Key: SOLR-5514
URL: https://issues.apache.org/jira/browse/SOLR-5514
Project: Solr
Issue Type: Bug
Affects Versions: 4.5.1
Environment: unix and windows
Reporter: Dirk Reuss
Assignee: Shalin Shekhar Mangar
I am updating an exiting document with the statement
adddocfield name='name' update='set'newvalue/field
All fields are stored and I have several UUID fields. About 10-20% of the
update commands will fail with the message: (example)
Invalid UUID String: 'java.util.UUID:532c9353-d391-4a04-8618-dc2fa1ef8b35'
the point is that java.util.UUID seems to be prepended to the original uuid
stored in the field and when the value is written this error occours.
I tried to check if this specific uuid field was the problem and
added the uuid field in the update xml with(field name='id1'
update='set'...). But the error simply moved to an other uuid field.
here is the original exception:
lst name=responseHeaderint name=status500/intint
name=QTime34/int/lstlst name=errorstr name=msgError while
creating field
'MyUUIDField{type=uuid,properties=indexed,stored,omitTermFreqAndPositions,required,
required=true}' from value
'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'/strstr
name=traceorg.apache.solr.common.SolrException: Error while creating field
'MyUUIDField{type=uuid,properties=indexed,stored,omitTermFreqAndPositions,required,
required=true}' from value
'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'
at org.apache.solr.schema.FieldType.createField(FieldType.java:259)
at org.apache.solr.schema.StrField.createFields(StrField.java:56)
at
org.apache.solr.update.DocumentBuilder.addField(DocumentBuilder.java:47)
at
org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:118)
at
org.apache.solr.update.AddUpdateCommand.getLuceneDocument(AddUpdateCommand.java:77)
at
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:215)
at
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
at
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:556)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:692)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:435)
at
org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:100)
at
org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:247)
at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:174)
at
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
[jira] [Updated] (SOLR-5514) atomic update throws exception if the schema contains uuid fields: Invalid UUID String: 'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'
[
https://issues.apache.org/jira/browse/SOLR-5514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elran Dvir updated SOLR-5514:
-
Attachment: SOLR-5514.patch
atomic update throws exception if the schema contains uuid fields: Invalid
UUID String: 'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'
-
Key: SOLR-5514
URL: https://issues.apache.org/jira/browse/SOLR-5514
Project: Solr
Issue Type: Bug
Affects Versions: 4.5.1
Environment: unix and windows
Reporter: Dirk Reuss
Assignee: Shalin Shekhar Mangar
Attachments: SOLR-5514.patch
I am updating an exiting document with the statement
adddocfield name='name' update='set'newvalue/field
All fields are stored and I have several UUID fields. About 10-20% of the
update commands will fail with the message: (example)
Invalid UUID String: 'java.util.UUID:532c9353-d391-4a04-8618-dc2fa1ef8b35'
the point is that java.util.UUID seems to be prepended to the original uuid
stored in the field and when the value is written this error occours.
I tried to check if this specific uuid field was the problem and
added the uuid field in the update xml with(field name='id1'
update='set'...). But the error simply moved to an other uuid field.
here is the original exception:
lst name=responseHeaderint name=status500/intint
name=QTime34/int/lstlst name=errorstr name=msgError while
creating field
'MyUUIDField{type=uuid,properties=indexed,stored,omitTermFreqAndPositions,required,
required=true}' from value
'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'/strstr
name=traceorg.apache.solr.common.SolrException: Error while creating field
'MyUUIDField{type=uuid,properties=indexed,stored,omitTermFreqAndPositions,required,
required=true}' from value
'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'
at org.apache.solr.schema.FieldType.createField(FieldType.java:259)
at org.apache.solr.schema.StrField.createFields(StrField.java:56)
at
org.apache.solr.update.DocumentBuilder.addField(DocumentBuilder.java:47)
at
org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:118)
at
org.apache.solr.update.AddUpdateCommand.getLuceneDocument(AddUpdateCommand.java:77)
at
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:215)
at
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
at
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:556)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:692)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:435)
at
org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:100)
at
org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:247)
at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:174)
at
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
at
[jira] [Commented] (SOLR-5975) NullPointerException in StatsComponent when field is of type Date
[ https://issues.apache.org/jira/browse/SOLR-5975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13965079#comment-13965079 ] Elran Dvir commented on SOLR-5975: -- I am using 4.4. I am sorry for the duplication. I wasn't aware it's a known issue. Thanks. NullPointerException in StatsComponent when field is of type Date -- Key: SOLR-5975 URL: https://issues.apache.org/jira/browse/SOLR-5975 Project: Solr Issue Type: Bug Reporter: Elran Dvir Attachments: SOLR-5975.patch For a stats distributed query on a date field, a null pointer exception is thrown if there aren't any docs matching the query in one of the shards. In this case there won't be values sum and sumOfSquares in shard response, and we will get null pointer exception when we try to read them in updateTypeSpecificStats in accumulate. A patch fixing it is attached. the full exception stack trace: java.lang.NullPointerException at org.apache.solr.handler.component.DateStatsValues.updateTypeSpecificStats(StatsValuesFactory.java:484) at org.apache.solr.handler.component.AbstractStatsValues.accumulate(StatsValuesFactory.java:128) at org.apache.solr.handler.component.StatsComponent.handleResponses(StatsComponent.java:121) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:311) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1904) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:659) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:362) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:158) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) 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:1086) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) 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.HandlerCollection.handle(HandlerCollection.java:154) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:804) -- 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] [Resolved] (SOLR-5975) NullPointerException in StatsComponent when field is of type Date
[ https://issues.apache.org/jira/browse/SOLR-5975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir resolved SOLR-5975. -- Resolution: Duplicate NullPointerException in StatsComponent when field is of type Date -- Key: SOLR-5975 URL: https://issues.apache.org/jira/browse/SOLR-5975 Project: Solr Issue Type: Bug Reporter: Elran Dvir Attachments: SOLR-5975.patch For a stats distributed query on a date field, a null pointer exception is thrown if there aren't any docs matching the query in one of the shards. In this case there won't be values sum and sumOfSquares in shard response, and we will get null pointer exception when we try to read them in updateTypeSpecificStats in accumulate. A patch fixing it is attached. the full exception stack trace: java.lang.NullPointerException at org.apache.solr.handler.component.DateStatsValues.updateTypeSpecificStats(StatsValuesFactory.java:484) at org.apache.solr.handler.component.AbstractStatsValues.accumulate(StatsValuesFactory.java:128) at org.apache.solr.handler.component.StatsComponent.handleResponses(StatsComponent.java:121) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:311) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1904) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:659) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:362) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:158) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) 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:1086) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) 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.HandlerCollection.handle(HandlerCollection.java:154) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:804) -- 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-5975) NullPointerException in StatsComponent when field is of type Date
Elran Dvir created SOLR-5975: Summary: NullPointerException in StatsComponent when field is of type Date Key: SOLR-5975 URL: https://issues.apache.org/jira/browse/SOLR-5975 Project: Solr Issue Type: Bug Reporter: Elran Dvir For a stats distributed query on a date field, a null pointer exception is thrown if there aren't any docs matching the query in one of the shards. In this case there won't be values sum and sumOfSquares in shard response, and we will get null pointer exception when we try to read them in updateTypeSpecificStats in accumulate. A patch fixing it is attached. the full exception stack trace: java.lang.NullPointerException at org.apache.solr.handler.component.DateStatsValues.updateTypeSpecificStats(StatsValuesFactory.java:484) at org.apache.solr.handler.component.AbstractStatsValues.accumulate(StatsValuesFactory.java:128) at org.apache.solr.handler.component.StatsComponent.handleResponses(StatsComponent.java:121) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:311) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1904) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:659) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:362) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:158) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) 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:1086) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) 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.HandlerCollection.handle(HandlerCollection.java:154) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:804) -- 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-5975) NullPointerException in StatsComponent when field is of type Date
[ https://issues.apache.org/jira/browse/SOLR-5975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5975: - Attachment: SOLR-5975.patch NullPointerException in StatsComponent when field is of type Date -- Key: SOLR-5975 URL: https://issues.apache.org/jira/browse/SOLR-5975 Project: Solr Issue Type: Bug Reporter: Elran Dvir Attachments: SOLR-5975.patch For a stats distributed query on a date field, a null pointer exception is thrown if there aren't any docs matching the query in one of the shards. In this case there won't be values sum and sumOfSquares in shard response, and we will get null pointer exception when we try to read them in updateTypeSpecificStats in accumulate. A patch fixing it is attached. the full exception stack trace: java.lang.NullPointerException at org.apache.solr.handler.component.DateStatsValues.updateTypeSpecificStats(StatsValuesFactory.java:484) at org.apache.solr.handler.component.AbstractStatsValues.accumulate(StatsValuesFactory.java:128) at org.apache.solr.handler.component.StatsComponent.handleResponses(StatsComponent.java:121) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:311) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1904) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:659) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:362) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:158) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) 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:1086) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) 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.HandlerCollection.handle(HandlerCollection.java:154) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:804) -- 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-5972) new statistics facet capabilities to StatsComponent facet - limit, sort and missing.
Elran Dvir created SOLR-5972: Summary: new statistics facet capabilities to StatsComponent facet - limit, sort and missing. Key: SOLR-5972 URL: https://issues.apache.org/jira/browse/SOLR-5972 Project: Solr Issue Type: New Feature Reporter: Elran Dvir I thought it would be very useful to enable limiting and sorting StatsComponent facet response. I chose to implement it in Stats Component rather than Analytics component because Analytics doesn't support distributed queries yet. The default for limit is -1 - returns all facet values. The default for sort is no sorting. The default for missing is true. So if you use stats component exactly as before, the response won't change as of nowadays. If ask for sort or limit, missing facet value will be the last, as in regular facet. Sort types supported: min, max, sum and countdistinct for stats fields, and count and index for facet fields (all sort types are lower cased). Sort directions asc and desc are supported. Sorting by multiple fields is supported. our example use case will be employees' monthly salaries: The follwing query returns the 10 most expensive employees: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary sum descf.employee_name.stats.facet.limit=10 The follwing query returns the 10 least expensive employees: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary sum ascf.employee_name.stats.facet.limit=10 The follwing query returns the employee that got the highest salary ever: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary max descf.employee_name.stats.facet.limit=1 The follwing query returns the employee that got the lowest salary ever: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary min ascf.employee_name.stats.facet.limit=1 The follwing query returns the 10 first (lexicographically) employees: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=employee_name index ascf.employee_name.stats.facet.limit=10 The follwing query returns the 10 employees that have worked for the longest period: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=employee_name count descf.employee_name.stats.facet.limit=10 The follwing query returns the 10 employee whose salaries vary the most: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary countdistinct descf.employee_name.stats.facet.limit=10 Attached a patch implementing this in StatsComponent. -- 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-5972) new statistics facet capabilities to StatsComponent facet - limit, sort and missing.
[ https://issues.apache.org/jira/browse/SOLR-5972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5972: - Attachment: SOLR-5972.patch new statistics facet capabilities to StatsComponent facet - limit, sort and missing. Key: SOLR-5972 URL: https://issues.apache.org/jira/browse/SOLR-5972 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: SOLR-5972.patch I thought it would be very useful to enable limiting and sorting StatsComponent facet response. I chose to implement it in Stats Component rather than Analytics component because Analytics doesn't support distributed queries yet. The default for limit is -1 - returns all facet values. The default for sort is no sorting. The default for missing is true. So if you use stats component exactly as before, the response won't change as of nowadays. If ask for sort or limit, missing facet value will be the last, as in regular facet. Sort types supported: min, max, sum and countdistinct for stats fields, and count and index for facet fields (all sort types are lower cased). Sort directions asc and desc are supported. Sorting by multiple fields is supported. our example use case will be employees' monthly salaries: The follwing query returns the 10 most expensive employees: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary sum descf.employee_name.stats.facet.limit=10 The follwing query returns the 10 least expensive employees: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary sum ascf.employee_name.stats.facet.limit=10 The follwing query returns the employee that got the highest salary ever: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary max descf.employee_name.stats.facet.limit=1 The follwing query returns the employee that got the lowest salary ever: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary min ascf.employee_name.stats.facet.limit=1 The follwing query returns the 10 first (lexicographically) employees: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=employee_name index ascf.employee_name.stats.facet.limit=10 The follwing query returns the 10 employees that have worked for the longest period: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=employee_name count descf.employee_name.stats.facet.limit=10 The follwing query returns the 10 employee whose salaries vary the most: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary countdistinct descf.employee_name.stats.facet.limit=10 Attached a patch implementing this in StatsComponent. -- 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-5877) allow empty values in EnumField
Elran Dvir created SOLR-5877: Summary: allow empty values in EnumField Key: SOLR-5877 URL: https://issues.apache.org/jira/browse/SOLR-5877 Project: Solr Issue Type: Improvement Reporter: Elran Dvir now This will be possible: enumsConfig !-- note: you cannot change the order/existing values in enum without reindexing. but you can always add new values to the end. -- enum name=severity value/value valueLow/value valueHigh/value valueCritical/value /enum /enumsConfig The patch is attached -- 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-5877) allow empty values in EnumField
[ https://issues.apache.org/jira/browse/SOLR-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5877: - Attachment: SOLR-5877.patch allow empty values in EnumField --- Key: SOLR-5877 URL: https://issues.apache.org/jira/browse/SOLR-5877 Project: Solr Issue Type: Improvement Reporter: Elran Dvir Attachments: SOLR-5877.patch now This will be possible: enumsConfig !-- note: you cannot change the order/existing values in enum without reindexing. but you can always add new values to the end. -- enum name=severity value/value valueLow/value valueHigh/value valueCritical/value /enum /enumsConfig The patch is attached -- 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-5857) StatsComponent returns invalid string representation in facets
Elran Dvir created SOLR-5857: Summary: StatsComponent returns invalid string representation in facets Key: SOLR-5857 URL: https://issues.apache.org/jira/browse/SOLR-5857 Project: Solr Issue Type: Bug Reporter: Elran Dvir I have an EnumField called severity. When I run the following query: rows=0q=*:*fq=(severity:Critical OR severity:High)fq=fieldB:[* TO *]fq=severity:[* TO *]stats=truestats.field=fieldBf.fieldB.stats.facet=severity I get the following response: result name=response numFound=1786 start=0/ lst name=stats lst name=stats_fields lst name=fieldB str name=minBej/str str name=maxdmfbsrvftu/str long name=count1786/long long name=missing0/long lst name=facets lst name=severity lst name=`#8;#0;#0;#0;#5; str name=minCfo Qbsbejtf )cfoq@be/difdlqpjou/dpn*!/str str name=maxTiblfe Evobz )tiblfee*!/str long name=count24/long long name=missing0/long lst name=facets/ /lst lst name=`#8;#0;#0;#0;#4; str name=minBej Cbcbj )bejc*!/str str name=maxdmfbsrvftu/str long name=count1762/long long name=missing0/long lst name=facets/ /lst /lst /lst /lst /lst /lst As can be seen, the string representation of severity is invalid So I concluded there is a bug with displaying statscomponent facet value. I attached a patch fixing the bug. It now returns the proper string representation of the term. I think StatsComponent facet value should be the Object itself and not the string representation, similar to all other stats values. (For example, If it's an object, the facet field values can be sorted in case the field is a Number or EnumField) I tried to change it, but statscomponent facet value is FieldStatsInfo's name and it gets it from NamedList element's name. If someone can take a look and fix it, I think it will be great. Thanks. -- 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-5857) StatsComponent returns invalid string representation in facets
[ https://issues.apache.org/jira/browse/SOLR-5857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5857: - Attachment: SOLR-5857.patch StatsComponent returns invalid string representation in facets -- Key: SOLR-5857 URL: https://issues.apache.org/jira/browse/SOLR-5857 Project: Solr Issue Type: Bug Reporter: Elran Dvir Attachments: SOLR-5857.patch I have an EnumField called severity. When I run the following query: rows=0q=*:*fq=(severity:Critical OR severity:High)fq=fieldB:[* TO *]fq=severity:[* TO *]stats=truestats.field=fieldBf.fieldB.stats.facet=severity I get the following response: result name=response numFound=1786 start=0/ lst name=stats lst name=stats_fields lst name=fieldB str name=minBej/str str name=maxdmfbsrvftu/str long name=count1786/long long name=missing0/long lst name=facets lst name=severity lst name=`#8;#0;#0;#0;#5; str name=minCfo Qbsbejtf )cfoq@be/difdlqpjou/dpn*!/str str name=maxTiblfe Evobz )tiblfee*!/str long name=count24/long long name=missing0/long lst name=facets/ /lst lst name=`#8;#0;#0;#0;#4; str name=minBej Cbcbj )bejc*!/str str name=maxdmfbsrvftu/str long name=count1762/long long name=missing0/long lst name=facets/ /lst /lst /lst /lst /lst /lst As can be seen, the string representation of severity is invalid So I concluded there is a bug with displaying statscomponent facet value. I attached a patch fixing the bug. It now returns the proper string representation of the term. I think StatsComponent facet value should be the Object itself and not the string representation, similar to all other stats values. (For example, If it's an object, the facet field values can be sorted in case the field is a Number or EnumField) I tried to change it, but statscomponent facet value is FieldStatsInfo's name and it gets it from NamedList element's name. If someone can take a look and fix it, I think it will be great. Thanks. -- 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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13930026#comment-13930026 ] Elran Dvir commented on SOLR-2894: -- No. It doesn't happen when I use facet.limit=-1 instead of the f.fieldname.facet.limit syntax. Thanks. Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.7 Attachments: SOLR-2894-reworked.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, dateToObject.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925787#comment-13925787 ] Elran Dvir commented on SOLR-2894: -- Hi, I don't know where I should exactly put the test in DistributedFacetPivotTest, but this the test: 1)index more than 100 docs (you can index docs only with id) 2)run the following query: this.query( q, *:*, rows, 0, facet,true, facet.pivot,id, f.id.facet.limit,-1); you expect to get as many ids as you indexed, but you will get only 100. Thanks. Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.7 Attachments: SOLR-2894-reworked.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, dateToObject.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-5846) EnumField docValues funtionality
Elran Dvir created SOLR-5846: Summary: EnumField docValues funtionality Key: SOLR-5846 URL: https://issues.apache.org/jira/browse/SOLR-5846 Project: Solr Issue Type: Improvement Reporter: Elran Dvir I have added docValues functionality to EnumField. Please review the patch attached. If there is any problem with it, please let me know. -- 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-5846) EnumField docValues funtionality
[ https://issues.apache.org/jira/browse/SOLR-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5846: - Attachment: SOLR-5846.patch EnumField docValues funtionality Key: SOLR-5846 URL: https://issues.apache.org/jira/browse/SOLR-5846 Project: Solr Issue Type: Improvement Reporter: Elran Dvir Attachments: SOLR-5846.patch I have added docValues functionality to EnumField. Please review the patch attached. If there is any problem with it, please let me know. -- 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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925156#comment-13925156 ] Elran Dvir commented on SOLR-2894: -- I think I solved the the toObject problem with datetime fields. Please see the patch attached. All tests pass now. Let me know what you think. Thanks. Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.7 Attachments: SOLR-2894-reworked.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, dateToObject.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-2894: - Attachment: dateToObject.patch Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.7 Attachments: SOLR-2894-reworked.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, dateToObject.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925211#comment-13925211 ] Elran Dvir commented on SOLR-2894: -- I have checked the latest patch. Problem 3 (field with negative limit threw exception) is now solved. Thanks! But I still see problem 1 (f.field.facet.limit=-1 is not being respected). Thank you very much. Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.7 Attachments: SOLR-2894-reworked.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, dateToObject.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920946#comment-13920946 ] Elran Dvir commented on SOLR-2894: -- I think we should preserve object values in disruibuted pivot, as in regular pivot. I want to help fix the toObject problem with datetime fields. I tried to apply the most recent patch to the latest Solr trunk revision. There were some problems applying it. Can you please create a new patch against latest Solr trunk revision, or indicate which revision the patch was created againt? Thanks! Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.7 Attachments: SOLR-2894-reworked.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13922092#comment-13922092 ] Elran Dvir commented on SOLR-2894: -- Thanks for the patch. I will take a lool at the toObject problem with datetime fields. Does the patch fix issues 1 and 3 I reported on February 24? Thanks. Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.7 Attachments: SOLR-2894-reworked.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-5428) new statistics results to StatsComponent - distinctValues and countDistinct
[ https://issues.apache.org/jira/browse/SOLR-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13917310#comment-13917310 ] Elran Dvir commented on SOLR-5428: -- I think it should work on multi-value fields. It works as any other stats functions. new statistics results to StatsComponent - distinctValues and countDistinct --- Key: SOLR-5428 URL: https://issues.apache.org/jira/browse/SOLR-5428 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Shalin Shekhar Mangar Fix For: 4.7, 5.0 Attachments: SOLR-5428.patch, SOLR-5428.patch I thought it would be very useful to display the distinct values (and the count) of a field among other statistics. Attached a patch implementing this in StatsComponent. Added results : distinctValues - list of all distnict values countDistinct - distnict values count. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912660#comment-13912660 ] Elran Dvir commented on SOLR-2894: -- By the way, when I profiled our very slow distributed pivot, I noticed most of the time is wasted in val.get(i) in trimExcessValuesBasedUponFacetLimitAndOffset in PivotFacetHelper.java. The following change (in the first two lines of the function) has shown a significant improvement: ListNamedListObject newVal = new LinkedListNamedListObject(); if (val == null) return val; to: if (val == null) return val; ListNamedListObject newVal = new ArrayListNamedListObject(val.size()); Thanks. Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.7 Attachments: SOLR-2894-reworked.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13910397#comment-13910397 ] Elran Dvir commented on SOLR-2894: -- Brett (and your team), thank you very much for your hard work. We've been having a lot of performance issues with using the previous version patch (which we love), and initial testing shows they are now resolved. We did also notice a few issues: 1) f.field.facet.limit=-1 is not being respected (as reported by me on 20/May/13 10:27) 2) pivot queries are returning String instead of Object (as reported by me on 25/Aug/13 07:38) except for boolean fields. I know the reason is there was a problem with datetime fields. I changed it back to toObject and I can't reproduce any issues running unit test locally via maven. I'd be glad to help fix this problem, if anyone can create a simple test case that fails ? 3) The following query throws an exception: q=*:*rows=0f.fieldA.facet.sort=indexf.fieldA.facet.limit=-1f.fieldA.facet.missing=truef.fieldA.facet.mincount=1f.fieldB.facet.sort=indexf.fieldB.facet.limit=-1f.fieldB.facet.missing=truef.fieldB.facet.mincount=1facet=truefacet.pivot=fieldA,fieldBshards=127.0.0.1:8983/solr/shardA,127.0.0.1:8983/solr/shardB java.lang.IllegalArgumentException: fromIndex(0) toIndex(-1) at java.util.ArrayList.subListRangeCheck(ArrayList.java:975) at java.util.ArrayList.subList(ArrayList.java:965) at org.apache.solr.handler.component.PivotFacetField.refineNextLevelOfFacets(PivotFacetField.java:276) at org.apache.solr.handler.component.PivotFacetField.queuePivotRefinementRequests(PivotFacetField.java:231) at org.apache.solr.handler.component.PivotFacet.queuePivotRefinementRequests(PivotFacet.java:86) at org.apache.solr.handler.component.FacetComponent.countFacets(FacetComponent.java:565) at org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:413) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:311) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1904) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:659) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:362) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:158) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) 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:1086) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) 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.HandlerCollection.handle(HandlerCollection.java:154) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:804) Thank you again for this great patch! Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.7
[jira] [Created] (SOLR-5690) Null pointerException in AbstractStatsValues.accumulate
Elran Dvir created SOLR-5690: Summary: Null pointerException in AbstractStatsValues.accumulate Key: SOLR-5690 URL: https://issues.apache.org/jira/browse/SOLR-5690 Project: Solr Issue Type: Bug Affects Versions: 5.0, 4.7 Reporter: Elran Dvir Priority: Minor It happens when there is a string field with docValues=true and default=. Then, with documents that have empty string value in the field, values.exists(docID) is true but values.strVal(docID) is null, and it throws null pointer exception when trying to add the value to distinctValues set. the solr query is stats=truestats.field=Xstats.calcdistinct=true stack trace: java.lang.NullPointerException at java.util.TreeMap.put(TreeMap.java:567) at java.util.TreeSet.add(TreeSet.java:266) at org.apache.solr.handler.component.AbstractStatsValues.accumulate(StatsValuesFactory.java:164) at org.apache.solr.handler.component.StringStatsValues.accumulate(StatsValuesFactory.java:535) at org.apache.solr.handler.component.SimpleStats.getFieldCacheStats(StatsComponent.java:274) at org.apache.solr.handler.component.SimpleStats.getStatsFields(StatsComponent.java:225) at org.apache.solr.handler.component.SimpleStats.getStatsCounts(StatsComponent.java:200) at org.apache.solr.handler.component.StatsComponent.process(StatsComponent.java:68) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1904) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:659) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:362) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:158) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) 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:1086) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) 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.HandlerCollection.handle(HandlerCollection.java:154) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:804) -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5690) Null pointerException in AbstractStatsValues.accumulate
[ https://issues.apache.org/jira/browse/SOLR-5690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889459#comment-13889459 ] Elran Dvir commented on SOLR-5690: -- Patch resolving the issue is attached. Null pointerException in AbstractStatsValues.accumulate --- Key: SOLR-5690 URL: https://issues.apache.org/jira/browse/SOLR-5690 Project: Solr Issue Type: Bug Affects Versions: 5.0, 4.7 Reporter: Elran Dvir Priority: Minor Attachments: SOLR-5690.patch It happens when there is a string field with docValues=true and default=. Then, with documents that have empty string value in the field, values.exists(docID) is true but values.strVal(docID) is null, and it throws null pointer exception when trying to add the value to distinctValues set. the solr query is stats=truestats.field=Xstats.calcdistinct=true stack trace: java.lang.NullPointerException at java.util.TreeMap.put(TreeMap.java:567) at java.util.TreeSet.add(TreeSet.java:266) at org.apache.solr.handler.component.AbstractStatsValues.accumulate(StatsValuesFactory.java:164) at org.apache.solr.handler.component.StringStatsValues.accumulate(StatsValuesFactory.java:535) at org.apache.solr.handler.component.SimpleStats.getFieldCacheStats(StatsComponent.java:274) at org.apache.solr.handler.component.SimpleStats.getStatsFields(StatsComponent.java:225) at org.apache.solr.handler.component.SimpleStats.getStatsCounts(StatsComponent.java:200) at org.apache.solr.handler.component.StatsComponent.process(StatsComponent.java:68) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1904) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:659) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:362) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:158) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) 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:1086) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) 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.HandlerCollection.handle(HandlerCollection.java:154) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:804) -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5690) Null pointerException in AbstractStatsValues.accumulate
[ https://issues.apache.org/jira/browse/SOLR-5690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5690: - Attachment: SOLR-5690.patch Null pointerException in AbstractStatsValues.accumulate --- Key: SOLR-5690 URL: https://issues.apache.org/jira/browse/SOLR-5690 Project: Solr Issue Type: Bug Affects Versions: 5.0, 4.7 Reporter: Elran Dvir Priority: Minor Attachments: SOLR-5690.patch It happens when there is a string field with docValues=true and default=. Then, with documents that have empty string value in the field, values.exists(docID) is true but values.strVal(docID) is null, and it throws null pointer exception when trying to add the value to distinctValues set. the solr query is stats=truestats.field=Xstats.calcdistinct=true stack trace: java.lang.NullPointerException at java.util.TreeMap.put(TreeMap.java:567) at java.util.TreeSet.add(TreeSet.java:266) at org.apache.solr.handler.component.AbstractStatsValues.accumulate(StatsValuesFactory.java:164) at org.apache.solr.handler.component.StringStatsValues.accumulate(StatsValuesFactory.java:535) at org.apache.solr.handler.component.SimpleStats.getFieldCacheStats(StatsComponent.java:274) at org.apache.solr.handler.component.SimpleStats.getStatsFields(StatsComponent.java:225) at org.apache.solr.handler.component.SimpleStats.getStatsCounts(StatsComponent.java:200) at org.apache.solr.handler.component.StatsComponent.process(StatsComponent.java:68) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1904) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:659) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:362) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:158) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) 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:1086) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) 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.HandlerCollection.handle(HandlerCollection.java:154) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:804) -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5302) Analytics Component
[ https://issues.apache.org/jira/browse/SOLR-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13840002#comment-13840002 ] Elran Dvir commented on SOLR-5302: -- I saw in documentation that Unique count is supported among other statistical expressions. what about the unique values themselves? (as described in SOLR-5428) Thanks. Analytics Component --- Key: SOLR-5302 URL: https://issues.apache.org/jira/browse/SOLR-5302 Project: Solr Issue Type: New Feature Reporter: Steven Bower Assignee: Erick Erickson Attachments: SOLR-5302.patch, SOLR-5302.patch, SOLR-5302.patch, SOLR-5302.patch, Search Analytics Component.pdf, Statistical Expressions.pdf, solr_analytics-2013.10.04-2.patch This ticket is to track a replacement for the StatsComponent. The AnalyticsComponent supports the following features: * All functionality of StatsComponent (SOLR-4499) * Field Faceting (SOLR-3435) ** Support for limit ** Sorting (bucket name or any stat in the bucket ** Support for offset * Range Faceting ** Supports all options of standard range faceting * Query Faceting (SOLR-2925) * Ability to use overall/field facet statistics as input to range/query faceting (ie calc min/max date and then facet over that range * Support for more complex aggregate/mapping operations (SOLR-1622) ** Aggregations: min, max, sum, sum-of-square, count, missing, stddev, mean, median, percentiles ** Operations: negation, abs, add, multiply, divide, power, log, date math, string reversal, string concat ** Easily pluggable framework to add additional operations * New / cleaner output format Outstanding Issues: * Multi-value field support for stats (supported for faceting) * Multi-shard support (may not be possible for some operations, eg median) -- 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] [Created] (SOLR-5531) support unique values in Analytics Component
Elran Dvir created SOLR-5531: Summary: support unique values in Analytics Component Key: SOLR-5531 URL: https://issues.apache.org/jira/browse/SOLR-5531 Project: Solr Issue Type: Wish Reporter: Elran Dvir -- 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] [Updated] (SOLR-5428) new statistics results to StatsComponent - distinctValues and countDistinct
[ https://issues.apache.org/jira/browse/SOLR-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5428: - Attachment: SOLR-5428.patch new statistics results to StatsComponent - distinctValues and countDistinct --- Key: SOLR-5428 URL: https://issues.apache.org/jira/browse/SOLR-5428 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Shalin Shekhar Mangar Attachments: SOLR-5428.patch, SOLR-5428.patch I thought it would be very useful to display the distinct values (and the count) of a field among other statistics. Attached a patch implementing this in StatsComponent. Added results : distinctValues - list of all distnict values countDistinct - distnict values count. -- 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-5428) new statistics results to StatsComponent - distinctValues and countDistinct
[ https://issues.apache.org/jira/browse/SOLR-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13827736#comment-13827736 ] Elran Dvir commented on SOLR-5428: -- I attached a new patch. Now stats component contains new parameter calcdistinict. By default it's false. It can be set per field (f.field.stats.calcdistinct) Let me know what you think. new statistics results to StatsComponent - distinctValues and countDistinct --- Key: SOLR-5428 URL: https://issues.apache.org/jira/browse/SOLR-5428 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Shalin Shekhar Mangar Attachments: SOLR-5428.patch, SOLR-5428.patch I thought it would be very useful to display the distinct values (and the count) of a field among other statistics. Attached a patch implementing this in StatsComponent. Added results : distinctValues - list of all distnict values countDistinct - distnict values count. -- 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-5428) new statistics results to StatsComponent - distinctValues and countDistinct
[ https://issues.apache.org/jira/browse/SOLR-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13828535#comment-13828535 ] Elran Dvir commented on SOLR-5428: -- Thank you, Shalin! new statistics results to StatsComponent - distinctValues and countDistinct --- Key: SOLR-5428 URL: https://issues.apache.org/jira/browse/SOLR-5428 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Shalin Shekhar Mangar Fix For: 5.0, 4.7 Attachments: SOLR-5428.patch, SOLR-5428.patch I thought it would be very useful to display the distinct values (and the count) of a field among other statistics. Attached a patch implementing this in StatsComponent. Added results : distinctValues - list of all distnict values countDistinct - distnict values count. -- 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-5428) new statistics results to StatsComponent - distinctValues and countDistinct
[ https://issues.apache.org/jira/browse/SOLR-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13822465#comment-13822465 ] Elran Dvir commented on SOLR-5428: -- Thanks, Shalin. My use case requires 'distinctValues' alongside the other results, so I am afraid using LukeRequestHandler is not suitable. In what way is it expensive? Is tere a way to improve it? What do you mean when you say There should be a way to stop the collection ? Thanks. new statistics results to StatsComponent - distinctValues and countDistinct --- Key: SOLR-5428 URL: https://issues.apache.org/jira/browse/SOLR-5428 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Shalin Shekhar Mangar Attachments: SOLR-5428.patch I thought it would be very useful to display the distinct values (and the count) of a field among other statistics. Attached a patch implementing this in StatsComponent. Added results : distinctValues - list of all distnict values countDistinct - distnict values count. -- 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-5428) new statistics results to StatsComponent - distinctValues and countDistinct
[ https://issues.apache.org/jira/browse/SOLR-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13822477#comment-13822477 ] Elran Dvir commented on SOLR-5428: -- Anthother thing I thout about: my queries have q,fq and are distributed. Does LukeRequestHandler support it? new statistics results to StatsComponent - distinctValues and countDistinct --- Key: SOLR-5428 URL: https://issues.apache.org/jira/browse/SOLR-5428 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Shalin Shekhar Mangar Attachments: SOLR-5428.patch I thought it would be very useful to display the distinct values (and the count) of a field among other statistics. Attached a patch implementing this in StatsComponent. Added results : distinctValues - list of all distnict values countDistinct - distnict values count. -- 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-5428) new statistics results to StatsComponent - distinctValues and countDistinct
[ https://issues.apache.org/jira/browse/SOLR-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13821391#comment-13821391 ] Elran Dvir commented on SOLR-5428: -- I am not sure my understanding of Solr is good enough to answer this question. you can look at the code to determine the answer. it will very much appreciated if you update me what you found out. Thanks. new statistics results to StatsComponent - distinctValues and countDistinct --- Key: SOLR-5428 URL: https://issues.apache.org/jira/browse/SOLR-5428 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Shalin Shekhar Mangar Attachments: SOLR-5428.patch I thought it would be very useful to display the distinct values (and the count) of a field among other statistics. Attached a patch implementing this in StatsComponent. Added results : distinctValues - list of all distnict values countDistinct - distnict values count. -- 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] [Updated] (SOLR-5428) new statistics results to StatsComponent - distinctValues and countDistinct
[ https://issues.apache.org/jira/browse/SOLR-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5428: - Description: I thought it would be very useful to display the distinct values (and the count) of a field among other statistics. Attached a patch implementing this in StatsComponent. Added results : distinctValues - list of all distnict values countDistinct - distnict values count. was: Added new statistics results to StatsComponent : distinctValues - list of all distnict values countDistinct - distnict values count new statistics results to StatsComponent - distinctValues and countDistinct --- Key: SOLR-5428 URL: https://issues.apache.org/jira/browse/SOLR-5428 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: SOLR-5428.patch I thought it would be very useful to display the distinct values (and the count) of a field among other statistics. Attached a patch implementing this in StatsComponent. Added results : distinctValues - list of all distnict values countDistinct - distnict values count. -- 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-5428) new statistics results to StatsComponent - distinctValues and countDistinct
[ https://issues.apache.org/jira/browse/SOLR-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13821019#comment-13821019 ] Elran Dvir commented on SOLR-5428: -- Yes, as far as I know. If there aren't any bugs in distributed queries in StatsComponent, this feature works as others. new statistics results to StatsComponent - distinctValues and countDistinct --- Key: SOLR-5428 URL: https://issues.apache.org/jira/browse/SOLR-5428 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: SOLR-5428.patch I thought it would be very useful to display the distinct values (and the count) of a field among other statistics. Attached a patch implementing this in StatsComponent. Added results : distinctValues - list of all distnict values countDistinct - distnict values count. -- 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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13818422#comment-13818422 ] Elran Dvir commented on SOLR-2894: -- I didn't manage to make ditributed pivot on date field to blow up with toObject. Can you please attach an example query that blows Solr up and I'll adjust it to my environment? Thanks. Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.6 Attachments: SOLR-2894-reworked.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- 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] [Created] (SOLR-5428) new statistics results to StatsComponent - distinctValues and countDistinct
Elran Dvir created SOLR-5428: Summary: new statistics results to StatsComponent - distinctValues and countDistinct Key: SOLR-5428 URL: https://issues.apache.org/jira/browse/SOLR-5428 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Added new statistics results to StatsComponent : distinctValues - list of all distnict values countDistinct - distnict values count -- 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] [Updated] (SOLR-5428) new statistics results to StatsComponent - distinctValues and countDistinct
[ https://issues.apache.org/jira/browse/SOLR-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5428: - Attachment: SOLR-5428.patch new statistics results to StatsComponent - distinctValues and countDistinct --- Key: SOLR-5428 URL: https://issues.apache.org/jira/browse/SOLR-5428 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: SOLR-5428.patch Added new statistics results to StatsComponent : distinctValues - list of all distnict values countDistinct - distnict values count -- 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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13815993#comment-13815993 ] Elran Dvir commented on SOLR-2894: -- I exained the code. It seems that the refinement process occures before doPivots (where the call ftype.toObject(sfield, termval)) was). So it seems toObject shouldn't affect the refinement process . What am I missing? Thanks. Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.6 Attachments: SOLR-2894-reworked.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13814729#comment-13814729 ] Elran Dvir commented on SOLR-2894: -- Hi Andrew, Sorry for the long delay. I am still seeing the issue I reported on 20/May/13 12:27 (f.field_A.facet.limit=-1 returns at most 100 terms for field_A). Also, can you please dircet me to the line of code where datetimes are breaking when trying to refine (caused by pivot.add( value, ftype.toObject(sfield, termval))) I need pivot to return values as objects. Thank you very much. Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.6 Attachments: SOLR-2894-reworked.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13814661#comment-13814661 ] Elran Dvir commented on SOLR-5084: -- Thank you, Erick! new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Erick Erickson Fix For: 4.6, 5.0 Attachments: Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, enumsConfig.xml, schema_example.xml We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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] [Updated] (SOLR-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5084: - Attachment: Solr-5084.trunk.patch new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Erick Erickson Attachments: Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, enumsConfig.xml, schema_example.xml We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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] [Updated] (SOLR-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5084: - Attachment: Solr-5084.trunk.patch new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Erick Erickson Attachments: Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, enumsConfig.xml, schema_example.xml We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13810092#comment-13810092 ] Elran Dvir commented on SOLR-5084: -- Attached new patch Fixes our test issues. Added putConfig(conf1, zkClient, solrhome, enumsConfig.xml); in buildZooKeeper in LeaderElectionIntegrationTest. There are still test errors but I don't think it's related to our patch (thread leaked from SUITE scope at org.apache.solr.servlet.SolrRequestParserTest). Thanks. new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Erick Erickson Attachments: Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, enumsConfig.xml, schema_example.xml We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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] [Updated] (SOLR-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5084: - Attachment: Solr-5084.trunk.patch new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Erick Erickson Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809013#comment-13809013 ] Elran Dvir commented on SOLR-5084: -- Hi Erick, I have added the necessary JavaDocs. Now 'ant precommit' finishes successfully I have attached updated patch. You can ignore the 4.x version. It's only here because it's the version I started with. Thank you very much! new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Erick Erickson Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793595#comment-13793595 ] Elran Dvir commented on SOLR-5084: -- Hi all, Did anyone have a chance to examine the latest patch? Is everthing fine? Thanks. new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Erick Erickson Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793683#comment-13793683 ] Elran Dvir commented on SOLR-5084: -- Thanks! new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Erick Erickson Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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] [Updated] (SOLR-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5084: - Attachment: Solr-5084.trunk.patch new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Erick Erickson Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13769270#comment-13769270 ] Elran Dvir commented on SOLR-5084: -- Thanks! new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Erick Erickson Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13768442#comment-13768442 ] Elran Dvir commented on SOLR-5084: -- Hi all, Did any have a chance to examine the latest patch? Thanks. new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Erick Erickson Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5084: - Attachment: Solr-5084.trunk.patch new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Erick Erickson Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13755744#comment-13755744 ] Elran Dvir commented on SOLR-5084: -- Hi all, I attached a new patch that contains: 1.Integer values in enum configuration are now implicit 0-N 2.Throw exception when indexed value is not in the configuration (either numeric or string) Should I change the example directory to demonstrate the use? If so, how? Thanks. new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Erick Erickson Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5084: - Attachment: Solr-5084.trunk.patch new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13753736#comment-13753736 ] Elran Dvir commented on SOLR-5084: -- Hi all, I attached a new patch. The patch is based on trunk. It contains changes regarding the issues Robert mentioned (Thanks Robert): 1. fixed the bug where string inputs weren't mapped into their numeric values in ValueSourceScorer.getRangeScorer and getRangeQuery 2. removed analysis chain. In the next following days, I will attach fixes for the remaining issues: 1.Verify value strictness on startup (numeric values start at 0, increment by 1). 2.Throwing exception when indexed value is not in the configuration (either number or string). Thank you all. new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13752306#comment-13752306 ] Elran Dvir commented on SOLR-5084: -- Hi Erick, I developed the feature with Solr 4.2.1 source code. I can create a similar patch based on Solr 4.4. Do you want me to create and attach it? Thanks. new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5084: - Attachment: Solr-5084.patch new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13751202#comment-13751202 ] Elran Dvir commented on SOLR-5084: -- Hi, I have attached a patch containing unit tests. Thanks. new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-2894) Implement distributed pivot faceting
[
https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13749549#comment-13749549
]
Elran Dvir commented on SOLR-2894:
--
Hi Andrew,
in class PivotFacetProcessor in function doPivots, I have noticed a change in
the code.
the current implementation is:
SimpleOrderedMapObject pivot = new SimpleOrderedMapObject();
pivot.add( field, field );
if (null == fieldValue) {
pivot.add( value, null );
} else {
termval = new BytesRef();
ftype.readableToIndexed(fieldValue, termval);
pivot.add( value, fieldValue );
}
pivot.add( count, kv.getValue() );
It means we are getting the values as strings in pivots.
In the past the implementation was pivot.add( value, ftype.toObject(sfield,
termval)) - meaning we were getting the values as objects.
I am using SolrJ and it's very important to me to get the values as objects.
Is there a reason not returning the values as objects?
Thank you very much.
Implement distributed pivot faceting
Key: SOLR-2894
URL: https://issues.apache.org/jira/browse/SOLR-2894
Project: Solr
Issue Type: Improvement
Reporter: Erik Hatcher
Fix For: 4.5
Attachments: SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894-reworked.patch
Following up on SOLR-792, pivot faceting currently only supports
undistributed mode. Distributed pivot faceting needs to be implemented.
--
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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13747249#comment-13747249 ] Elran Dvir commented on SOLR-5084: -- In the latest patch I removed all redundant format changes. There were no changes in logic. I hope to attach the patch with unit tests in the next following days. Thanks again for the attention. new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13738031#comment-13738031 ] Elran Dvir commented on SOLR-5084: -- The patch is finally attached. I'll attach a patch with unit tests ASAP. new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5084: - Attachment: Solr-5084.patch new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736975#comment-13736975 ] Elran Dvir commented on SOLR-5084: -- Thank you all very much for your very quick feedback. @Hoss, 1) I eliminated all formatting changes and attached a new patch. I hope it'll be more readable now. 2) I will try to create unit test as soon as possible and attach it. 3) I returned the value as EnumFieldValue in JavaBin format because I would like to allow for a use case of sorting the values when returned to my application by SolrJ. 4) Maybe it could, but I tried to keep the implementation simple and it didn’t appear to give much more value. If someone feels strongly about it I can revisit the implementation @Robert, In the configuration, I chose to specify the numeric values because I want to also enable indexing and querying numeric values. For example, the queries risk:[1 TO 3] and risk:[Low TO High] are both valid. Currently: - If a bogus string value is sent, the value is indexed as -1. - If a bogus integer value is sent, if the value is not a negative number, the value is indexed as is. If it’s negative – the value is indexed as -1. - The display value is of course string. If we don’t find a matching label to the numeric value in the configuration, the actual numeric value is displayed. Adding a new value at the end, would work. Changing a display string for a value, will also work for retrieving data – new data will have to be inserted using the new name (or by int value) Removing a legal value from the list would retrieve the numeric value for existing data I have no use case for removing a previously legal value, so I can either document the behavior, or implement a different behavior – depending on how this discussion goes @Erick, I didn't intend to make this type single valued on purpose, it’s just that my use case is single valued. I changed the field's configuration to multi value and it seems to work fine (facet, pivot, stats, return stored field). Why do you say the assumption is the type is restricted to single value? Thanks again. new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736990#comment-13736990 ] Elran Dvir commented on SOLR-5084: -- I failed attaching the new patch. I will attach it ASAP. The only changes are formatting. new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5084: - Attachment: Solr-5084.patch new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726151#comment-13726151 ] Elran Dvir commented on SOLR-5084: -- I reformatted the code. I hope it's OK now. Thanks. new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5084: - Attachment: Solr-5084.patch new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
Elran Dvir created SOLR-5084: Summary: new field type - EnumField Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5084: - Attachment: schema_example.xml enumsConfig.xml new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: enumsConfig.xml, schema_example.xml We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- 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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13719417#comment-13719417 ] Elran Dvir commented on SOLR-2894: -- I have downloaded the source code from Solr's website. Then opened it with my IDE: Intellij. when I tried applying the patch, Intellij reported there were problems with some files. Thanks. Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.5 Attachments: SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894-reworked.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13718122#comment-13718122 ] Elran Dvir commented on SOLR-2894: -- Hi Andrew, I have tried applying latest patch to 4.2.1 and there were a few problems. Which version does it apply to? Thanks. Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.5 Attachments: SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894-reworked.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13716169#comment-13716169 ] Elran Dvir commented on SOLR-2894: -- Andrew, Thank you very much for the fix! Does this version fix the issue of f.field.facet.limit not being respected? Thanks. Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.5 Attachments: SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894-reworked.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-4845) StatsComponent doesn't work if field's type is TextField
Elran Dvir created SOLR-4845:
Summary: StatsComponent doesn't work if field's type is TextField
Key: SOLR-4845
URL: https://issues.apache.org/jira/browse/SOLR-4845
Project: Solr
Issue Type: Improvement
Components: search
Affects Versions: 4.2.1
Reporter: Elran Dvir
StatsComponent doesn't work if field's type is TextField
I get the following message:
Field type
textstring{class=org.apache.solr.schema.TextField,analyzer=org.apache.solr.analysis.TokenizerChain,args={positionIncrementGap=100,
sortMissingLast=true}} is not currently supported.
Is there a plan to support it?
Thanks.
--
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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13661866#comment-13661866 ] Elran Dvir commented on SOLR-2894: -- Hi, I want to report a problem that we found in the patch of March 21st. It seems that the problem Shahar reported is now solved, but there is another similar problem. In short, the problem seems to be related to facet.limit per field definition and the symptom is that a distributed pivot returns less terms than expected. Here's a simple scenario: if I run a distributed pivot such as: http://myHost:8999/solr/core-B/select?shards=myHost:8999/solr/core-Aq=*:*wt=xmlfacet=truefacet.pivot=field_Arows=0facet.limit=-1facet.sort=index it will return exactly number of terms for field_A as expected. On the other hand, if I use f.field_name.facet.limit=-1: http://myHost:8999/solr/core-B/select?shards=myHost:8999/solr/core-Aq=*:*wt=xmlfacet=truefacet.pivot=field_Arows=0f.field_A.facet.limit=-1facet.sort=index then it will return at most 100 terms for field_A. I'll appreciate your help with this. Thanks. Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.4 Attachments: SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894-reworked.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-1782) stats.facet assumes FieldCache.StringIndex - fails horribly on multivalued fields
[ https://issues.apache.org/jira/browse/SOLR-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13653039#comment-13653039 ] Elran Dvir commented on SOLR-1782: -- Hi, I tried to apply the latest patch to 4.2.1 and it doesn't seem to be compatible. Do you plan a patch compatible to this version? Thanks. stats.facet assumes FieldCache.StringIndex - fails horribly on multivalued fields - Key: SOLR-1782 URL: https://issues.apache.org/jira/browse/SOLR-1782 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.4 Environment: reproduced on Win2k3 using 1.5.0-dev solr ($Id: CHANGES.txt 906924 2010-02-05 12:43:11Z noble $) Reporter: Gerald DeConto Assignee: Hoss Man Attachments: index.rar, SOLR-1782.2013-01-07.patch, SOLR-1782.2013-04-10.patch, SOLR-1782.2.patch, SOLR-1782.patch, SOLR-1782.patch, SOLR-1782.patch, SOLR-1782.test.patch the StatsComponent assumes any field specified in the stats.facet param can be faceted using FieldCache.DEFAULT.getStringIndex. This can cause problems with a variety of field types, but in the case of multivalued fields it can either cause erroneous false stats when the number of distinct values is small, or it can cause ArrayIndexOutOfBoundsException when the number of distinct values is greater then the number of documents. -- 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
