[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Smiley updated SOLR-11444: -------------------------------- Attachment: SOLR-11444.patch Updated patch. I think it's ready. * double-resolve of an alias. This used to not be supported by JoinQParser nor streaming expressions but now it works since I put this logic in Aliases.java where it can be shared. I added some TODOs about this feature being dubious. * ClusterStateProvider: getAlias -> resolveAlias and changed semantics to return input if not an alias. The extra alias indirection happens here (new). * Aliases.java: decided to remove a convenience method I added in the last patch. And changed one of the newer methods I added to be resolveAlias with same semantics as the one in ClusterStateProvider. * SolrTestCaseJ4: new getCloudSolrClient(MiniSolrCloudCluster cluster) to randomly pick a cluster state provider based on either ZK or HTTP. FYI [~ichattopadhyaya]. Perhaps MSCC.getClient's impl should random().usually() do what it does now (it's probably fastest) and otherwise use the HTTP provider one (perhaps slower?)? note: some streaming expressions code here and CloudSolrClient's http cluster state provider are coded in such a way that will probably be wrong or break if aliases and collections have the same name. This is an observation I see, not a change induced by this patch. > Improve Aliases.java and comma delimited collection list handling > ----------------------------------------------------------------- > > Key: SOLR-11444 > URL: https://issues.apache.org/jira/browse/SOLR-11444 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud > Reporter: David Smiley > Assignee: David Smiley > Attachments: SOLR-11444.patch, SOLR-11444.patch, > SOLR_11444_Aliases.patch, SOLR_11444_Aliases.patch > > > While starting to look at SOLR-11299 I noticed some brittleness in > assumptions about Strings that refer to a collection. Sometimes they are in > fact references to comma separated lists, which appears was added with the > introduction of collection aliases (an alias can refer to a comma delimited > list). So Java's type system kind of goes out the window when we do this. > In one case this leads to a bug -- CloudSolrClient will throw an NPE if you > try to write to such an alias. Sending an update via HTTP will allow it and > send it to the first in the list. > So this issue is about refactoring and some little improvements pertaining to > Aliases.java plus certain key spots that deal with collection references. I > don't think I want to go as far as changing the public SolrJ API except to > adding documentation on what's possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org