[jira] [Comment Edited] (SOLR-11624) _default configset overwrites a a configset if collection.configName isn't specified even if a confiset of the same name already exists.
[
https://issues.apache.org/jira/browse/SOLR-11624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16286385#comment-16286385
]
Abhishek Kumar Singh edited comment on SOLR-11624 at 12/11/17 6:46 PM:
---
Please find the updated patch here -> [^SOLR-11624.3.patch]
Changes made:-
1. Modified the test case {{TimeRoutedAliasUpdateProcessorTest#test}} to
create/update and use the correct {{modifiedConfigSet}} name.
2. Refactored the {{configName}} , added suffix to the name of _auto-generated
configSet_.
[~ichattopadhyaya] , [~dsmiley] Please review the patch.
was (Author: asingh2411):
Please find the updated patch here -> [^SOLR-11624.3.patch]
Changes made:-
1. Modified the test case {{TimeRoutedAliasUpdateProcessorTest#test}} to
create/update and use the correct {{modifiedConfigSet}} name.
2. Refactored the {{configName}} , added suffix to the name of _auto-generated
configSet_.
[~ichattopadhyaya] [~dsmiley] Please review the patch.
> _default configset overwrites a a configset if collection.configName isn't
> specified even if a confiset of the same name already exists.
>
>
> Key: SOLR-11624
> URL: https://issues.apache.org/jira/browse/SOLR-11624
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.2
>Reporter: Erick Erickson
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-11624-2.patch, SOLR-11624.3.patch, SOLR-11624.patch
>
>
> Looks like a problem that crept in when we changed the _default configset
> stuff.
> setup:
> upload a configset named "wiki"
> collections?action=CREATE&name=wiki&.
> My custom configset "wiki" gets overwritten by _default and then used by the
> "wiki" collection.
> Assigning to myself only because it really needs to be fixed IMO and I don't
> want to lose track of it. Anyone else please feel free to take it.
--
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] [Comment Edited] (SOLR-11624) _default configset overwrites a a configset if collection.configName isn't specified even if a confiset of the same name already exists.
[
https://issues.apache.org/jira/browse/SOLR-11624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16286385#comment-16286385
]
Abhishek Kumar Singh edited comment on SOLR-11624 at 12/11/17 6:45 PM:
---
Please find the updated patch here -> [^SOLR-11624.3.patch]
Changes made:-
1. Modified the test case {{TimeRoutedAliasUpdateProcessorTest#test}} to
create/update and use the correct {{modifiedConfigSet}} name.
2. Refactored the {{configName}} , added suffix to the name of _auto-generated
configSet_.
[~ichattopadhyaya] [~dsmiley] Please review the patch.
was (Author: asingh2411):
Please find the updated patch here -> [^SOLR-11624.3.patch]
Changes made:-
1. Modified the test case {{TimeRoutedAliasUpdateProcessorTest#test}} to
create/update and use the correct {{modifiedConfigSet}} name.
2. Refactored the {{configName}} , added suffix to the name of _auto-generated
configSet_.
> _default configset overwrites a a configset if collection.configName isn't
> specified even if a confiset of the same name already exists.
>
>
> Key: SOLR-11624
> URL: https://issues.apache.org/jira/browse/SOLR-11624
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.2
>Reporter: Erick Erickson
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-11624-2.patch, SOLR-11624.3.patch, SOLR-11624.patch
>
>
> Looks like a problem that crept in when we changed the _default configset
> stuff.
> setup:
> upload a configset named "wiki"
> collections?action=CREATE&name=wiki&.
> My custom configset "wiki" gets overwritten by _default and then used by the
> "wiki" collection.
> Assigning to myself only because it really needs to be fixed IMO and I don't
> want to lose track of it. Anyone else please feel free to take it.
--
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] [Comment Edited] (SOLR-11624) _default configset overwrites a a configset if collection.configName isn't specified even if a confiset of the same name already exists.
[
https://issues.apache.org/jira/browse/SOLR-11624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16286385#comment-16286385
]
Abhishek Kumar Singh edited comment on SOLR-11624 at 12/11/17 6:43 PM:
---
Please find the updated patch here -> [^SOLR-11624.3.patch]
Changes made:-
1. Modified the test case {{TimeRoutedAliasUpdateProcessorTest#test}} to
create/update and use the correct {{modifiedConfigSet}} name.
2. Refactored the {{configName}} , added suffix to the name of _auto-generated
configSet_.
was (Author: asingh2411):
Please find the updated patch here.
> _default configset overwrites a a configset if collection.configName isn't
> specified even if a confiset of the same name already exists.
>
>
> Key: SOLR-11624
> URL: https://issues.apache.org/jira/browse/SOLR-11624
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.2
>Reporter: Erick Erickson
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-11624-2.patch, SOLR-11624.3.patch, SOLR-11624.patch
>
>
> Looks like a problem that crept in when we changed the _default configset
> stuff.
> setup:
> upload a configset named "wiki"
> collections?action=CREATE&name=wiki&.
> My custom configset "wiki" gets overwritten by _default and then used by the
> "wiki" collection.
> Assigning to myself only because it really needs to be fixed IMO and I don't
> want to lose track of it. Anyone else please feel free to take it.
--
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] [Comment Edited] (SOLR-11624) _default configset overwrites a a configset if collection.configName isn't specified even if a confiset of the same name already exists.
[ https://issues.apache.org/jira/browse/SOLR-11624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16279754#comment-16279754 ] Ishan Chattopadhyaya edited comment on SOLR-11624 at 12/6/17 8:54 AM: -- I was a bit under the weather and couldn't get to this sooner. -I'll try to put in this immediate measure, i.e. throw an error on overwrite.- EDIT: Error on overwrite seems a bit tricky: the collection creation would fail on this error which is an unfriendly behaviour and I'm not sure if this is what we should do as a temporary/stopgap behaviour. I'm thinking through this a bit more, will update as soon as possible. I'll try not to hold up the release for this. was (Author: ichattopadhyaya): I was a bit under the weather and couldn't get to this sooner. I'll try to put in this immediate measure, i.e. throw an error on overwrite. > _default configset overwrites a a configset if collection.configName isn't > specified even if a confiset of the same name already exists. > > > Key: SOLR-11624 > URL: https://issues.apache.org/jira/browse/SOLR-11624 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.2 >Reporter: Erick Erickson >Assignee: Ishan Chattopadhyaya > Attachments: SOLR-11624.patch > > > Looks like a problem that crept in when we changed the _default configset > stuff. > setup: > upload a configset named "wiki" > collections?action=CREATE&name=wiki&. > My custom configset "wiki" gets overwritten by _default and then used by the > "wiki" collection. > Assigning to myself only because it really needs to be fixed IMO and I don't > want to lose track of it. Anyone else please feel free to take it. -- 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] [Comment Edited] (SOLR-11624) _default configset overwrites a a configset if collection.configName isn't specified even if a confiset of the same name already exists.
[ https://issues.apache.org/jira/browse/SOLR-11624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16278796#comment-16278796 ] Erick Erickson edited comment on SOLR-11624 at 12/5/17 4:07 PM: [~noble.paul][~steve_rowe][~ichattopadhyaya] Adrien mentioned this JIRA as something he might include in the 7.2 release. Is this worth trying to push into 7.2 or would it be better to bake it for 7.3? I won't be able to devote significant time to it this week, too late for 7.2. was (Author: erickerickson): [~noble.paul][~steve_rowe][~ichattopadhyaya] Adrien mentioned this JIRA as something he might include in the 7.2 release. Is this worth trying to push into 7.2 or would it be better to bake it for 7.3? I won't be able to devote significant time to it this week, too late for 7.3. > _default configset overwrites a a configset if collection.configName isn't > specified even if a confiset of the same name already exists. > > > Key: SOLR-11624 > URL: https://issues.apache.org/jira/browse/SOLR-11624 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.2 >Reporter: Erick Erickson >Assignee: Ishan Chattopadhyaya > Attachments: SOLR-11624.patch > > > Looks like a problem that crept in when we changed the _default configset > stuff. > setup: > upload a configset named "wiki" > collections?action=CREATE&name=wiki&. > My custom configset "wiki" gets overwritten by _default and then used by the > "wiki" collection. > Assigning to myself only because it really needs to be fixed IMO and I don't > want to lose track of it. Anyone else please feel free to take it. -- 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] [Comment Edited] (SOLR-11624) _default configset overwrites a a configset if collection.configName isn't specified even if a confiset of the same name already exists.
[
https://issues.apache.org/jira/browse/SOLR-11624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16250884#comment-16250884
]
Erick Erickson edited comment on SOLR-11624 at 11/14/17 5:25 AM:
-
I think I see how you're thinking about this. I think it's too much effort,
unnecessarily complex and there's too many ways it can fail. Not to mention
startling to veteran users.
*Failure case*: User creates a collection and we copy {{_default}} with our
prefix. User uses the config API or schema API to modify. User drops
collection. The user's work disappears. Hair tearing ensues.
*Failure case*: User creates a collection and we copy {{_default}}. User is
learning about configsets and uploads customized configs manually to the same
place 'cause "Hey! that's where my configset is!". User deletes collection and
work disappears. Remaining hair is torn out.
*Failure case*: User manually creates a configset prefixed by
{{SOLR_CONFIGSET}} 'cause "Hey, that's the convention apparently" then drops
the associated collection. We remove the configset, again losing his work. User
is now bald and head explodes.
*Failure case N+1*: I'm sure we'll find more.
Sure, each failure case can be fixed with enough coding, but why bother just to
keep configsets from proliferating? As I see it, the only thing this mechanism
is really helping with is:
{{Take the use case of a casual user creating and deleting collections. very
soon, we will end up a lot of unused configsets in zookeeper. }}
First of all, if the user is dropping and recreating the same collection
there's no problem, they'll just continue to use the same configset that was
copied the first time.
Second, after that bit of hand-holding users will soon have to be aware of
configsets. Especially since every time they create a collection with the
{{_default}} configset (or a copy) there's a warning in the response *telling
the user that this isn't a good idea* (that should stay BTW)! I don't think
it's too much to ask for them to use the configsets API to delete old
configsets if they create/drop a bunch of different collections and we copy
{{_defalut}} around. Until then having configsets proliferate isn't a big deal
IMO.
I don't think your argument below is germane. Maybe I'm stringing two sentences
together that weren't intended...
{{The user did not create the configset, so he is not aware of its existence.
Imagine he screwed up the configset while he was using the collection and he
wanted to start with a clean slate.}}
How did the user screw up a configset if she was unaware of it in the first
place? I guess you can argue that she messed it up by using the config API or
the managed schema API. IMO it's totally reasonable to expect anyone at that
level to use the configs API to delete the configset if they need to start over.
I claim a user will have to eventually be aware of configsets and the added
burden of using the configs API to delete unwanted ones after they figure
configsets out is preferable to adding to the complexity and potential errors
by trying to fix the one use case I see this addressing. If we go this route it
won't need any new flags for the collections DELETE command.
What other use-cases do you see that need supporting besides proliferating
configsets?
was (Author: erickerickson):
I think I see how you're thinking about this. I think it's too much effort,
unnecessarily complex and there's too many ways it can fail. Not to mention
startling to veteran users.
*Failure case*: User creates a collection and we copy {{_default}} with our
prefix. User uses the config API or schema API to modify. User drops
collection. The user's work disappears. Hair tearing ensues.
*Failure case*: User creates a collection and we copy {{_default}}. User is
learning about configsets and uploads customized configs manually to the same
place 'cause "Hey! that's where my configset is!". User deletes collection and
work disappears. Remaining hair is torn out.
*Failure case*: User manually creates a configset prefixed by
{{SOLR_CONFIGSET}} 'cause "Hey, that's the convention apparently" then drops
the associated collection. We remove the configset, again losing his work. User
is now bald and head explodes.
*Failure case N+1*: I'm sure we'll find more.
Sure, each failure case can be fixed with enough coding, but why bother just to
keep configsets from proliferating? As I see it, the only thing this mechanism
is really helping with is:
{{
Take the use case of a casual user creating and deleting collections. very
soon, we will end up a lot of unused configsets in zookeeper.
}}
First of all, if the user is dropping and recreating the same collection
there's no problem, they'll just continue to use the same configset that was
copied the first time.
Second, after that bit of hand-holding users will so
[jira] [Comment Edited] (SOLR-11624) _default configset overwrites a a configset if collection.configName isn't specified even if a confiset of the same name already exists.
[
https://issues.apache.org/jira/browse/SOLR-11624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16250884#comment-16250884
]
Erick Erickson edited comment on SOLR-11624 at 11/14/17 5:22 AM:
-
I think I see how you're thinking about this. I think it's too much effort,
unnecessarily complex and there's too many ways it can fail. Not to mention
startling to veteran users.
*Failure case*: User creates a collection and we copy {{_default}} with our
prefix. User uses the config API or schema API to modify. User drops
collection. The user's work disappears. Hair tearing ensues.
*Failure case*: User creates a collection and we copy {{_default}}. User is
learning about configsets and uploads customized configs manually to the same
place 'cause "Hey! that's where my configset is!". User deletes collection and
work disappears. Remaining hair is torn out.
*Failure case*: User manually creates a configset prefixed by
{{SOLR_CONFIGSET}} 'cause "Hey, that's the convention apparently" then drops
the associated collection. We remove the configset, again losing his work. User
is now bald and head explodes.
*Failure case N+1*: I'm sure we'll find more.
Sure, each failure case can be fixed with enough coding, but why bother just to
keep configsets from proliferating? As I see it, the only thing this mechanism
is really helping with is:
{{
Take the use case of a casual user creating and deleting collections. very
soon, we will end up a lot of unused configsets in zookeeper.
}}
First of all, if the user is dropping and recreating the same collection
there's no problem, they'll just continue to use the same configset that was
copied the first time.
Second, after that bit of hand-holding users will soon have to be aware of
configsets. Especially since every time they create a collection with the
{{_default}} configset (or a copy) there's a warning in the response *telling
the user that this isn't a good idea* (that should stay BTW)! I don't think
it's too much to ask for them to use the configs API to delete old configsets
if they create/drop a bunch of different collections and we copy {{_defalut}}
around. Until then having configsets proliferate isn't a big deal IMO.
I don't think your argument below is germane. Maybe I'm stringing two sentences
together that weren't intended...
{{The user did not create the configset, so he is not aware of its existence.
Imagine he screwed up the configset while he was using the collection and he
wanted to start with a clean slate.}}
How did the user screw up a configset if she was unaware of it in the first
place? I guess you can argue that she messed it up by using the config API or
the managed schema API. IMO it's totally reasonable to expect anyone at that
level to use the configs API to delete the configset if they need to start over.
I claim a user will have to eventually be aware of configsets and the added
burden of using the configs API to delete unwanted ones after they figure
configsets out is preferable to adding to the complexity and potential errors
by trying to fix the one use case I see this addressing. If we go this route it
won't need any new flags for the collections DELETE command.
What other use-cases do you see that need supporting besides proliferating
configsets?
was (Author: erickerickson):
I think I see how you're thinking about this. I think it's too much effort,
unnecessarily complex and there's too many ways it can fail. Not to mention
startling to veteran users.
*Failure case*: User creates a collection and we copy {{_default}} with our
prefix. User uses the config API or schema API to modify. User drops
collection. The user's work disappears. Hair tearing ensues.
*Failure case*: User creates a collection and we copy {{_default}}. User is
learning about configsets and uploads customized configs manually to the same
place 'cause "Hey! that's where my configset is!". User deletes collection and
work disappears. Remaining hair is torn out.
*Failure case*: User manually creates a configset prefixed by
{{SOLR_CONFIGSET}} 'cause "Hey, that's the convention apparently" then drops
the associated collection. We remove the configset, again losing his work. User
is now bald and head explodes.
*Failure case N+1*: I'm sure we'll find more.
Sure, each failure case can be fixed with enough coding, but why bother just to
keep configsets from proliferating? As I see it, the only thing this mechanism
is really helping with is:
{{Take the use case of a casual user creating and deleting collections. very
soon, we will end up a lot of unused configsets in zookeeper. }}
First of all, if the user is dropping and recreating the same collection
there's no problem, they'll just continue to use the same configset that was
copied the first time.
Second, after that bit of hand-holding users will soon h
[jira] [Comment Edited] (SOLR-11624) _default configset overwrites a a configset if collection.configName isn't specified even if a confiset of the same name already exists.
[ https://issues.apache.org/jira/browse/SOLR-11624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245844#comment-16245844 ] Shawn Heisey edited comment on SOLR-11624 at 11/9/17 3:42 PM: -- I agree with Erick. If a configset already exists, Solr should *not* be changing it just because a collection creation with the same name was requested. What if there were a hundred existing collections all using that configset? Having an option on the create command to force a config overwrite wouldn't be a bad idea, but that shouldn't be the default behavior. was (Author: elyograg): I agree with Erick. If a configset already exists, Solr should *not* be changing it just because a collection creation with the same name was requested. What if there were a hundred existing collections all using that configset? > _default configset overwrites a a configset if collection.configName isn't > specified even if a confiset of the same name already exists. > > > Key: SOLR-11624 > URL: https://issues.apache.org/jira/browse/SOLR-11624 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.2 >Reporter: Erick Erickson >Assignee: Erick Erickson > Attachments: SOLR-11624.patch > > > Looks like a problem that crept in when we changed the _default configset > stuff. > setup: > upload a configset named "wiki" > collections?action=CREATE&name=wiki&. > My custom configset "wiki" gets overwritten by _default and then used by the > "wiki" collection. > Assigning to myself only because it really needs to be fixed IMO and I don't > want to lose track of it. Anyone else please feel free to take it. -- 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] [Comment Edited] (SOLR-11624) _default configset overwrites a a configset if collection.configName isn't specified even if a confiset of the same name already exists.
[ https://issues.apache.org/jira/browse/SOLR-11624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245749#comment-16245749 ] Erick Erickson edited comment on SOLR-11624 at 11/9/17 2:43 PM: Ishan: Yeah, reverting overwriting the named configuration set would be my preference. BTW, the wonkiness I was getting with my patch was due to it being late and having a massive elevate.xml left over from chasing a totally unrelated issue so it might be viable after all. Feel free to grab this JIRA if you want, I only assigned it to myself to make sure I didn't lose track of it. was (Author: erickerickson): Ishan: Yeah, reverting overwriting the named configuration set would be my preference. BTW, the wonkiness I was getting with my patch was due to it being late and having a massive elevate.xml left over from chasing a totally unrelated issue so it might be viable after all. > _default configset overwrites a a configset if collection.configName isn't > specified even if a confiset of the same name already exists. > > > Key: SOLR-11624 > URL: https://issues.apache.org/jira/browse/SOLR-11624 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.2 >Reporter: Erick Erickson >Assignee: Erick Erickson > Attachments: SOLR-11624.patch > > > Looks like a problem that crept in when we changed the _default configset > stuff. > setup: > upload a configset named "wiki" > collections?action=CREATE&name=wiki&. > My custom configset "wiki" gets overwritten by _default and then used by the > "wiki" collection. > Assigning to myself only because it really needs to be fixed IMO and I don't > want to lose track of it. Anyone else please feel free to take it. -- 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
