[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
