[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625304#action_12625304
]
Henri Biestro commented on SOLR-725:
------------------------------------
About being inconsistent, this is what this issue attempts to solve. :-)
And, yes, aliasing is a usefull feature: this allows to have one webapp path
that's constant for users (or links to persist) and allows to change the index
when reindexing is needed (reload is only good enough for non-schema related
modifications) without fuss..
Say you have your core declared as:
{code:xml}
<core name='version-2.1,public' .../>
{code}
Users refer to it through its *public* alias.
When you make schema/indexing changes that necessitate reindexing (hcnage
stopwords, stemming, etc):
# create your new core as 'version-3.0,dev'
# reindex the content
# verify your preferred queries do work appropriately
# alias('public', 'versions-3.0') ; which changes the link to point to the new
version and closes the old one (as soon as all queries have finished running)
# unalias('dev'); so you are ready for next version
> 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.
