[ 
https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16204446#comment-16204446
 ] 

David Smiley commented on SOLR-11444:
-------------------------------------

I applied the patch in SOLR-11218 over my working copy which has the changes 
here.  (there were some straight-forward merge conflicts in the test).  I ran 
{{testDeleteAliasWithExistingCollectionName}}  It failed only because of one 
assertEquals that I think is incorrect:
{code:java}
    // Now we should still transitively see collection_new
    res = cluster.getSolrClient().query("collection_old_reserve", new 
SolrQuery("*:*"));
    assertEquals(1, res.getResults().getNumFound());
{code}
This doesn't make sense to me -- the _alias_ {{collection_old_reserve}} points 
to the _collection_ {{collection_old}} and thus it should find three documents. 
 No?  In looking at code for aliases a great deal lately, aliases point to 
collections only, not to other aliases.  Thus you _cannot_ get yourself into an 
infinite loop A -> B -> A    (not possible)

> 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]

Reply via email to