[ 
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626206#action_12626206
 ] 

Noble Paul commented on SOLR-725:
---------------------------------

bq.Why not? It's like an atomic rename, except you aren't removing the source. 
Seems fine to me.

In reality, why would anyone want to alias to an existing name. It could have 
been a mistake as well. It is like a rename file to an existing file which is 
not allowed by an OS. We actually delete an existing one and rename to that.

bq.Why not? I could see arguments either way on this one.

The alias is just adding a name to the core . Why should it change the old name?


OK. why my arguments on these. 

1) Till now we have been assuming that the core always has a name. Just imagine 
I register a JMX object w/ a name and suddenly it is not more available with 
that name. It is not a very nice behavior. Actually adding alias to an existing 
object does not even have to reflect in JMX  because there is only one object. 
It is just a virtual URL to access a core  (actually this is the only need). 

2) For instance if I publish the url of a core to the outside and it does not 
become valid anymore even though the core is alive. (for replication (SOLR-561) 
we actually fix the url of the master and assume it will always be there). This 
change may break that assumption

So, I am afraid that we are suddenly changing a very well known behavior . And 
the symlink approach is my middle path to keep old things as it is and make the 
feature available . The symlink approach may not be the very 'ideal' solution , 
but it somehow struck to me as the most practical solution. That is it

> CoreContainer/CoreDescriptor/SolrCore cleansing
> -----------------------------------------------
>
>                 Key: SOLR-725
>                 URL: https://issues.apache.org/jira/browse/SOLR-725
>             Project: Solr
>          Issue Type: Improvement
>    Affects Versions: 1.3
>            Reporter: Henri Biestro
>         Attachments: solr-725.patch
>
>
> These 3 classes and the name vs alias handling are somewhat confusing.
> The recent SOLR-647 & SOLR-716 have created a bit of a flux.
> This issue attemps to clarify the model and the list of operations. 
> h3. CoreDescriptor: describes the parameters of a SolrCore
> h4. Definitions
> * has one name
>       ** The CoreDescriptor name may represent multiple aliases; in that 
> case, first alias is the SolrCore name
> * has one instance directory location
> * has one config & schema name
> h4. Operations
> The class is only a parameter passing facility
> h3. SolrCore: manages a Lucene index
> h4. Definitions
> * has one unique *name* (in the CoreContainer)
> **    the *name* is used in JMX to identify the core
> * has one current set of *aliases*
> **    the name is the first alias
> h4. Name & alias operations
> *     *get name/aliases*: obvious
> *     *alias*: adds an alias to this SolrCore
> *     *unalias*: removes an alias from this SolrCore
> *     *name*: sets the SolrCore name
> **            potentially impacts JMX registration
> *     *rename*: picks a new name from the SolrCore aliases
> **            triggered when alias name is already in use
> h3. CoreContainer: manages all relations between cores & descriptors
> h4. Definitions
> * has a set of aliases (each of them pointing to one core)
> **    ensure alias uniqueness.
> h4. SolrCore instance operations
> *     *load*: makes a SolrCore available for requests
> **            creates a SolrCore
> **            registers all SolrCore aliases in the aliases set
> **            (load = create + register)
> *     *unload*: removes a core idenitified by one of its aliases
> **            stops handling the Lucene index
> **            all SolrCore aliases are removed
> *     *reload*: recreate the core identified by one of its aliases
> *     *create*: create a core from a CoreDescriptor
> **            readies up the Lucene index
> *     *register*: registers all aliases of a SolrCore
>                       
> h4. SolrCore  alias operations
> *     *swap*: swaps 2 aliases
> **            method: swap
> *     *alias*: creates 1 alias for a core, potentially unaliasing a 
> previously used alias
> **            The SolrCore name being an alias, this operation might trigger 
> a SolrCore rename
> *     *unalias*: removes 1 alias for a core
> **            The SolrCore name being an alias, this operation might trigger 
> a SolrCore rename
>                       

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to