lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Potter (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory
Date Wed, 26 Nov 2014 23:34:13 GMT

    [ https://issues.apache.org/jira/browse/SOLR-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14226995#comment-14226995
] 

Timothy Potter commented on SOLR-3619:
--------------------------------------

I've addressed most of [~arafalov]'s concerns in the latest commit. However, I didn't create
the example cores in a solr home under example (as suggested) because what happens if the
user does the following?

{code}
bin/solr -e schemaless
bin/solr create_core -n my_core
{code}

Now {{my_core}} lives under {{example/solr/my_core}} vs. {{server/solr/my_core}}, which is
exactly where we were before this ticket - setting up the user to create non-example stuff
under examples! In other words, we can't assume the user isn't going to create their own cores
after starting up an example so it doesn't make sense to me to create things under a different
solr home (other than the default server/solr). Moreover, once we start using a different
solr home, then the user would have to know to restart the server with the -s parameter, i.e.
{{bin/solr restart -s example/solr}}.

Next, if you re-run an example, such as:

{code}
bin/solr -e techproducts
bin/solr stop -all
bin/solr -e techproducts
{code}

Then the script does the correct thing (fires up Solr, tries to re-create the existing core
(which fails), and then re-indexes the docs but that's harmless IMO).

Also, I went with the selective cloning of the server directory when running the cloud example.
Agreed it's a bit of a maintenance headache, but Solr needs a default solr.solr.home set in
order to initialize, so at some point, there may be cores in the {{server/solr}} directory.
In other words, if the user does:

{code}
bin/solr start -p 8983
bin/solr create_core -n foo
bin/solr stop -p 8983
bin/solr -e cloud
{code}

Then the foo instanceDir is in {{server/solr}} and we don't want to pull that over when creating
node1. At least now with the latest changes, it's safe to run the -e cloud example after doing
other things that affect the server/solr directory.

In short, I think we should only take this immutable master concept so far, but at some point,
there's either going to be a dirty solr home directory some where OR the user is going to
have to be burdened with passing the correct -s param, which is bad for getting started.

> Rename 'example' dir to 'server' and pull examples into an 'examples' directory
> -------------------------------------------------------------------------------
>
>                 Key: SOLR-3619
>                 URL: https://issues.apache.org/jira/browse/SOLR-3619
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Mark Miller
>            Assignee: Timothy Potter
>             Fix For: 5.0, Trunk
>
>         Attachments: SOLR-3619.patch, SOLR-3619.patch, SOLR-3619.patch, managed-schema,
server-name-layout.png, solrconfig.xml
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message