[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625347#action_12625347
]
Henri Biestro commented on SOLR-725:
------------------------------------
bq . This does not look like a useful way of using aliases. This is one extra
step which could have been avoided.
You used aliases in your own example. So I must have missed your point.
bq. We just blindly do a reload assuming everything is fine. So no testing.
Your operational rules are different than those I'm constrained to.
I'm merely trying to contribute back the solution to some problems I've
encountered.
bq . the alias feature is implemented in a very wrong way
Again, this is what this issue attempts to address.
It's not intended to be confrontational.
bq. I am yet to see a valid usecase.
Besides those already mentioned (& I guess Yonik may have more since he
introduced aliasessolving solr-647), there are plenty of other features that
can come out from having a different path to use the same core; security,
rendering, etc.
Courtesy aside, I do respect functional needs of others & their implications
although I don't understand all of them; I wish this was a community value.
> 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.
