[
https://issues.apache.org/jira/browse/SOLR-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13729564#comment-13729564
]
Shawn Heisey commented on SOLR-5102:
------------------------------------
I agree with the idea of separating code and data. I have /opt/solr4, which
has a subset of what you find in example from the binary download, and
/index/solr4, which is my solr.solr.home. /index is a separate filesystem.
Everyone is talking about cloud mode being the only mode in a future major
release, most likely 5.0. If that happens, there's probably no reason to have
instanceDir and dataDir be configurable separately. There are possible
terminology confusions with dataDir if we go from solr.solr.home to
solr.data.dir. I was going to suggest that we might want to drop the data
subdirectory as well, but due to things like ExternalFileField, we might want
to hold off on that decision until later.
Thinking further along in a "break with legacy" path, "instanceDir" may be a
dead-end term too. When multicore first became a reality, it was "multiple
Solr instances in one webapp." I think it's grown beyond those roots.
> Simplify Solr Home
> ------------------
>
> Key: SOLR-5102
> URL: https://issues.apache.org/jira/browse/SOLR-5102
> Project: Solr
> Issue Type: Bug
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Fix For: 5.0
>
>
> I think for 5.0, we should re-think some of the variations we support around
> things like Solr Home, etc. We have a fair bit of code, I suspect that could
> just go away if make it easier by assuming there is a single solr home where
> everything lives. The notion of making that stuff configurable has outlived
> its usefulness
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
