[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16257915#comment-16257915 ] ASF subversion and git services commented on SOLR-11444: Commit 35bd3310aa6f0907f1b9582fdbda9516e742e3c9 in lucene-solr's branch refs/heads/branch_7x from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=35bd331 ] SOLR-11444: CloudSolrClient could have thrown an NPE if the collection doesn't exist. Refactor: Tidy the exception throwing (cherry picked from commit 6f99196) > 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 > Fix For: 7.2 > > Attachments: SOLR-11444.patch, SOLR-11444.patch, > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16257914#comment-16257914 ] ASF subversion and git services commented on SOLR-11444: Commit 6f99196e816761706e616325b3b2399867c571cc in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6f99196 ] SOLR-11444: CloudSolrClient could have thrown an NPE if the collection doesn't exist. Refactor: Tidy the exception throwing > 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 > Fix For: 7.2 > > Attachments: SOLR-11444.patch, SOLR-11444.patch, > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16212094#comment-16212094 ] ASF subversion and git services commented on SOLR-11444: Commit 31d24ea293836e8b12b69ca49d76cec1aa459996 in lucene-solr's branch refs/heads/branch_7x from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=31d24ea ] SOLR-11444: Fix AliasIntegrationTest when masked collection is null (cherry picked from commit f472210) > 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 > Fix For: 7.2 > > Attachments: SOLR-11444.patch, SOLR-11444.patch, > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16212093#comment-16212093 ] ASF subversion and git services commented on SOLR-11444: Commit f47221002311fe80f4fbcb337dc8e7b985aa7347 in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f472210 ] SOLR-11444: Fix AliasIntegrationTest when masked collection is null > 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 > Fix For: 7.2 > > Attachments: SOLR-11444.patch, SOLR-11444.patch, > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16210545#comment-16210545 ] ASF subversion and git services commented on SOLR-11444: Commit da71587196eccefd8b58923dc162916c808762a9 in lucene-solr's branch refs/heads/branch_7x from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=da71587 ] SOLR-11444: Improve consistency of collection alias handling and collection list references. Other refactorings of nearby code too. (cherry picked from commit e001f35) > 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.patch, SOLR-11444.patch, > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16210544#comment-16210544 ] ASF subversion and git services commented on SOLR-11444: Commit e001f352895c83652c3cf31e3c724d29a46bb721 in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e001f35 ] SOLR-11444: Improve consistency of collection alias handling and collection list references. Other refactorings of nearby code too. > 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.patch, SOLR-11444.patch, > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16206524#comment-16206524 ] David Smiley commented on SOLR-11444: - Your change RE path & idx makes total sense Erick. I'll improve this further as I indicated to do a double-resolution of Aliases (alias -> alias -> collection) to be supported and then test it works. Conditionally supporting and eventually removing support for it ought to be a separate issue. This issue here is mostly a refactoring with minor improvements related to consistency: consistency of comma delimited collection/alias lists in the path, and ensuring CloudSolrClient can route an update to a multi-collection alias just as HttpSolrCall already can. > 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.patch, 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[
https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204819#comment-16204819
]
Gus Heck commented on SOLR-11444:
-
This patch fixes a bug I was just puzzling over. While reading code in
HttpSolrCall, I couldn't figure out how it was possible to find an alias from a
node not part of that alias... finally I set up a test, and found that in fact
it did fail...
{code}
{
"error":{
"metadata":[
"error-class","org.apache.solr.common.SolrException",
"root-error-class","org.apache.zookeeper.KeeperException$SessionExpiredException"],
"msg":"Could not load collection from ZK: test1",
"code":400}}
{code}
That was from a 4 node cluster with collection *test1* aliased as *test1alias*
that had 1 shard and replication factor 1, which were allocated to nodes on
port 8981 and 8982, from which all seemed normal, but errors like this occured
if one tried to use the test1alias name from the node on port 8983
I was about to file a bug but then I applied this patch since it seemed to be
in exactly the section of code that didn't make sense, and poof the issue
disappeared :)
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[
https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204755#comment-16204755
]
Erick Erickson commented on SOLR-11444:
---
IIRC, that test in SOLR-11218 _used_ to work in which case the behavior is now
different (and, I think, correct). Of course I may be mis-remembering...
Let's claim I'm remembering correctly for a second though: the test
{{testDeleteAliasWithExistingCollectionName}} used to work but was only showing
incorrect behavior. That lends weight to the discussions in SOLR-11488 and
SOLR-11489 I think. At least we should beef up the tests a _lot_ to have faith
that
1> the behavior is what we expect
2> future changes don't unexpectedly break things
I'd prefer a more systemic change of course.
To be clear, the discussions at SOLR-11488 and SOLR-11489 should _not_ hold up
this JIRA. In fact I'd be loathe to do either of them before this one is
committed.
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? The
nocommit test {{testDeleteOneOfTwoCollectionsAliased}} in SOLR-11218 exercises
that and IIRC we get an error if we query on an alias after deleting only one
of the collections pointed to by 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204455#comment-16204455 ] David Smiley commented on SOLR-11444: - bq. In looking at code for aliases a great deal lately, aliases point to collections only, not to other aliases. To clarify, I mean the code that _uses_ aliases (lots of which affected by SOLR-11444 here) it was clear that aliases are not recursively resolved, and thus you can't get yourself into an infinite loop. That said, now that I look carefully at the alias creation validation code, it does not forbid creating aliases pointing to aliases, and there is even a test that shows it's not forbidden! But no test (in AliasIntegrationTest) actually _uses_ (searches with) this alias pointing to an alias. I added a simple try to do so to validate my understanding of the code and it indeed failed. All this conversation about SOLR-11218 really ought to be on that issue, alas. Too late? Hey [~markrmil...@gmail.com] you added aliases originally and have some insight I'm sure. IMO, we shouldn't let someone create an alias to an alias. As I mentioned above, Solr will let you do it but it doesn't actually work, and may be tricky to support with safety. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[
https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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. H, 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204226#comment-16204226 ] David Smiley commented on SOLR-11444: - No prob Erick; I'll investigate and see what's going wrong. BTW I didn't know aliases could be named after existing collections! Seems like something possibly hard to get right. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204174#comment-16204174 ] Erick Erickson commented on SOLR-11444: --- -1 until we resolve the additional test issue in SOLR-11218. I hope to have some time this weekend to dig further. The issue for me is that testDeleteAliasWithExistingCollectionName fails with the patch on this JIRA but did not before. The reason I'm persnickety about this one is that this scenario doing the wrong thing is very painful. A common strategy for reindexing from scratch is to create a new collection, index to that and then define an alias to switch atomically. Problem is that it's often the case that the user won't already have an alias set up, so you wind up with an alias and collection name that are identical, but the alias does _not_ point to the collection named the same. So far, so good. But now I want to delete the old collection. If the alias is followed it deletes the wrong collection. Here's an abbreviated set of steps. > create collection old > create collection new > alias old->new > delete old If that sequence deletes the new collection it's pretty bad. Now, it may just be that the test isn't doing what I think, I really didn't have time to look yet. I'll see what I can get through this weekend. The second test in SOLR-11218 with the nocommit is a separate concern, "it does what it does" may be fine there. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204123#comment-16204123 ] David Smiley commented on SOLR-11444: - [~erickerickson] This issue, SOLR-11444, should not change the semantics of either of those issues (SOLR-10181 or SOLR-11218). However both issues touch the same files as this one and so there will be some merge conflicts for one or both of us to get through if our mutual work overlaps. If there are no further comments, I'd like to commit this Monday and let the tests beat on it a bit. In a subsequent commit I can adjust Solr's documentation to point out that collection references in the path can be a comma delimited list (new). I should add some docs too. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201866#comment-16201866 ] Kevin Risden commented on SOLR-11444: - Changes for SQL sounds reasonable to me. I think streaming expressions support aliases now. When it was originally implemented not sure that was the case. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16194919#comment-16194919 ] Joel Bernstein commented on SOLR-11444: --- I also believe the get slices logic was in a number of different places in the streaming code with slightly different implementations. It was then moved to the TupleStream where it's shared by all the stream sources. So when that consolidation was done it probably took the most up to date version in CloudSolrClient. I think it does make sense to use the CloudSolrClient version rather then having the streaming have this logic. > 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 > > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16194909#comment-16194909 ] Joel Bernstein commented on SOLR-11444: --- I suspect what happened was that the getSlices implementation was different at one point in time and then made the same. I'm not sure if I'm the one that did this or not, as it's been refactored a number of times I believe. If they are identical now it makes sense to just use the CloudSolrClient version. > 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 > > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
