[
https://issues.apache.org/jira/browse/SOLR-13017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16859659#comment-16859659
]
Lucene/Solr QA commented on SOLR-13017:
---------------------------------------
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
31s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 31s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 6m
33s{color} | {color:green} solrj in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 12m 48s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13017 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12949713/SOLR-13017.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.4.0-137-generic #163~14.04.1-Ubuntu SMP Mon
Sep 24 17:14:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / fe58b6f |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/426/testReport/ |
| modules | C: solr solr/solrj U: solr |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/426/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> SolrInputField.setValue method should not use supplied collection as backing
> value.
> -----------------------------------------------------------------------------------
>
> Key: SOLR-13017
> URL: https://issues.apache.org/jira/browse/SOLR-13017
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Reporter: Charles Sanders
> Priority: Minor
> Attachments: SOLR-13017.patch
>
>
> The setValue method in SolrInputField takes an argument of Object. If the
> supplied object is a collection, then the collection is used as the backing
> value for the field. This can cause unexpected results when the collection
> is used to initialize two or more different fields.
> Consider the example where a list of values 'a', 'b', 'c' is used to
> initialize two fields in a SolrInputDocument.
> {noformat}
> List<String> lst = new ArrayList<>();
> lst.add("a");
> lst.add("b");
> lst.add("c");
>
> SolrInputDocument sid = new SolrInputDocument();
> sid.addField("alpha", lst);
> sid.addField("beta", lst);
> .
> . {add more fields to doc}
> .
> sid.addField("beta", "blah"); // add another value to field 'beta'
> {noformat}
> Because the same list is used to initialize both fields 'alpha' and 'beta',
> they not only contain the same values, but point to the same instance of the
> list. Therefore, if an additional value is added to one of the fields, both
> will contain the value.
> In the example provided, the user would expect field 'alpha' to contain
> values 'a', 'b', 'c'. While field 'beta' should contain fields 'a', 'b', 'c'
> and 'blah'. But that is not the case. Both fields point to the same
> instance of the list, so if a new value is added to either field, the list is
> updated and both fields will contain the same values ('a', 'b', 'c', 'blah').
> This is not a bug, but the intended logic of the method based on the method
> comment.
> {noformat}
> /**
> * Set the value for a field. Arrays will be converted to a collection. If
> * a collection is given, then that collection will be used as the backing
> * collection for the values.
> */
> {noformat}
> This jira is a request to improve the logic of the method by not using the
> supplied collection as the backing value for the field. But rather, create a
> new collection and add the values from the supplied collection to the new
> collection. This way the field is not backed by the actual instance of the
> supplied collection, but its values only.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
