[
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
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
