[
https://issues.apache.org/jira/browse/SOLR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572080#action_12572080
]
henrib edited comment on SOLR-350 at 2/27/08 9:44 AM:
-------------------------------------------------------------
Otis, reading your requirements, I'd be considering using a Solr core (the
"metacore") to handle an indexed version of multicore.xml; if you have a few
thousands indices, it might be convenient to use queries in some occasions to
select/retrieve/operate on one/many of them.
The xml version of the multicore persistent file could be written at
application/multicore shutdown and the Lucene based one could be recreated at
application/multicore startup; creating a new index would just induce creating
a new document in the multicore core (and in fact all CRUD operations could be
handled that way) and we'd benefit from Solr autocommit feature & al, tackling
your functional requirements reusing well-known capabilities & code.
This also removes the "hack" loop used to find a core to work with when issuing
a multicore/admin request (and the getDefaultCore call). Got a patch running
for this now if this seems interesting.
On configuring easily the data/index dir from multicore.xml, it seems we all
agree that variables definitions should be able to allow just that; the
non-extensible version of the feature (see previous comment)- where we dont
allow the user to augment the environment but only expose 'solr.multicore.*'-
did not trigger any comment yet, Otis/Hoss/Ryan what do you think of it ?
was (Author: henrib):
Otis, reading your requirements, I'd be considering using a Solr core to
handle an indexed version of multicore.xml; if you have a few thousands
indices, it might be convenient to use queries in some occasions to
select/retrieve one/many of them.
The xml version of the multicore persistent file could be written at
application/multicore shutdown and the Lucene based one could be recreated at
application/multicore startup; creating a new index would just induce creating
a new document in the multicore core (and in fact all CRUD operations could be
handled that way) and we'd benefit from Solr autocommit feature & al, tackling
your functional requirements reusing well-known capabilities & code.
For ~10 indices/cores, this seems like overkill though...
On configuring easily the data/index dir from multicore.xml, it seems we all
agree that variables definitions should be able to allow just that; the
non-extensible version of the feature (see previous comment)- where we dont
allow the user to augment the environment but only expose 'solr.multicore.*'-
did not trigger any comment yet, Otis/Hoss/Ryan what do you think of it ?
> 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, 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.
