[jira] [Commented] (SOLR-13542) Code cleanup - Avoid using stream filter count where possible
[
https://issues.apache.org/jira/browse/SOLR-13542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917183#comment-16917183
]
Tomás Fernández Löbbe commented on SOLR-13542:
--
I moved the CHANGES entry to 8.3 and merged to both branches
> Code cleanup - Avoid using stream filter count where possible
> -
>
> Key: SOLR-13542
> URL: https://issues.apache.org/jira/browse/SOLR-13542
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
>Reporter: Koen De Groote
>Priority: Trivial
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This is another ticket in the logic of
> https://issues.apache.org/jira/browse/LUCENE-8847
>
> Not a feature, not serious, don't review this when you could be reviewing
> actual features or critical bugs, don't want to take your time away with this.
>
> Intellij's static code analysis bumped into this.
>
> I also saw most other instances in the code where such a filter needed to
> happen already used
> {code:java}
> anyMatch{code}
> instead of count(). So I applied the suggested fixes. Code cleanup and
> potentially a small performance gain. As far as my understanding goes, since
> it is not a simple count that's happening, there's no known size for the
> evaluator to return and as such it has to iterate over the entire collection.
> Whereas anyMatch and noneMatch will use the predicate to stop the instance
> the condition is met.
> It just so happens that all affected instances exist within the SolrJ
> namespace.
>
> All tests have run, all succeed.
>
> EDIT: Github PR: https://github.com/apache/lucene-solr/pull/717
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13542) Code cleanup - Avoid using stream filter count where possible
[
https://issues.apache.org/jira/browse/SOLR-13542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917179#comment-16917179
]
ASF subversion and git services commented on SOLR-13542:
Commit 5aa9a02421820fa3717fde1edf9effa8e5161191 in lucene-solr's branch
refs/heads/branch_8x from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5aa9a02 ]
SOLR-13542: Move CHANGES entry to 8.3. Added contributor
> Code cleanup - Avoid using stream filter count where possible
> -
>
> Key: SOLR-13542
> URL: https://issues.apache.org/jira/browse/SOLR-13542
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
>Reporter: Koen De Groote
>Priority: Trivial
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This is another ticket in the logic of
> https://issues.apache.org/jira/browse/LUCENE-8847
>
> Not a feature, not serious, don't review this when you could be reviewing
> actual features or critical bugs, don't want to take your time away with this.
>
> Intellij's static code analysis bumped into this.
>
> I also saw most other instances in the code where such a filter needed to
> happen already used
> {code:java}
> anyMatch{code}
> instead of count(). So I applied the suggested fixes. Code cleanup and
> potentially a small performance gain. As far as my understanding goes, since
> it is not a simple count that's happening, there's no known size for the
> evaluator to return and as such it has to iterate over the entire collection.
> Whereas anyMatch and noneMatch will use the predicate to stop the instance
> the condition is met.
> It just so happens that all affected instances exist within the SolrJ
> namespace.
>
> All tests have run, all succeed.
>
> EDIT: Github PR: https://github.com/apache/lucene-solr/pull/717
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13542) Code cleanup - Avoid using stream filter count where possible
[
https://issues.apache.org/jira/browse/SOLR-13542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917163#comment-16917163
]
ASF subversion and git services commented on SOLR-13542:
Commit 7b589ad7699a7318df4a4267db736e7ac1f7e7e8 in lucene-solr's branch
refs/heads/master from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7b589ad ]
SOLR-13542: Move CHANGES entry to 8.3. Added contributor
> Code cleanup - Avoid using stream filter count where possible
> -
>
> Key: SOLR-13542
> URL: https://issues.apache.org/jira/browse/SOLR-13542
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
>Reporter: Koen De Groote
>Priority: Trivial
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This is another ticket in the logic of
> https://issues.apache.org/jira/browse/LUCENE-8847
>
> Not a feature, not serious, don't review this when you could be reviewing
> actual features or critical bugs, don't want to take your time away with this.
>
> Intellij's static code analysis bumped into this.
>
> I also saw most other instances in the code where such a filter needed to
> happen already used
> {code:java}
> anyMatch{code}
> instead of count(). So I applied the suggested fixes. Code cleanup and
> potentially a small performance gain. As far as my understanding goes, since
> it is not a simple count that's happening, there's no known size for the
> evaluator to return and as such it has to iterate over the entire collection.
> Whereas anyMatch and noneMatch will use the predicate to stop the instance
> the condition is met.
> It just so happens that all affected instances exist within the SolrJ
> namespace.
>
> All tests have run, all succeed.
>
> EDIT: Github PR: https://github.com/apache/lucene-solr/pull/717
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13542) Code cleanup - Avoid using stream filter count where possible
[
https://issues.apache.org/jira/browse/SOLR-13542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916985#comment-16916985
]
ASF subversion and git services commented on SOLR-13542:
Commit 00f4bbe6fc814b9fa86b9f231b13b6c03a3a045e in lucene-solr's branch
refs/heads/master from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=00f4bbe ]
Merge pull request #717 from KoenDG/SOLR-13542
SOLR-13542: Code cleanup - Avoid using stream filter count where possible
> Code cleanup - Avoid using stream filter count where possible
> -
>
> Key: SOLR-13542
> URL: https://issues.apache.org/jira/browse/SOLR-13542
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
>Reporter: Koen De Groote
>Priority: Trivial
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This is another ticket in the logic of
> https://issues.apache.org/jira/browse/LUCENE-8847
>
> Not a feature, not serious, don't review this when you could be reviewing
> actual features or critical bugs, don't want to take your time away with this.
>
> Intellij's static code analysis bumped into this.
>
> I also saw most other instances in the code where such a filter needed to
> happen already used
> {code:java}
> anyMatch{code}
> instead of count(). So I applied the suggested fixes. Code cleanup and
> potentially a small performance gain. As far as my understanding goes, since
> it is not a simple count that's happening, there's no known size for the
> evaluator to return and as such it has to iterate over the entire collection.
> Whereas anyMatch and noneMatch will use the predicate to stop the instance
> the condition is met.
> It just so happens that all affected instances exist within the SolrJ
> namespace.
>
> All tests have run, all succeed.
>
> EDIT: Github PR: https://github.com/apache/lucene-solr/pull/717
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13542) Code cleanup - Avoid using stream filter count where possible
[
https://issues.apache.org/jira/browse/SOLR-13542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916986#comment-16916986
]
ASF subversion and git services commented on SOLR-13542:
Commit 00f4bbe6fc814b9fa86b9f231b13b6c03a3a045e in lucene-solr's branch
refs/heads/master from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=00f4bbe ]
Merge pull request #717 from KoenDG/SOLR-13542
SOLR-13542: Code cleanup - Avoid using stream filter count where possible
> Code cleanup - Avoid using stream filter count where possible
> -
>
> Key: SOLR-13542
> URL: https://issues.apache.org/jira/browse/SOLR-13542
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
>Reporter: Koen De Groote
>Priority: Trivial
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This is another ticket in the logic of
> https://issues.apache.org/jira/browse/LUCENE-8847
>
> Not a feature, not serious, don't review this when you could be reviewing
> actual features or critical bugs, don't want to take your time away with this.
>
> Intellij's static code analysis bumped into this.
>
> I also saw most other instances in the code where such a filter needed to
> happen already used
> {code:java}
> anyMatch{code}
> instead of count(). So I applied the suggested fixes. Code cleanup and
> potentially a small performance gain. As far as my understanding goes, since
> it is not a simple count that's happening, there's no known size for the
> evaluator to return and as such it has to iterate over the entire collection.
> Whereas anyMatch and noneMatch will use the predicate to stop the instance
> the condition is met.
> It just so happens that all affected instances exist within the SolrJ
> namespace.
>
> All tests have run, all succeed.
>
> EDIT: Github PR: https://github.com/apache/lucene-solr/pull/717
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
