Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
Message-ID: <1570446191.1219730024195.JavaMail.jira@brutus>
Date: Mon, 25 Aug 2008 22:53:44 -0700 (PDT)
From: "Noble Paul (JIRA)" <jira@apache.org>
To: solr-dev@lucene.apache.org
Subject: [jira] Issue Comment Edited: (SOLR-725)
 CoreContainer/CoreDescriptor/SolrCore cleansing
In-Reply-To: <896229925.1219654665981.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

noble.paul edited comment on SOLR-725 at 8/25/08 10:51 PM:
-----------------------------------------------------------

bq.Paul - I haven't looked at Henri's patch, but like Henri I also don't follow your logic. You give an example of using core alias

My example uses SWAP . SWAP is a indeed a useful feature and SWAP does not use ALIAS . The usecase is this. I wish to start core and ensure that it is initialized properly . If it does I wish to replace that with another core .  

My concern here , 
*  We have added a feature called ALIAS 
*  Nobody has a compelling usecase for that. 
*  Because of this feature some very useful methods are implemented inconsistently. As Yonik says "core should be independent of how it is named" . But as things stand we are removing some commonly useful methods for a feature which does not have a usecase. 

OK. Now that we already have ALIAS as a feature I propose the following behavior ,

* let the getName() methods remain as is. 
* An ALIAS *must not* rename a core. It should just add another mapping in the core container. The only command that should change a core's name should be SWAP
* An ALIAS command *must not* succeed if the new name is already registered for another core. If a user wish to do so UNLOAD that core , or if it is an alias UNALIAS that name before trying this.
* The solr.xml <core> tag must keep the name as the primary name. We can add an extra attribute 'alias' which can take multiple names. This is already discussed in SOLR-350. 
* UNALIAS command can be added . It can just remove an ALIAS if it exists . But it must not be able to remove the primary name.

      was (Author: noble.paul):
    bq.Paul - I haven't looked at Henri's patch, but like Henri I also don't follow your logic. You give an example of using core alias

My example uses SWAP . SWAP is a indeed a useful feature and SWAP does not use ALIAS . The usecase is this. I wish to start core and ensure that it is initialized properly . If it does I wish to replace that with another core .  

My concern here , 
*  We have added a feature called ALIAS 
*  Nobody has a compelling usecase for that. 
*  Because of this feature some very useful methods are implemented inconsistently. As Yonik says "core should be independent of how it is named" . But as things stand we are removing some commonly useful methods for a feature which does not have a usecase. 

OK. Now that we already have ALIAS as a feature I propose the following behavior

* let the getName() methods remain as is. 
* An ALIAS *must not* rename a core. It should just add another mapping in the core container. The only command that should change a core's name should be SWAP
* An ALIAS command should not succeed if the new name is already registered for another core. 
* The solr.xml <core> tag must keep the name as the primary name. We can add an extra attribute 'alias' which can take multiple names. This is already discussed in SOLR-350. 
* UNALIAS command can be added . It can just remove an ALIAS if it exists . But it must not be able to remove the primary name.
  
> 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.