[
https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16204379#comment-16204379
]
Erick Erickson commented on SOLR-11444:
---------------------------------------
Yeah, when I realized that we were recommending that and didn't have a test for
it it kind of scared me.
Several things though:
1> I'm interested in preventing this "delete the wrong collection" issue, not
_necessarily_ keeping this behavior.
2> The test could very well not be doing what I think
3> I'm also interested in codifying the intended behavior with tests.
If it gets too hairy (and I'm thinking of all the persist pain and and agony
for solr.xml historically) we could consider alternatives like preventing
having an alias with the same name as a collection. People could get by if they
> index to new collection
> have a maintenance window in which they
>> deleted the old collection
>> created an alias with the old name and pointed to the new collection
Once that was done the first time, they wouldn't have the problem again as they
are now using an alias not a collection even though it has the same name as the
old (deleted) collection. This pre-supposes they can't/won't change whatever
the app is to use an alias in the first place.
Hmmmm, I'm starting to think that preventing an alias from being created with
the same name as an existing collection is the way to go. Supporting the
current behavior would be for people who do it that way now and can't/won't
change client(s) to use an alias. And there is a way to get by without changing
the client above, albeit it'd be a bit of a pain, but not much frankly.
And it's not even an all-or-none thing. Say I have collectionA. I create an
alias to it (aliasA->collectionA). Now I can switch over my client(s) to use
aliasA on whatever schedule I want, one at a time or all at once. When they're
all done and tested I can reindex to collectionB and then switch
aliasA->collectionB.
WDYT? I can claim that having an alias and a collection with the same name is
inherently unsafe/confusing without any qualms at all.
That would leave the question of what we should do at initialization time if we
find a collection and alias with the same name from something previous though.
Big fat ERROR THIS HAS UNDEFINED BEHAVIOR message or something?
> 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]
