[
https://issues.apache.org/jira/browse/SOLR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564212#action_12564212
]
Hoss Man commented on SOLR-350:
-------------------------------
I agree generalizing variables is somewhat significant, and a larger scope then
just what's being talked about here -- perhaps that's part of the disconnect
... I'm taking it as a given that it's a problem that needs to be solved before
multicores can really be useful -- so if we have to solve that problem, and
that solution can also solve the common dataDir problem, let's not have an
alternate solution to hte dataDir problem that is "non transparent" to people
reading the configs.
(my assumption being based on the impression that we can't really support a lot
of the use cases people have talked about without having at a minimum a way to
know use the "name" of the current core as a variable in the configs --
postCommit hooks being one example of a place where this info will be crucial)
In a nutshell: if we know we are going to need variables, then instead of
introducing a new <multicore dataDir="..."> option now (which if used changes
the meaning of the <dataDir/>) let's solve the broader problem of passing
arbitrary variables to a SolrCore. we can still commit all of the other stuff
you guys have been working on, lets just set the dataDir issue aside until we
add the variable support.
*BUT!!!* part of your comment has me worried that i'm misunderstanding how
<multicore dataDir="..."> works, you just said...
bq. The multicore dataDir attributes is a default directory/roots that can be
overriden by core definitions
...how can it be overridden? My understanding based on your early comment was
that <multicore dataDir="..."> was the directory that the
<dataDir>...</dataDir> options in each solrconfig.xml would be relative to
...do you mean that in the multicore.xml file, each <core/> can have a dataDir
option? ... if so that doesn't really solve the concern I have: people should
be able to read a solrconfig.xml and understand when there are outside
inflluences on that config...
bq. Plus it could be argued that it increases the element of surprise or at
least the potential for side effects.
bq. If a solrconfig/schema refers to a variable that can be superseded in a
multicore.xml, the behavior of a core is explictly dependant on whether it is
loaded in a multicore configuration of not. I agree that being explicit rather
than implicit is better but this does modify behavior even deeper nevertheless.
I disagree ... it's true that using a "variables" approach the evaluation of a
solrconfig.xml would be dependent on the environment it's run in (ie: is there
a multicore.xml? are variables set in it? are any system properties set?) but
the evaluation of solrconfog.xml is already dependent on it's environment (ie:
what is the solr home? are any system properties set?) ... my point is that
when a human is *reading* a config with variables in it, it is crystal clear
that there is an environmental factor that will affect the behavior. If a
person reads a solrconfig.xml that contains this line...
{code}
<dataDir>${my.special.dir}/data</dataDir>
{code}
...then it's very obvious that the location of the data will depends on the
environment the core is run in (in which "my.special.dir" must be set, either
as a system property or as a multicore.xml variable -- the point being it's an
*known* external factor). The approach you guys have been talking about though
(assuming i'm understanding it correctly) would take away that transparency --
people could look at a solrconfig.xml that looks like this...
<dataDir>data</dataDir>
...and that that could mean anything depending on whether or not this
solrconfig.xml is running in a multicore setup or not.
> Manage Multiple SolrCores
> -------------------------
>
> Key: SOLR-350
> URL: https://issues.apache.org/jira/browse/SOLR-350
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.3
> Reporter: Ryan McKinley
> Attachments: SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch,
> SOLR-350-MultiCore.patch, SOLR-350-Naming.patch, SOLR-350-Naming.patch,
> solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch,
> solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch
>
>
> In SOLR-215, we enabled support for more then one SolrCore - but there is no
> way to use them yet.
> We need to make some interface to manage, register, modify avaliable SolrCores
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
