[
https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16204835#comment-16204835
]
David Smiley commented on SOLR-11444:
-------------------------------------
Ugh; looks like I'm wrong about something: While I saw no _explicit_ alias
recursive resolution, there was in effect one level of this in HttpSolrCall due
to the second call site of looking up aliases. I found this via shelving this
patch's changes while keeping the AliasIntegrationTest changes (including
specifically your test for alias of an alias) and running it in a debugger and
seeing it work. However note while it did work, it didn't work when the
collection/alias was specified as a parameter -- searchSeveralWays tests many
ways to refer to the intended collection/alias. This double-resolution was not
previously tested -- so who knows wether it was supposed to work this way.
Perhaps it _was_ intended since the creating of an alias pointing to an alias
was tested even though it was forgotten to test actually using it.
Where does this leave us...? Well... we could add explicit double-resolution
support and test, but do this with a system property flag? Then we remove in
8.0; I don't like aliases pointing to aliases.
bq. And on a side note, WDYT about including the bits from SOLR-11488 that
dis-allows deleting a collection if any alias points to it in this JIRA?
I reviewed that patch and commented there that I liked it.
> 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_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: [email protected]
For additional commands, e-mail: [email protected]
