[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling

JIRA jira@apache.org

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

Erick Erickson commented on SOLR-11444:

Do these changes affect SOLR-10181 or SOLR-11218? I doubt it's relevant to 10181.

I wrote two additional tests in AliasIntegrationTest to verify what happens when you delete aliases with naming issues. These now both fail whereas only one failed before after applying both this patch and 10181. 10181 was not committed...

This is the test that now fails: testDeleteAliasWithExistingCollectionName. When I wrote it originally, it passed. Whether that behavior was intended/correct I'm not quite sure but we should agree on the correct behavior. The step that fails now has the comment "// Now we should still transitively see collection_new". I'm not sure that's proper behavior, but it was true before.

The gist of these tests is "what happens when an alias and collection have the _same_ name when you delete? The scenario I'm worried about is that people create a collection then need to re-index completely and want to just alias things. This is the sequence
1> create collection old_collection
2> decide to change the schema so create new_collection and index/verify
3> don't want to change the client app so create an alias old_collection->new_collection
4> delete old_collection
NOTE: this test has a different alias to old_collection too!

I won't be able to look in detail until at least Friday.

The other new test I wrote exercises the situation where you have an alias that points to two collections. What happens when you delete one of the underlying collections? At this point we get a "no live servers", which is arguably correct, in which case we probably should error out when deleting a collection that any alias points to. Which if we agree is probably a separate JIRA.

> 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

To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]