[jira] [Commented] (SOLR-13584) Explore prohibiting aliases and collections from having the same name.
[ https://issues.apache.org/jira/browse/SOLR-13584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875548#comment-16875548 ] Erick Erickson commented on SOLR-13584: --- Hmmm, would the hassle be more manageable if ZK was, indeed, the single source of truth? Currently, core discovery uses some information in core.properties to try to figure out where that replica fits in the grand scheme of things. So things like collection name need to be in core.properties and the info in core.properties and state.json need to be kept in sync. What if SolrCloud stored something like a GUID in the core.properties file rather than collection name and the like? Would that make a true rename easier by just requiring that the state.json node be updated and possibly the collections znode for the configname? This is straw-man, for discussion. It might not even be that invasive (going from memory here, so be warned). But at some point the core cloud descriptor is created from the core.properties file. Somehow (tm), if there was a GUID in the core.properties file we could find the corresponding state.json and "do the right thing". Lots of details here, which is why it's straw-man. Off the top of my head I can see these issues: * we'd need some migration path, akin to MIGRATESTATE that would assign IDs/guids to each replica and update core.properties * Humans read these things, so putting comments in the core.properties for all the current properties seems good * It'd be tricky to deal with orphans. I.e. some replica on some node that was down when the MIGRATESTATE was done. Maybe also add some kind of manual command that allowed individual replicas to be migrated? * All this pretty much assumes that once the (cloud) core descriptor is created properly, the rest of the code that uses it doesn't change much. * Maybe keep a rename_list in the collections znode to be able to find out where some replica belongs. * Hmmm, wait wait wait. Do we really need a GUID/ID or would the coreNodeName work? That's already unique, at least within a collection, we'd have to check if it was unique across collections. * And lots more no doubt, I'm wondering if this seems feasible and whether it's worth even thinking about > Explore prohibiting aliases and collections from having the same name. > -- > > Key: SOLR-13584 > URL: https://issues.apache.org/jira/browse/SOLR-13584 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Priority: Major > > Allowing aliases and collections to have the same name is fragile and a > potentially a data issue. I'll link in a few JIRAs illustrating this and one > at least where the discussion gets long. > Straw-man proposal to start things off. > Deprecate this ability now, and enforce it in 9.0. > We have to provide a graceful way for users to get themselves out of the > following currently-possible use-case. > * a collection C1 is created and all the front-end uses it. > * users want to atomically switch to a new collection for various reasons > * users create C2 and test it out. > * users create an alias C1->C2 > Let's discuss. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13584) Explore prohibiting aliases and collections from having the same name.
[ https://issues.apache.org/jira/browse/SOLR-13584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875475#comment-16875475 ] Andrzej Bialecki commented on SOLR-13584: -- We've tried implementing a true RENAME by actually renaming the collection state, configs, cores, etc ... it proved to be a lot of hassle, it took many tricky steps to do it and one failed step could have caused a permanent data loss - so in the end the solution with an alias was the only sensible way to do this. bq. a graceful way for users to get themselves out The use case that you outlined IS the primary reason for using aliases - if we remove this ability then we might as well remove aliases altogether. > Explore prohibiting aliases and collections from having the same name. > -- > > Key: SOLR-13584 > URL: https://issues.apache.org/jira/browse/SOLR-13584 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Priority: Major > > Allowing aliases and collections to have the same name is fragile and a > potentially a data issue. I'll link in a few JIRAs illustrating this and one > at least where the discussion gets long. > Straw-man proposal to start things off. > Deprecate this ability now, and enforce it in 9.0. > We have to provide a graceful way for users to get themselves out of the > following currently-possible use-case. > * a collection C1 is created and all the front-end uses it. > * users want to atomically switch to a new collection for various reasons > * users create C2 and test it out. > * users create an alias C1->C2 > Let's discuss. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13584) Explore prohibiting aliases and collections from having the same name.
[ https://issues.apache.org/jira/browse/SOLR-13584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875303#comment-16875303 ] Erick Erickson commented on SOLR-13584: --- Oops, that's not so good then ;( > Explore prohibiting aliases and collections from having the same name. > -- > > Key: SOLR-13584 > URL: https://issues.apache.org/jira/browse/SOLR-13584 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Priority: Major > > Allowing aliases and collections to have the same name is fragile and a > potentially a data issue. I'll link in a few JIRAs illustrating this and one > at least where the discussion gets long. > Straw-man proposal to start things off. > Deprecate this ability now, and enforce it in 9.0. > We have to provide a graceful way for users to get themselves out of the > following currently-possible use-case. > * a collection C1 is created and all the front-end uses it. > * users want to atomically switch to a new collection for various reasons > * users create C2 and test it out. > * users create an alias C1->C2 > Let's discuss. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13584) Explore prohibiting aliases and collections from having the same name.
[
https://issues.apache.org/jira/browse/SOLR-13584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875269#comment-16875269
]
Jan Høydahl commented on SOLR-13584:
{quote}I have not tested this at all, but "theoretically it should work".
{quote}
I have read a bit more about the RENAME command, and it actually does not
rename anything, it just adds an alias and makes it look like a rename happened
from the API's perspective. So I don't hink RENAME in its current form is a way
forward for your use case.
> Explore prohibiting aliases and collections from having the same name.
> --
>
> Key: SOLR-13584
> URL: https://issues.apache.org/jira/browse/SOLR-13584
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erick Erickson
>Priority: Major
>
> Allowing aliases and collections to have the same name is fragile and a
> potentially a data issue. I'll link in a few JIRAs illustrating this and one
> at least where the discussion gets long.
> Straw-man proposal to start things off.
> Deprecate this ability now, and enforce it in 9.0.
> We have to provide a graceful way for users to get themselves out of the
> following currently-possible use-case.
> * a collection C1 is created and all the front-end uses it.
> * users want to atomically switch to a new collection for various reasons
> * users create C2 and test it out.
> * users create an alias C1->C2
> Let's discuss.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13584) Explore prohibiting aliases and collections from having the same name.
[ https://issues.apache.org/jira/browse/SOLR-13584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875003#comment-16875003 ] Erick Erickson commented on SOLR-13584: --- One proposal for handing the use-case I outlined in the Jira statement is to use the Collections RENAME command to rename your original collection to something else_._ I have not tested this at all, but "theoretically it should work". > Explore prohibiting aliases and collections from having the same name. > -- > > Key: SOLR-13584 > URL: https://issues.apache.org/jira/browse/SOLR-13584 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Priority: Major > > Allowing aliases and collections to have the same name is fragile and a > potentially a data issue. I'll link in a few JIRAs illustrating this and one > at least where the discussion gets long. > Straw-man proposal to start things off. > Deprecate this ability now, and enforce it in 9.0. > We have to provide a graceful way for users to get themselves out of the > following currently-possible use-case. > * a collection C1 is created and all the front-end uses it. > * users want to atomically switch to a new collection for various reasons > * users create C2 and test it out. > * users create an alias C1->C2 > Let's discuss. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13584) Explore prohibiting aliases and collections from having the same name.
[ https://issues.apache.org/jira/browse/SOLR-13584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874998#comment-16874998 ] Erick Erickson commented on SOLR-13584: --- SOLR-13122 in particular has some discussion, but changing this behavior is way outside the scope of that JIRA. Anyone working on this should read it though. SOLR-13583 illustrates how allowing aliases and collections to have the same name can and has gone wrong. > Explore prohibiting aliases and collections from having the same name. > -- > > Key: SOLR-13584 > URL: https://issues.apache.org/jira/browse/SOLR-13584 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Priority: Major > > Allowing aliases and collections to have the same name is fragile and a > potentially a data issue. I'll link in a few JIRAs illustrating this and one > at least where the discussion gets long. > Straw-man proposal to start things off. > Deprecate this ability now, and enforce it in 9.0. > We have to provide a graceful way for users to get themselves out of the > following currently-possible use-case. > * a collection C1 is created and all the front-end uses it. > * users want to atomically switch to a new collection for various reasons > * users create C2 and test it out. > * users create an alias C1->C2 > Let's discuss. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
