[jira] [Commented] (SOLR-9981) Multiple analytics fixes/performance improvements
[ https://issues.apache.org/jira/browse/SOLR-9981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063187#comment-16063187 ] Dennis Gove commented on SOLR-9981: --- Thanks [~steve_rowe]. Houston is taking a look. All tests passed when I ran with this patch on Saturday. Perhaps related to a seed choice. > Multiple analytics fixes/performance improvements > - > > Key: SOLR-9981 > URL: https://issues.apache.org/jira/browse/SOLR-9981 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Houston Putman >Assignee: Dennis Gove >Priority: Minor > Labels: patch > Fix For: master (7.0) > > Attachments: SOLR-9983.patch > > > Included are the following improvements/fixes: > * Improving the unit test case. > * Performance fix that stops the reading of ALL lucene segments over and > again for each stats collector. > ** The AtomicReaderContext that refers to the "current " segment is reused. > ** This fix shows an improvement of about 25% in query time for a dataset of > ~10M (=9.8M) records. > ** Given the nature of the fix, the improvement should get better as the > dataset increases. > * Fix for the NPE during comparison -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9981) Multiple analytics fixes/performance improvements
[ https://issues.apache.org/jira/browse/SOLR-9981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063516#comment-16063516 ] Dennis Gove commented on SOLR-9981: --- I am going to revert this change. > Multiple analytics fixes/performance improvements > - > > Key: SOLR-9981 > URL: https://issues.apache.org/jira/browse/SOLR-9981 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Houston Putman >Assignee: Dennis Gove >Priority: Minor > Labels: patch > Fix For: master (7.0) > > Attachments: SOLR-9983.patch > > > Included are the following improvements/fixes: > * Improving the unit test case. > * Performance fix that stops the reading of ALL lucene segments over and > again for each stats collector. > ** The AtomicReaderContext that refers to the "current " segment is reused. > ** This fix shows an improvement of about 25% in query time for a dataset of > ~10M (=9.8M) records. > ** Given the nature of the fix, the improvement should get better as the > dataset increases. > * Fix for the NPE during comparison -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-9981) Multiple analytics fixes/performance improvements
[ https://issues.apache.org/jira/browse/SOLR-9981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Gove reopened SOLR-9981: --- > Multiple analytics fixes/performance improvements > - > > Key: SOLR-9981 > URL: https://issues.apache.org/jira/browse/SOLR-9981 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Houston Putman >Assignee: Dennis Gove >Priority: Minor > Labels: patch > Fix For: master (7.0) > > Attachments: SOLR-9983.patch > > > Included are the following improvements/fixes: > * Improving the unit test case. > * Performance fix that stops the reading of ALL lucene segments over and > again for each stats collector. > ** The AtomicReaderContext that refers to the "current " segment is reused. > ** This fix shows an improvement of about 25% in query time for a dataset of > ~10M (=9.8M) records. > ** Given the nature of the fix, the improvement should get better as the > dataset increases. > * Fix for the NPE during comparison -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-9981) Multiple analytics fixes/performance improvements
[ https://issues.apache.org/jira/browse/SOLR-9981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Gove closed SOLR-9981. - Resolution: Won't Fix Fix Version/s: (was: master (7.0)) Closing as no fix as this is being dealt with in SOLR-10123. > Multiple analytics fixes/performance improvements > - > > Key: SOLR-9981 > URL: https://issues.apache.org/jira/browse/SOLR-9981 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Houston Putman >Assignee: Dennis Gove >Priority: Minor > Labels: patch > Attachments: SOLR-9983.patch > > > Included are the following improvements/fixes: > * Improving the unit test case. > * Performance fix that stops the reading of ALL lucene segments over and > again for each stats collector. > ** The AtomicReaderContext that refers to the "current " segment is reused. > ** This fix shows an improvement of about 25% in query time for a dataset of > ~10M (=9.8M) records. > ** Given the nature of the fix, the improvement should get better as the > dataset increases. > * Fix for the NPE during comparison -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10123) Analytics Component 2.0
[ https://issues.apache.org/jira/browse/SOLR-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Gove updated SOLR-10123: --- Attachment: SOLR-10123.patch This is the current patch. It appears to have failing tests and precommit issues. Houston is working on both. > Analytics Component 2.0 > --- > > Key: SOLR-10123 > URL: https://issues.apache.org/jira/browse/SOLR-10123 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Houston Putman > Labels: features > Attachments: SOLR-10123.patch, SOLR-10123.patch > > > A completely redesigned Analytics Component, introducing the following > features: > * Support for distributed collections > * New JSON request language, and response format that fits JSON better. > * Faceting over mapping functions in addition to fields (Value Faceting) > * PivotFaceting with ValueFacets > * More advanced facet sorting > * Support for PointField types > * Expressions over multi-valued fields > * New types of mapping functions > ** Logical > ** Conditional > ** Comparison > * Concurrent request execution > * Custom user functions, defined within the request > Fully backwards compatible with the orifinal Analytics Component with the > following exceptions: > * All fields used must have doc-values enabled > * Expression results can no longer be used when defining Range and Query > facets > * The reverse(string) mapping function is no longer a native function -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-9981) Multiple analytics fixes/performance improvements
[ https://issues.apache.org/jira/browse/SOLR-9981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Gove closed SOLR-9981. - Resolution: Fixed Fix Version/s: master (7.0) > Multiple analytics fixes/performance improvements > - > > Key: SOLR-9981 > URL: https://issues.apache.org/jira/browse/SOLR-9981 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Houston Putman >Assignee: Dennis Gove >Priority: Minor > Labels: patch > Fix For: master (7.0) > > Attachments: SOLR-9983.patch > > > Included are the following improvements/fixes: > * Improving the unit test case. > * Performance fix that stops the reading of ALL lucene segments over and > again for each stats collector. > ** The AtomicReaderContext that refers to the "current " segment is reused. > ** This fix shows an improvement of about 25% in query time for a dataset of > ~10M (=9.8M) records. > ** Given the nature of the fix, the improvement should get better as the > dataset increases. > * Fix for the NPE during comparison -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10292) Add cartesian Streaming Expression to build cartesian products from multi-value fields and text fields
[ https://issues.apache.org/jira/browse/SOLR-10292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16018223#comment-16018223 ] Dennis Gove commented on SOLR-10292: [~varunthacker], thank you. I've corrected this. > Add cartesian Streaming Expression to build cartesian products from > multi-value fields and text fields > -- > > Key: SOLR-10292 > URL: https://issues.apache.org/jira/browse/SOLR-10292 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein > Fix For: 6.6 > > Attachments: SOLR-10292.patch, SOLR-10292.patch, SOLR-10292.patch, > SOLR-10292.patch, SOLR-10292.patch > > > Currently all the Streaming Expression such as rollups, intersections, fetch > etc, work on single value fields. The *cartesian* expression would create a > stream of tuples from a single tuple with a multi-value field. This would > allow multi-valued fields to be operated on by the wider library of Streaming > Expression. > For example a single tuple with a multi-valued field: > id: 1 > author: [Jim, Jack, Steve] > Would be transformed in the following three tuples: > id:1 > author:Jim > id:1 > author:Jack > id:1 > author:Steve -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-10292) Add cartesian Streaming Expression to build cartesian products from multi-value fields and text fields
[ https://issues.apache.org/jira/browse/SOLR-10292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Gove closed SOLR-10292. -- Resolution: Fixed Fix Version/s: 6.6 > Add cartesian Streaming Expression to build cartesian products from > multi-value fields and text fields > -- > > Key: SOLR-10292 > URL: https://issues.apache.org/jira/browse/SOLR-10292 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein > Fix For: 6.6 > > Attachments: SOLR-10292.patch, SOLR-10292.patch, SOLR-10292.patch, > SOLR-10292.patch, SOLR-10292.patch > > > Currently all the Streaming Expression such as rollups, intersections, fetch > etc, work on single value fields. The *cartesian* expression would create a > stream of tuples from a single tuple with a multi-value field. This would > allow multi-valued fields to be operated on by the wider library of Streaming > Expression. > For example a single tuple with a multi-valued field: > id: 1 > author: [Jim, Jack, Steve] > Would be transformed in the following three tuples: > id:1 > author:Jim > id:1 > author:Jack > id:1 > author:Steve -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10753) Add array Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026326#comment-16026326
]
Dennis Gove commented on SOLR-10753:
Could it just be a thing that returns an list of objects? Then it's up to the
container to handle whatever they are.
{code}
list(1,2,3,4)
list(1,add(2,3),if(gt(a,b),a,b))
list(1,"foo", search())
{code}
Basically, a single function that creates a list/array of whatever. It is up to
the containing function to decide if the list is valid for its purpose. For
example,
{code}
add(1, list(2,3,4,5)) is the same as add(1,2,3,4,5)
add(1, list("foo","bar")) is deemed invalid
{code}
And map with a list would allow things like
{code}
map(add(1,?), over=list(2,3,4,5)) would result in list(1 + 2, 1 + 3, 1 + 4, 1 +
5)
{code}
> Add array Stream Evaluator
> --
>
> Key: SOLR-10753
> URL: https://issues.apache.org/jira/browse/SOLR-10753
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (7.0)
>
> Attachments: SOLR-10753.patch
>
>
> The *array* Stream Evaluator returns an array of numbers. It can contain
> numbers and evaluators that return numbers.
> Syntax:
> {code}
> a = array(1, 2, 3, 4, 5, 6)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10753) Add array Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026348#comment-16026348
]
Dennis Gove commented on SOLR-10753:
The array itself isn't doing the vector math operations, though. Right? I'd
think it'd be up to the function doing the math operation to validate its
input, which means accepting a list that could be filled with anything is
alright - cause it'll be validated anyway.
I'm concerned that there'll end up being a lot of very similar things used for
very different reasons. And users will be confused about when to use which.
> Add array Stream Evaluator
> --
>
> Key: SOLR-10753
> URL: https://issues.apache.org/jira/browse/SOLR-10753
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (7.0)
>
> Attachments: SOLR-10753.patch
>
>
> The *array* Stream Evaluator returns an array of numbers. It can contain
> numbers and evaluators that return numbers.
> Syntax:
> {code}
> a = array(1, 2, 3, 4, 5, 6)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10753) Add array Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026388#comment-16026388
]
Dennis Gove commented on SOLR-10753:
Maybe merge should support and inOrder option which doesn't maintain sort
between the streams.
> Add array Stream Evaluator
> --
>
> Key: SOLR-10753
> URL: https://issues.apache.org/jira/browse/SOLR-10753
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (7.0)
>
> Attachments: SOLR-10753.patch
>
>
> The *array* Stream Evaluator returns an array of numbers. It can contain
> numbers and evaluators that return numbers.
> Syntax:
> {code}
> a = array(1, 2, 3, 4, 5, 6)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10753) Add array Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026375#comment-16026375
]
Dennis Gove commented on SOLR-10753:
If that's the case, isn't it the same as
[merge|https://cwiki.apache.org/confluence/display/solr/Streaming+Expressions#StreamingExpressions-merge]?
> Add array Stream Evaluator
> --
>
> Key: SOLR-10753
> URL: https://issues.apache.org/jira/browse/SOLR-10753
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (7.0)
>
> Attachments: SOLR-10753.patch
>
>
> The *array* Stream Evaluator returns an array of numbers. It can contain
> numbers and evaluators that return numbers.
> Syntax:
> {code}
> a = array(1, 2, 3, 4, 5, 6)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10882) Restructure and Cleanup Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-10882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047905#comment-16047905 ] Dennis Gove commented on SOLR-10882: Working branch can be found at https://github.com/dennisgove/lucene-solr/tree/SOLR-10882 > Restructure and Cleanup Stream Evaluators > - > > Key: SOLR-10882 > URL: https://issues.apache.org/jira/browse/SOLR-10882 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dennis Gove > > There are a suite of new Stream Evaluators that I'd like to cleanup and > restructure prior to the cutting of v7. This ticket is to track that progress. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10882) Restructure and Cleanup Stream Evaluators
Dennis Gove created SOLR-10882: -- Summary: Restructure and Cleanup Stream Evaluators Key: SOLR-10882 URL: https://issues.apache.org/jira/browse/SOLR-10882 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Dennis Gove There are a suite of new Stream Evaluators that I'd like to cleanup and restructure prior to the cutting of v7. This ticket is to track that progress. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10882) Restructure and Cleanup Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-10882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Gove updated SOLR-10882: --- Attachment: SOLR-10882.patch Changes so far. > Restructure and Cleanup Stream Evaluators > - > > Key: SOLR-10882 > URL: https://issues.apache.org/jira/browse/SOLR-10882 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dennis Gove > Attachments: SOLR-10882.patch > > > There are a suite of new Stream Evaluators that I'd like to cleanup and > restructure prior to the cutting of v7. This ticket is to track that progress. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10617) JDBCStream: support more data types
[
https://issues.apache.org/jira/browse/SOLR-10617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001842#comment-16001842
]
Dennis Gove commented on SOLR-10617:
I've only taken a quick look at this point, but I do want to point this out.
{code}
} else if (jdbcType == Types.DATE || jdbcType == Types.TIME || jdbcType ==
Types.TIMESTAMP) {
valueSelectors[columnIdx] = new ResultSetValueSelector() {
public Object selectValue(ResultSet resultSet) throws SQLException {
if (jdbcType == Types.TIME) {
Time sqlTime = resultSet.getTime(columnNumber);
return resultSet.wasNull() ? null : sqlTime.toString();
} else if (jdbcType == Types.DATE) {
Date sqlDate = resultSet.getDate(columnNumber);
return resultSet.wasNull() ? null : sqlDate.toString();
} else {
Timestamp sqlTimestamp = resultSet.getTimestamp(columnNumber);
return resultSet.wasNull() ? null : sqlTimestamp.toInstant().toString();
}
}
public String getColumnName() {
return columnName;
}
};
}
{code}
The value selectors are constructed on open so that we can avoid executing the
same conditional check on each row in the result set. By putting the jdbc type
check inside of selectValue it is now repeating the same conditional for each
row, even though every row will end up going down the same path.
While splitting these checks up does result in repeated code, the performance
saving is well worth it.
> JDBCStream: support more data types
> ---
>
> Key: SOLR-10617
> URL: https://issues.apache.org/jira/browse/SOLR-10617
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Attachments: SOLR-10617.patch
>
>
> It would be nice if JDBCStream could support Decimal types as well as
> Timestamp-related types, and CLOBs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-11145) Comprehensive Unit Tests for the Analytics Component
[ https://issues.apache.org/jira/browse/SOLR-11145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Gove reassigned SOLR-11145: -- Assignee: Dennis Gove > Comprehensive Unit Tests for the Analytics Component > > > Key: SOLR-11145 > URL: https://issues.apache.org/jira/browse/SOLR-11145 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.1 >Reporter: Houston Putman >Assignee: Dennis Gove >Priority: Critical > Fix For: 7.0 > > > Adding comprehensive unit tests for the new Analytics Component. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-11146) Analytics Component 2.0 Bug Fixes
[ https://issues.apache.org/jira/browse/SOLR-11146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Gove reassigned SOLR-11146: -- Assignee: Dennis Gove > Analytics Component 2.0 Bug Fixes > - > > Key: SOLR-11146 > URL: https://issues.apache.org/jira/browse/SOLR-11146 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.1 >Reporter: Houston Putman >Assignee: Dennis Gove >Priority: Blocker > Fix For: 7.0 > > > The new Analytics Component has several small bugs in mapping functions and > other places. This ticket is a fix for a large number of them. This patch > should allow all unit tests created in SOLR-11145 to pass. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11283) Refactor all Stream Evaluators in solrj.io.eval to simplify them
[
https://issues.apache.org/jira/browse/SOLR-11283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Gove updated SOLR-11283:
---
Attachment: SOLR-11283.patch
All stream related tests pass.
The following 3 tests failed but appear to be completely unrelated to my
changes.
{code}
[junit4] Tests with failures [seed: EE1F61CDA04C3749]:
[junit4] - org.apache.solr.cloud.HttpPartitionTest.test
[junit4] - org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader
[junit4] -
org.apache.solr.update.processor.UpdateRequestProcessorFactoryTest.testUpdateDistribChainSkipping
{code}
When run individually those tests pass.
> Refactor all Stream Evaluators in solrj.io.eval to simplify them
>
>
> Key: SOLR-11283
> URL: https://issues.apache.org/jira/browse/SOLR-11283
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Dennis Gove
>Assignee: Dennis Gove
> Attachments: SOLR-11283.patch, SOLR-11283.patch
>
>
> As Stream Evaluators have been evolving we are seeing a need to better handle
> differing types of data within evaluators. For example, allowing some to
> evaluate over individual values or arrays of values, like
> {code}
> sin(a)
> sin(a,b,c,d)
> sin([a,b,c,d])
> {code}
> The current structure of Evaluators makes this difficult and repetitive work.
> Also, the hierarchy of classes behind evaluators can be confusing for
> developers creating new evaluators. For example, when to use a
> ComplexEvaluator vs a BooleanEvaluator.
> A full refactoring of these classes will greatly enhance the usability and
> future evolution of evaluators.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11283) Refactor all Stream Evaluators in solrj.io.eval to simplify them
[
https://issues.apache.org/jira/browse/SOLR-11283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16139070#comment-16139070
]
Dennis Gove commented on SOLR-11283:
I should add, this patch has a bunch of new tests marked to fail with
NotImplementedException. I intend to implement these tests before committing.
> Refactor all Stream Evaluators in solrj.io.eval to simplify them
>
>
> Key: SOLR-11283
> URL: https://issues.apache.org/jira/browse/SOLR-11283
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Dennis Gove
>Assignee: Dennis Gove
> Attachments: SOLR-11283.patch
>
>
> As Stream Evaluators have been evolving we are seeing a need to better handle
> differing types of data within evaluators. For example, allowing some to
> evaluate over individual values or arrays of values, like
> {code}
> sin(a)
> sin(a,b,c,d)
> sin([a,b,c,d])
> {code}
> The current structure of Evaluators makes this difficult and repetitive work.
> Also, the hierarchy of classes behind evaluators can be confusing for
> developers creating new evaluators. For example, when to use a
> ComplexEvaluator vs a BooleanEvaluator.
> A full refactoring of these classes will greatly enhance the usability and
> future evolution of evaluators.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11283) Refactor all Stream Evaluators in solrj.io.eval to simplify them
[
https://issues.apache.org/jira/browse/SOLR-11283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Gove updated SOLR-11283:
---
Attachment: SOLR-11283.patch
Full patch. All evaluator and stream related tests pass. Have not yet run full
tests or precommit checks.
All evaluators are backward compatible in functionality and name/parameters,
except for addAll which has been renamed to append.
> Refactor all Stream Evaluators in solrj.io.eval to simplify them
>
>
> Key: SOLR-11283
> URL: https://issues.apache.org/jira/browse/SOLR-11283
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Dennis Gove
>Assignee: Dennis Gove
> Attachments: SOLR-11283.patch
>
>
> As Stream Evaluators have been evolving we are seeing a need to better handle
> differing types of data within evaluators. For example, allowing some to
> evaluate over individual values or arrays of values, like
> {code}
> sin(a)
> sin(a,b,c,d)
> sin([a,b,c,d])
> {code}
> The current structure of Evaluators makes this difficult and repetitive work.
> Also, the hierarchy of classes behind evaluators can be confusing for
> developers creating new evaluators. For example, when to use a
> ComplexEvaluator vs a BooleanEvaluator.
> A full refactoring of these classes will greatly enhance the usability and
> future evolution of evaluators.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11283) Refactor all Stream Evaluators in solrj.io.eval to simplify them
Dennis Gove created SOLR-11283:
--
Summary: Refactor all Stream Evaluators in solrj.io.eval to
simplify them
Key: SOLR-11283
URL: https://issues.apache.org/jira/browse/SOLR-11283
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Dennis Gove
Assignee: Dennis Gove
As Stream Evaluators have been evolving we are seeing a need to better handle
differing types of data within evaluators. For example, allowing some to
evaluate over individual values or arrays of values, like
{code}
sin(a)
sin(a,b,c,d)
sin([a,b,c,d])
{code}
The current structure of Evaluators makes this difficult and repetitive work.
Also, the hierarchy of classes behind evaluators can be confusing for
developers creating new evaluators. For example, when to use a ComplexEvaluator
vs a BooleanEvaluator.
A full refactoring of these classes will greatly enhance the usability and
future evolution of evaluators.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11145) Comprehensive Unit Tests for the Analytics Component
[ https://issues.apache.org/jira/browse/SOLR-11145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Gove resolved SOLR-11145. Resolution: Fixed Fix Version/s: (was: 7.0) 7.2 > Comprehensive Unit Tests for the Analytics Component > > > Key: SOLR-11145 > URL: https://issues.apache.org/jira/browse/SOLR-11145 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.1 >Reporter: Houston Putman >Assignee: Dennis Gove >Priority: Critical > Fix For: 7.2 > > > Adding comprehensive unit tests for the new Analytics Component. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11146) Analytics Component 2.0 Bug Fixes
[ https://issues.apache.org/jira/browse/SOLR-11146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Gove resolved SOLR-11146. Resolution: Fixed Fix Version/s: (was: 7.0) 7.2 > Analytics Component 2.0 Bug Fixes > - > > Key: SOLR-11146 > URL: https://issues.apache.org/jira/browse/SOLR-11146 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.1 >Reporter: Houston Putman >Assignee: Dennis Gove >Priority: Blocker > Fix For: 7.2 > > > The new Analytics Component has several small bugs in mapping functions and > other places. This ticket is a fix for a large number of them. This patch > should allow all unit tests created in SOLR-11145 to pass. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12355) HashJoinStream's use of String::hashCode results in non-matching tuples being considered matches
[
https://issues.apache.org/jira/browse/SOLR-12355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475055#comment-16475055
]
Dennis Gove commented on SOLR-12355:
I have a fix for this where instead of calculating the string value's hashCode
we just use the string value as the key in the hashed set of tuples. I'm
creating a few test cases to verify this gives us what we want.
> HashJoinStream's use of String::hashCode results in non-matching tuples being
> considered matches
>
>
> Key: SOLR-12355
> URL: https://issues.apache.org/jira/browse/SOLR-12355
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 6.0
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Major
>
> The following strings have been found to have hashCode conflicts and as such
> can result in HashJoinStream considering two tuples with fields of these
> values to be considered the same.
> {code:java}
> "MG!!00TNGP::Mtge::".hashCode() == "MG!!00TNH1::Mtge::".hashCode() {code}
> This means these two tuples are the same if we're comparing on field "foo"
> {code:java}
> {
> "foo":"MG!!00TNGP::Mtge::"
> }
> {
> "foo":"MG!!00TNH1::Mtge::"
> }
> {code}
> and these two tuples are the same if we're comparing on fields "foo,bar"
> {code:java}
> {
> "foo":"MG!!00TNGP"
> "bar":"Mtge"
> }
> {
> "foo":"MG!!00TNH1"
> "bar":"Mtge"
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12355) HashJoinStream's use of String::hashCode results in non-matching tuples being considered matches
[
https://issues.apache.org/jira/browse/SOLR-12355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475060#comment-16475060
]
Dennis Gove commented on SOLR-12355:
This also impacts OuterHashJoinStream.
> HashJoinStream's use of String::hashCode results in non-matching tuples being
> considered matches
>
>
> Key: SOLR-12355
> URL: https://issues.apache.org/jira/browse/SOLR-12355
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 6.0
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Major
>
> The following strings have been found to have hashCode conflicts and as such
> can result in HashJoinStream considering two tuples with fields of these
> values to be considered the same.
> {code:java}
> "MG!!00TNGP::Mtge::".hashCode() == "MG!!00TNH1::Mtge::".hashCode() {code}
> This means these two tuples are the same if we're comparing on field "foo"
> {code:java}
> {
> "foo":"MG!!00TNGP::Mtge::"
> }
> {
> "foo":"MG!!00TNH1::Mtge::"
> }
> {code}
> and these two tuples are the same if we're comparing on fields "foo,bar"
> {code:java}
> {
> "foo":"MG!!00TNGP"
> "bar":"Mtge"
> }
> {
> "foo":"MG!!00TNH1"
> "bar":"Mtge"
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12355) HashJoinStream's use of String::hashCode results in non-matching tuples being considered matches
Dennis Gove created SOLR-12355:
--
Summary: HashJoinStream's use of String::hashCode results in
non-matching tuples being considered matches
Key: SOLR-12355
URL: https://issues.apache.org/jira/browse/SOLR-12355
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrJ
Affects Versions: 6.0
Reporter: Dennis Gove
Assignee: Dennis Gove
The following strings have been found to have hashCode conflicts and as such
can result in HashJoinStream considering two tuples with fields of these values
to be considered the same.
{code:java}
"MG!!00TNGP::Mtge::".hashCode() == "MG!!00TNH1::Mtge::".hashCode() {code}
This means these two tuples are the same if we're comparing on field "foo"
{code:java}
{
"foo":"MG!!00TNGP::Mtge::"
}
{
"foo":"MG!!00TNH1::Mtge::"
}
{code}
and these two tuples are the same if we're comparing on fields "foo,bar"
{code:java}
{
"foo":"MG!!00TNGP"
"bar":"Mtge"
}
{
"foo":"MG!!00TNH1"
"bar":"Mtge"
}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12355) HashJoinStream's use of String::hashCode results in non-matching tuples being considered matches
[
https://issues.apache.org/jira/browse/SOLR-12355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475973#comment-16475973
]
Dennis Gove commented on SOLR-12355:
Initial patch attached. I have not yet run the full suite of tests against this.
> HashJoinStream's use of String::hashCode results in non-matching tuples being
> considered matches
>
>
> Key: SOLR-12355
> URL: https://issues.apache.org/jira/browse/SOLR-12355
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 6.0
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Major
> Attachments: SOLR-12355.patch
>
>
> The following strings have been found to have hashCode conflicts and as such
> can result in HashJoinStream considering two tuples with fields of these
> values to be considered the same.
> {code:java}
> "MG!!00TNGP::Mtge::".hashCode() == "MG!!00TNH1::Mtge::".hashCode() {code}
> This means these two tuples are the same if we're comparing on field "foo"
> {code:java}
> {
> "foo":"MG!!00TNGP::Mtge::"
> }
> {
> "foo":"MG!!00TNH1::Mtge::"
> }
> {code}
> and these two tuples are the same if we're comparing on fields "foo,bar"
> {code:java}
> {
> "foo":"MG!!00TNGP"
> "bar":"Mtge"
> }
> {
> "foo":"MG!!00TNH1"
> "bar":"Mtge"
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12355) HashJoinStream's use of String::hashCode results in non-matching tuples being considered matches
[
https://issues.apache.org/jira/browse/SOLR-12355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Gove updated SOLR-12355:
---
Attachment: SOLR-12355.patch
> HashJoinStream's use of String::hashCode results in non-matching tuples being
> considered matches
>
>
> Key: SOLR-12355
> URL: https://issues.apache.org/jira/browse/SOLR-12355
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 6.0
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Major
> Attachments: SOLR-12355.patch
>
>
> The following strings have been found to have hashCode conflicts and as such
> can result in HashJoinStream considering two tuples with fields of these
> values to be considered the same.
> {code:java}
> "MG!!00TNGP::Mtge::".hashCode() == "MG!!00TNH1::Mtge::".hashCode() {code}
> This means these two tuples are the same if we're comparing on field "foo"
> {code:java}
> {
> "foo":"MG!!00TNGP::Mtge::"
> }
> {
> "foo":"MG!!00TNH1::Mtge::"
> }
> {code}
> and these two tuples are the same if we're comparing on fields "foo,bar"
> {code:java}
> {
> "foo":"MG!!00TNGP"
> "bar":"Mtge"
> }
> {
> "foo":"MG!!00TNH1"
> "bar":"Mtge"
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-12271) Analytics Component reads negative float and double field values incorrectly
[ https://issues.apache.org/jira/browse/SOLR-12271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Gove reassigned SOLR-12271: -- Assignee: Dennis Gove > Analytics Component reads negative float and double field values incorrectly > > > Key: SOLR-12271 > URL: https://issues.apache.org/jira/browse/SOLR-12271 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.3.1, 7.4, master (8.0) >Reporter: Houston Putman >Assignee: Dennis Gove >Priority: Major > Fix For: 7.4, master (8.0) > > Time Spent: 10m > Remaining Estimate: 0h > > Currently the analytics component uses the incorrect way of converting > numeric doc values longs to doubles and floats. > The fix is easy and the tests now cover this use case. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12355) HashJoinStream's use of String::hashCode results in non-matching tuples being considered matches
[
https://issues.apache.org/jira/browse/SOLR-12355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Gove resolved SOLR-12355.
Resolution: Fixed
Fix Version/s: 7.4
> HashJoinStream's use of String::hashCode results in non-matching tuples being
> considered matches
>
>
> Key: SOLR-12355
> URL: https://issues.apache.org/jira/browse/SOLR-12355
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 6.0
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12355.patch, SOLR-12355.patch
>
>
> The following strings have been found to have hashCode conflicts and as such
> can result in HashJoinStream considering two tuples with fields of these
> values to be considered the same.
> {code:java}
> "MG!!00TNGP::Mtge::".hashCode() == "MG!!00TNH1::Mtge::".hashCode() {code}
> This means these two tuples are the same if we're comparing on field "foo"
> {code:java}
> {
> "foo":"MG!!00TNGP::Mtge::"
> }
> {
> "foo":"MG!!00TNH1::Mtge::"
> }
> {code}
> and these two tuples are the same if we're comparing on fields "foo,bar"
> {code:java}
> {
> "foo":"MG!!00TNGP"
> "bar":"Mtge"
> }
> {
> "foo":"MG!!00TNH1"
> "bar":"Mtge"
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12355) HashJoinStream's use of String::hashCode results in non-matching tuples being considered matches
[
https://issues.apache.org/jira/browse/SOLR-12355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Gove updated SOLR-12355:
---
Attachment: SOLR-12355.patch
> HashJoinStream's use of String::hashCode results in non-matching tuples being
> considered matches
>
>
> Key: SOLR-12355
> URL: https://issues.apache.org/jira/browse/SOLR-12355
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 6.0
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Major
> Attachments: SOLR-12355.patch, SOLR-12355.patch
>
>
> The following strings have been found to have hashCode conflicts and as such
> can result in HashJoinStream considering two tuples with fields of these
> values to be considered the same.
> {code:java}
> "MG!!00TNGP::Mtge::".hashCode() == "MG!!00TNH1::Mtge::".hashCode() {code}
> This means these two tuples are the same if we're comparing on field "foo"
> {code:java}
> {
> "foo":"MG!!00TNGP::Mtge::"
> }
> {
> "foo":"MG!!00TNH1::Mtge::"
> }
> {code}
> and these two tuples are the same if we're comparing on fields "foo,bar"
> {code:java}
> {
> "foo":"MG!!00TNGP"
> "bar":"Mtge"
> }
> {
> "foo":"MG!!00TNH1"
> "bar":"Mtge"
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12271) Analytics Component reads negative float and double field values incorrectly
[ https://issues.apache.org/jira/browse/SOLR-12271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Gove resolved SOLR-12271. Resolution: Fixed > Analytics Component reads negative float and double field values incorrectly > > > Key: SOLR-12271 > URL: https://issues.apache.org/jira/browse/SOLR-12271 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.4, master (8.0) >Reporter: Houston Putman >Assignee: Dennis Gove >Priority: Major > Fix For: 7.4, master (8.0) > > Time Spent: 10m > Remaining Estimate: 0h > > Currently the analytics component uses the incorrect way of converting > numeric doc values longs to doubles and floats. > The fix is easy and the tests now cover this use case. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10512) Innerjoin streaming expressions - Invalid JoinStream error
[
https://issues.apache.org/jira/browse/SOLR-10512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16392851#comment-16392851
]
Dennis Gove commented on SOLR-10512:
It was certainly designed such that the left field in the on clause is the
field from the first incoming stream and the right field in the on clause is
the field from the second incoming stream. If that is not occurring then this
is a very clear bug.
> Innerjoin streaming expressions - Invalid JoinStream error
> --
>
> Key: SOLR-10512
> URL: https://issues.apache.org/jira/browse/SOLR-10512
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
>Affects Versions: 6.4.2, 6.5
> Environment: Debian Jessie
>Reporter: Dominique Béjean
>Priority: Major
>
> It looks like innerJoin streaming expression do not work as explained in
> documentation. An invalid JoinStream error occurs.
> {noformat}
> curl --data-urlencode 'expr=innerJoin(
> search(books,
>q="*:*",
>fl="id",
>sort="id asc"),
> searchreviews,
>q="*:*",
>fl="id_book_s",
>sort="id_book_s asc"),
> on="id=id_books_s"
> )' http://localhost:8983/solr/books/stream
>
> {"result-set":{"docs":[{"EXCEPTION":"Invalid JoinStream - all incoming stream
> comparators (sort) must be a superset of this stream's
> equalitor.","EOF":true}]}}
> {noformat}
> It is tottaly similar to the documentation example
>
> {noformat}
> innerJoin(
> search(people, q=*:*, fl="personId,name", sort="personId asc"),
> search(pets, q=type:cat, fl="ownerId,petName", sort="ownerId asc"),
> on="personId=ownerId"
> )
> {noformat}
> Queries on each collection give :
> {noformat}
> $ curl --data-urlencode 'expr=search(books,
>q="*:*",
>fl="id, title_s, pubyear_i",
>sort="pubyear_i asc",
>qt="/export")'
> http://localhost:8983/solr/books/stream
> {
> "result-set": {
> "docs": [
> {
> "title_s": "Friends",
> "pubyear_i": 1994,
> "id": "book2"
> },
> {
> "title_s": "The Way of Kings",
> "pubyear_i": 2010,
> "id": "book1"
> },
> {
> "EOF": true,
> "RESPONSE_TIME": 16
> }
> ]
> }
> }
> $ curl --data-urlencode 'expr=search(reviews,
>q="author_s:d*",
>fl="id, id_book_s, stars_i, review_dt",
>sort="id_book_s asc",
>qt="/export")'
> http://localhost:8983/solr/reviews/stream
>
> {
> "result-set": {
> "docs": [
> {
> "stars_i": 3,
> "id": "book1_c2",
> "id_book_s": "book1",
> "review_dt": "2014-03-15T12:00:00Z"
> },
> {
> "stars_i": 4,
> "id": "book1_c3",
> "id_book_s": "book1",
> "review_dt": "2014-12-15T12:00:00Z"
> },
> {
> "stars_i": 3,
> "id": "book2_c2",
> "id_book_s": "book2",
> "review_dt": "1994-03-15T12:00:00Z"
> },
> {
> "stars_i": 4,
> "id": "book2_c3",
> "id_book_s": "book2",
> "review_dt": "1994-12-15T12:00:00Z"
> },
> {
> "EOF": true,
> "RESPONSE_TIME": 47
> }
> ]
> }
> }
> {noformat}
> After more tests, I just had to invert the "on" clause to make it work
> {noformat}
> curl --data-urlencode 'expr=innerJoin(
> search(books,
>q="*:*",
>fl="id",
>sort="id asc"),
> searchreviews,
>q="*:*",
>fl="id_book_s",
>sort="id_book_s asc"),
> on="id_books_s=id"
> )' http://localhost:8983/solr/books/stream
>
> {
> "result-set": {
> "docs": [
> {
> "title_s": "The Way of Kings",
> "pubyear_i": 2010,
> "stars_i": 5,
> "id": "book1",
>
[jira] [Resolved] (SOLR-11924) Add the ability to watch collection set changes in ZkStateReader
[ https://issues.apache.org/jira/browse/SOLR-11924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Gove resolved SOLR-11924. Resolution: Fixed Assignee: Dennis Gove Fix Version/s: (was: master (8.0)) > Add the ability to watch collection set changes in ZkStateReader > > > Key: SOLR-11924 > URL: https://issues.apache.org/jira/browse/SOLR-11924 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 7.4, master (8.0) >Reporter: Houston Putman >Assignee: Dennis Gove >Priority: Minor > Fix For: 7.4 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Allow users to watch when the set of collections for a cluster is changed. > This is useful if a user is trying to discover collections within a cloud. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11914) Remove/move questionable SolrParams methods
[
https://issues.apache.org/jira/browse/SOLR-11914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16440179#comment-16440179
]
Dennis Gove commented on SOLR-11914:
I agree with [~dsmiley] - the code in the streaming classes appears to be an
oddly round-about way of doing things. The changes you've made here appear to
be a much better approach.
> Remove/move questionable SolrParams methods
> ---
>
> Key: SOLR-11914
> URL: https://issues.apache.org/jira/browse/SOLR-11914
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Reporter: David Smiley
>Priority: Minor
> Labels: newdev
> Attachments: SOLR-11914.patch
>
>
> {{Map getAll(Map sink, Collection
> params)}}
> Is only used by the CollectionsHandler, and has particular rules about how it
> handles multi-valued data that make it not very generic, and thus I think
> doesn't belong here. Furthermore the existence of this method is confusing
> in that it gives the user another choice against it use versus toMap (there
> are two overloaded variants).
> {{SolrParams toFilteredSolrParams(List names)}}
> Is only called in one place, and something about it bothers me, perhaps just
> the name or that it ought to be a view maybe.
> {{static Map toMap(NamedList params)}}
> Isn't used and I don't like it; it doesn't even involve a SolrParams! Legacy
> of 2006.
> {{static Map toMultiMap(NamedList params)}}
> It doesn't even involve a SolrParams! Legacy of 2006 with some updates since.
> Used in some places. Perhaps should be moved to NamedList as an instance
> method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
