[jira] [Comment Edited] (SOLR-7798) Improve robustness of ExpandComponent
[
https://issues.apache.org/jira/browse/SOLR-7798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374513#comment-16374513
]
Joel Bernstein edited comment on SOLR-7798 at 2/23/18 3:40 PM:
---
There were a couple issues I ran into. First, I worked with the pull request,
but I found the commit message wasn't formatted quite right and the test wasn't
include.
Next, I applied the patch, which didn't apply cleanly on master.
So, I decided to hand integrate the changes and the test from the patch. The
test case in the patch looked like it might have been written for an older
version and was failing every time.
I wouldn't worry about it though. This is a small enough change that I can just
fix things up on my own and commit it. It will just take a little longer to get
committed because I need to carve out a little more time to work with it. But I
will get this committed unless I run into a blocker.
was (Author: joel.bernstein):
There were a couple issues I ran into. First I worked with the pull request,
but I found the commit message wasn't formatted quite right and the test wasn't
include.
Next I applied the patch, which didn't apply cleanly on master.
So, I decided to hand integrate the changes and the test from the patch. The
test case in the patch looked like it might have been written for an older
version and was failing every time.
I wouldn't worry about it though. This is a small enough change that I can just
fix things up on my own and commit it. It will just take a little longer to get
committed because I need to carve out a little more time to work with it. But I
will get this committed unless I run into a blocker.
> Improve robustness of ExpandComponent
> -
>
> Key: SOLR-7798
> URL: https://issues.apache.org/jira/browse/SOLR-7798
> Project: Solr
> Issue Type: Improvement
> Components: SearchComponents - other
>Reporter: Jörg Rathlev
>Assignee: Joel Bernstein
>Priority: Minor
> Attachments: expand-component.patch, expand-npe.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{ExpandComponent}} causes a {{NullPointerException}} if accidentally
> used without prior collapsing of results.
> If there are multiple documents in the result which have the same term value
> in the expand field, the size of the {{ordBytes}}/{{groupSet}} differs from
> the {{count}} value, and the {{getGroupQuery}} method creates an incompletely
> filled {{bytesRef}} array, which later causes a {{NullPointerException}} when
> trying to sort the terms.
> The attached patch extends the test to demonstrate the error, and modifies
> the {{getGroupQuery}} methods to create the array based on the size of the
> input maps.
--
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] [Comment Edited] (SOLR-7798) Improve robustness of ExpandComponent
[
https://issues.apache.org/jira/browse/SOLR-7798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373370#comment-16373370
]
Joel Bernstein edited comment on SOLR-7798 at 2/22/18 8:17 PM:
---
The test case is failing for me. What version are you working with? It looks
like the test might have been developed on a branch that is incompatible with
the current master branch.
The commit workflow is to commit to the master branch and back port to release
branch, which is branch_7x.
was (Author: joel.bernstein):
The test case is failing for me. What version are you working with?
The commit workflow is to commit the master branch and back port to release
branch.
> Improve robustness of ExpandComponent
> -
>
> Key: SOLR-7798
> URL: https://issues.apache.org/jira/browse/SOLR-7798
> Project: Solr
> Issue Type: Improvement
> Components: SearchComponents - other
>Reporter: Jörg Rathlev
>Assignee: Joel Bernstein
>Priority: Minor
> Attachments: expand-component.patch, expand-npe.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{ExpandComponent}} causes a {{NullPointerException}} if accidentally
> used without prior collapsing of results.
> If there are multiple documents in the result which have the same term value
> in the expand field, the size of the {{ordBytes}}/{{groupSet}} differs from
> the {{count}} value, and the {{getGroupQuery}} method creates an incompletely
> filled {{bytesRef}} array, which later causes a {{NullPointerException}} when
> trying to sort the terms.
> The attached patch extends the test to demonstrate the error, and modifies
> the {{getGroupQuery}} methods to create the array based on the size of the
> input maps.
--
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] [Comment Edited] (SOLR-7798) Improve robustness of ExpandComponent
[
https://issues.apache.org/jira/browse/SOLR-7798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373055#comment-16373055
]
Joel Bernstein edited comment on SOLR-7798 at 2/22/18 4:47 PM:
---
Just getting reacquainted with the code. I believe the 200 magic number is an
inflection point for when it makes sense to build a disjunction query for
retrieving the group records. I did quite a bit of performance tuning in the
original release and I believe 200 was the tipping point for when the
disjunction slowed things down, rather then sped things up. I'll need to do a
little more digging to fully understand how the patch effects things.
was (Author: joel.bernstein):
Just getting reacquainted with the code. I believe the 200 magic number is an
inflection point for when it makes sense to build a disjunction query for
retrieving the group records. I'll need to do a little more digging to fully
understand how the patch effects things.
> Improve robustness of ExpandComponent
> -
>
> Key: SOLR-7798
> URL: https://issues.apache.org/jira/browse/SOLR-7798
> Project: Solr
> Issue Type: Improvement
> Components: SearchComponents - other
>Reporter: Jörg Rathlev
>Assignee: Joel Bernstein
>Priority: Minor
> Attachments: expand-component.patch, expand-npe.patch
>
>
> The {{ExpandComponent}} causes a {{NullPointerException}} if accidentally
> used without prior collapsing of results.
> If there are multiple documents in the result which have the same term value
> in the expand field, the size of the {{ordBytes}}/{{groupSet}} differs from
> the {{count}} value, and the {{getGroupQuery}} method creates an incompletely
> filled {{bytesRef}} array, which later causes a {{NullPointerException}} when
> trying to sort the terms.
> The attached patch extends the test to demonstrate the error, and modifies
> the {{getGroupQuery}} methods to create the array based on the size of the
> input maps.
--
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] [Comment Edited] (SOLR-7798) Improve robustness of ExpandComponent
[
https://issues.apache.org/jira/browse/SOLR-7798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16372962#comment-16372962
]
Michael Gibney edited comment on SOLR-7798 at 2/22/18 3:46 PM:
---
Thanks, [~joel.bernstein]. I'm happy to prep a PR, but would you mind first
confirming that {{count}} (and its associated ceiling of 200) is intended to
represent the number of matching collapse _values_, as opposed to the number of
result documents associated with those values? Assuming that's the case, is
there any reason to continue tracking {{count}} externally (as opposed to
simply relying on {{ordBytes.size(), as in [~joergr]'s
[^expand-component.patch] patch}})?
was (Author: mgibney):
Thanks, [~joel.bernstein]. I'm happy to prep a PR, but would you mind first
confirming that {{count}} (and its associated ceiling of 200) is intended to
represent the number of matching collapse _values_, as opposed to the number of
result documents associated with those values? Assuming that's the case, is
there any reason to continue trac{{king }}{{count}} externally (as opposed to
simply relying on {{ordBytes.size(), as in [~joergr]'s
[^expand-component.patch] patch}})?
> Improve robustness of ExpandComponent
> -
>
> Key: SOLR-7798
> URL: https://issues.apache.org/jira/browse/SOLR-7798
> Project: Solr
> Issue Type: Improvement
> Components: SearchComponents - other
>Reporter: Jörg Rathlev
>Assignee: Joel Bernstein
>Priority: Minor
> Attachments: expand-component.patch, expand-npe.patch
>
>
> The {{ExpandComponent}} causes a {{NullPointerException}} if accidentally
> used without prior collapsing of results.
> If there are multiple documents in the result which have the same term value
> in the expand field, the size of the {{ordBytes}}/{{groupSet}} differs from
> the {{count}} value, and the {{getGroupQuery}} method creates an incompletely
> filled {{bytesRef}} array, which later causes a {{NullPointerException}} when
> trying to sort the terms.
> The attached patch extends the test to demonstrate the error, and modifies
> the {{getGroupQuery}} methods to create the array based on the size of the
> input maps.
--
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
