[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626993#action_12626993
]
Henri Biestro commented on SOLR-725:
------------------------------------
Paul
Would it be fair to say that you fear the alias/hardlink feature would allow
users to make configuration/manipulation mistakes more easily wrt replication?
As is, it does not remove any feature nor forces anyone into using them; thus,
it's not breaking anything nor does it make your use-cases more difficult. It
might be used in a wrong way and I'm not arguing that since it creates
possibility and more choices, it can lead to more mistakes. And in that sense,
some users could end up not being able to use the feature you contribute. I do
believe though that it's better to describe & educate on best practices than
constrain usage.
I also understand that for solr-727/solr-561, you need some URLs to be stable
(which is what the "cool uris dont change" motto advocates and this is a good
rule). Allowing more ways to alias a core is an easier path (no pun intended)
to this than constraining users into having just one. I can even dedicate a URL
to replication that is not something my end-users would ever need to know
(since I dont think my deployment constraints or choices should reflect into
what they use).
Aliasing (the hardlink model) is not adverse to replication usage conventions &
needs, it instead does allow to respect them more easily with more flexibility.
Just a different Solr user & contributor opinion.
> 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, solr-725.patch, 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
> * *rename*: renames a core
> h3. CoreAdminHandler: handles CoreContainer operations
> * *load*/*create*: CoreContainer load
> * *unload*: CoreContainer unload
> * *reload*: CoreContainer reload
> * *swap*: CoreContainer swap
> * *alias*: CoreContainer alias
> * *unalias*: CoreContainer unalias
> * *rename*: CoreContainer rename
> * *persist*: CoreContainer persist, writes the solr.xml
> * *stauts*: returns the status of all/one SolrCore
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
