You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Shawn Heisey (JIRA)" <ji...@apache.org> on 2016/06/03 14:43:59 UTC
[jira] [Comment Edited] (SOLR-9184) Add convenience method to
ModifiableSolrParams
[ https://issues.apache.org/jira/browse/SOLR-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15314206#comment-15314206 ]
Shawn Heisey edited comment on SOLR-9184 at 6/3/16 2:43 PM:
------------------------------------------------------------
There's no need to remove previous patches. Jira automatically handles marking the old ones differently than the newest one with the same filename. Having previous versions of a patch available helps to understand the thought processes of the person who created the patches -- we prefer to keep that history, even if the older patches are blatantly wrong.
Although I like this change, it probably should be restricted to master (7.0-SNAPSHOT) because it could break existing code. There are likely people who intentionally use the constructor to *copy* one MSP object, creating a new one that can be modified independently of the original. If we change that behavior in a minor release, any user who depends on that behavior will have a broken program after upgrading SolrJ. There might even be instances in the Solr main or test code that rely on this behavior -- all uses must be reviewed.
Edit: Closer reading reveals that you want to *add* a method. Which makes my concern moot.
was (Author: elyograg):
There's no need to remove previous patches. Jira automatically handles marking the old ones differently than the newest one with the same filename. Having previous versions of a patch available helps to understand the thought processes of the person who created the patches -- we prefer to keep that history, even if the older patches are blatantly wrong.
Although I like this change, it probably should be restricted to master (7.0-SNAPSHOT) because it could break existing code. There are likely people who intentionally use the constructor to *copy* one MSP object, creating a new one that can be modified independently of the original. If we change that behavior in a minor release, any user who depends on that behavior will have a broken program after upgrading SolrJ. There might even be instances in the Solr main or test code that rely on this behavior -- all uses must be reviewed.
> Add convenience method to ModifiableSolrParams
> ----------------------------------------------
>
> Key: SOLR-9184
> URL: https://issues.apache.org/jira/browse/SOLR-9184
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Reporter: Jörg Rathlev
> Priority: Minor
> Attachments: SOLR-9184.patch
>
>
> Add a static convenience method {{ModifiableSolrParams#of(SolrParams)}} which returns the same instance if it already is modifiable, otherwise creates a new {{ModifiableSolrParams}} instance.
> Rationale: when writing custom SearchComponents, we find that we often need to ensure that the SolrParams are modifiable. The copy constructor of ModifiableSolrParams always creates a copy, even if the SolrParms already are modifiable.
> Alternatives: The method could also be added as a convenience method in SolrParams itself, which already has static helper methods for wrapDefaults and wrapAppended.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org