[
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/26/08 12:07 AM:
-----------------------------------------------------------
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
* Whose usecases are not ver clear
* 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
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 (use UNLOAD to do that).
* SolrQueryRequest should have a method to let handlers know through which
alias this request is made
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 *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.
* SolrQueryRequest should have a method to let handlers know through which
alias this request is made
> 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.
