lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-2920) Refactor frequent conditional use of DefaultSolrParams into SolrParams.combine(p,d)
Date Thu, 08 Dec 2011 19:12:40 GMT


Hoss Man commented on SOLR-2920:

bq. I started this by putting a method in the respective class it came from, but then I noticed
that SolrParams already has some handy static utility methods. Then it occurred to me that
it would be convenient if the caller didn't need to know about all the classes in this package

Ah ... good point. SolrParams already has static methods like this, and no reason to increase
the import count. 

SolrParams.wrapAppended and SolrParams.wrapDefaults are a good call.

> Refactor frequent conditional use of DefaultSolrParams into SolrParams.combine(p,d)
> -----------------------------------------------------------------------------------
>                 Key: SOLR-2920
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: David Smiley
>            Priority: Minor
>         Attachments: SOLR-2920_SolrParams_combine().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:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message