[
https://issues.apache.org/jira/browse/SOLR-6671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15182846#comment-15182846
]
Jan Høydahl edited comment on SOLR-6671 at 3/7/16 10:33 AM:
------------------------------------------------------------
New patch
* Explicit test for verifying last path component of {{instanceDir}} is used
[~elyograg] thinking a bit more I agree it makes sense to use last component of
instanceDir as the folder name inside {{solr.data.home}}. Then the directory
structure is exactly the same below {{$SOLR_HOME/}} and {{$SOLR_DATA_HOME/}}.
So a core rename will not cause Solr to look for the index in another location,
and a core swap will load the index from the other instanceDir, even if name is
same after swap.
In SolrCloud rename and swap are not supported, so I assume that in most cases
{{instanceDir==core_name}} so it will be compatible.
Appreciate another pair of eyes, and tips for how to add more tests.
Questions:
* I am tempted to remove the support for setting {{solr.data.home}} as a
property to the {{<directoryFactory>}} element in {{solrconfig.xml}}. It is of
limited use to set such a root folder for each and every core, especially when
you already can set {{<dataDir>}} on a per core level. Any objections?
* I chose to put the variable {{Path dataHomePath}} in
{{DirectoryFactory.java}} where it is used in getDataHome(). But I initialize
the variable in {{CachingDirectoryFactory#init}} since I view this class as the
parent class of all file-system-based factories. The only exception I know is
{{HdfsDirectoryFactory}} which also subclasses {{CachingDirectoryFactory}}, but
it overrides both {{init}} and {{getDataHome}}. Comments?
* Anyone aware of code that calculates/assumes dataDir of a core without
calling {{DirectoryFactory#getDataHome}}? We could detect such though adding
{{solr.data.home}} to random test params but no need if we don't fear it to be
a problem?
This patch will also obviously trigger many changes in documentation which
currently assumes {{dataDir}} always being relative to {{solr.solr.home}} or
set per core by {{<dataDir>}}. Appreciate help in updating the patch with such
documentation changes :)
was (Author: janhoy):
New patch
* Explicit test for verifying last path component of {{instanceDir}} is used
[~elyograg] thinking a bit more I agree it makes sense to use last component of
instanceDir as the folder name inside {{solr.data.home}}. Then the directory
structure is exactly the same below {{$SOLR_HOME/}} and {{$SOLR_DATA_HOME/}}.
So a core rename will not cause Solr to look for the index in another location,
and a core swap will load the index from the other instanceDir, even if name is
same after swap.
In SolrCloud rename and swap are not supported, so I assume that in most cases
{{instanceDir==core_name}} so it will be compatible.
Appreciate another pair of eyes, and tips for how to add more tests.
Questions:
* I am tempted to remove the support for setting {{solr.data.home}} as a
property to the {{<directoryFactory>}} element in {{solrconfig.xml}}. It is of
limited use to set such a root folder for each and every core, especially when
you already can set {{<dataDir>}} on a per core level. Any objections?
* I chose to put the variable {{Path dataHomePath}} in
{{DirectoryFactory.java}} where it is used in getDataHome(). But I initialize
the variable in {{CachingDirectoryFactory#init}} since I view this class as the
parent class of all file-system-based factories. The only exception I know is
{{HdfsDirectoryFactory}} which also subclasses {{CachingDirectoryFactory}}, but
it overrides both {{init}} and {{getDataHome}}. Comments?
This patch will also obviously trigger many changes in documentation which
currently assumes {{dataDir}} always being relative to {{solr.solr.home}} or
set per core by {{<dataHome>}}. Appreciate help in updating the patch with such
documentation changes :)
> Introduce a solr.data.home as root dir for all data
> ---------------------------------------------------
>
> Key: SOLR-6671
> URL: https://issues.apache.org/jira/browse/SOLR-6671
> Project: Solr
> Issue Type: New Feature
> Components: SolrCloud
> Affects Versions: 4.10.1
> Reporter: Jan Høydahl
> Assignee: Jan Høydahl
> Fix For: master, 6.1
>
> Attachments: SOLR-6671.patch, SOLR-6671.patch, SOLR-6671.patch,
> SOLR-6671.patch, SOLR-6671.patch
>
>
> Many users prefer to deploy code, config and data on separate disk locations,
> so the default of placing the indexes under
> {{$\{solr.solr.home\}/$\{solr.core.name\}/data}} is not always wanted.
> In a multi-core/collection system, there is not much help in the
> {{solr.data.dir}} option, as it would set the {{dataDir}} to the same folder
> for all collections. One workaround, if you don't want to hardcode paths in
> your {{solrconfig.xml}}, is to specify the {{dataDir}} property in each
> {{solr.properties}} file.
> A more elegant solution would be to introduce a new Java-option
> {{solr.data.home}} which would be to data the same as {{solr.solr.home}} is
> for config. If set, all collections would default their {{dataDir}} as
> {{$\{solr.data.home\)/$\{solr.core.name\}/data}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
