[
https://issues.apache.org/jira/browse/SOLR-8332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605618#comment-15605618
]
Christine Poerschke commented on SOLR-8332:
-------------------------------------------
Thanks Noble for taking a look at the patch. I have made revisions and opened
the above [#102|https://github.com/apache/lucene-solr/pull/102] pull request
with them because in a patch it can sometimes be difficult to see the context
of changes.
{{ReplicaFilter.filter}} versus {{ReplicaListTransformer.transform}} names.
* The _transformer_ part of the interface name was quite deliberate to try and
be generic about what the transformation might be e.g. it could be removal
(i.e. filtering out) of elements or it could just be reordering (e.g. via
shuffling) of elements.
* revision made:
** javadocs added to ReplicaListTransformer.transform giving filtering and
shuffling as example transformations
There being both {{transform}} and {{transformUrls}} methods.
* Yes, i was uneasy about that as well. Usually Replica objects need to be
filtered or reordered but
[HttpShardHandler|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java#L306]
can also operate on URLs passed in via the ShardsParam.SHARDS parameter.
* revisions made:
** {{transform(List<Replica>)}} and {{transformUrls(List<String>)}} combined
into one {{transform(List<?> choices)}} method
** javadocs added to mention about Replica vs. String choices
** ToyMatchingReplicaListTransformer class (in tests) to demonstrate how
{{List<?> choices}} can be used
{{List methodName(List inputs)}} versus {{void methodName(List choices)}}
signature.
* no revisions made: making the parameter input-and-output seems unproblematic
and saves having to allocate an output list to be returned
{{transform(List,SolrQueryRequest)}} versus {{void transform(List)}} signature.
* transform is called multiple times i.e. once for each shard but there is only
one transformer object. The transformer's constructor may take a
SolrQueryRequest argument (if needed) and that way request param deciphering
happens only once per prepDistributed call.
* revisions made:
** Added ReplicaListTransformerTest class to demonstrate (with toy
ReplicaListTransformer classes) how SolrQueryRequest params (or indeed
SolrQueryRequest itself) could be passed to a ReplicaListTransformer upon
construction.
> factor HttpShardHandler[Factory]'s url shuffling out into a
> ReplicaListTransformer class
> ----------------------------------------------------------------------------------------
>
> Key: SOLR-8332
> URL: https://issues.apache.org/jira/browse/SOLR-8332
> Project: Solr
> Issue Type: Wish
> Reporter: Christine Poerschke
> Assignee: Christine Poerschke
> Priority: Minor
> Attachments: SOLR-8332.patch, SOLR-8332.patch, SOLR-8332.patch
>
>
> Proposed patch against trunk to follow. No change in behaviour intended. This
> would be as a step towards SOLR-6730.
--
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
