[
https://issues.apache.org/jira/browse/SOLR-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13167889#comment-13167889
]
Hoss Man commented on SOLR-2920:
--------------------------------
yep yep ... totally get it now. they don't use any of the params they are
given, so no reason to waste the cycles wrapping the defaults.
just in case though, i added a comment about the defaults in case those methods
ever _do_ start using defaults.
Committed revision 1213474. - trunk
...testing the merge back to 3x now.
> Refactor frequent conditional use of DefaultSolrParams into
> SolrParams.combine(p,d)
> -----------------------------------------------------------------------------------
>
> Key: SOLR-2920
> URL: https://issues.apache.org/jira/browse/SOLR-2920
> Project: Solr
> Issue Type: Improvement
> Reporter: David Smiley
> Priority: Minor
> Attachments: SOLR-2920_SolrParams_combine().patch,
> SOLR-2920_SolrParams_wrapDefaults_and_wrapAppended.patch
>
>
> I had a small bug in use of DefaultSolrParams in my code because I didn't
> check for non-existent defaults. I noticed through the Solr codebase that is
> code pattern is very common:
> {code:java}
> if( defaults != null ) {
> params = new DefaultSolrParams( params, defaults );
> }
> {code}
> Instead, I refactored this logic into a new SolrParams.combine(p,d) method
> and made it so that nobody refers to DefaultSolrParams. I did similarly for
> AppendedSolrParams.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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
