[
https://issues.apache.org/jira/browse/SOLR-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505927
]
Yonik Seeley commented on SOLR-265:
-----------------------------------
Doesn't this have thread-saftey and unsolvable consistency issues?
It doesn't seem like a specific instance of IndexSchema should change in the
middle of a request.
Perhaps it's better to create a new IndexSchema, and keep track of the current
schema in the SolrCore (a dependency that wasn't there before, but someone
needs to keep track of the current schema if it can change).
> Make IndexSchema updateable in live system
> ------------------------------------------
>
> Key: SOLR-265
> URL: https://issues.apache.org/jira/browse/SOLR-265
> Project: Solr
> Issue Type: Improvement
> Components: update
> Affects Versions: 1.3
> Reporter: Will Johnson
> Priority: Minor
> Fix For: 1.3
>
> Attachments: IndexSchemaReload.patch
>
>
> I've seen a few items on the mailing lists recently surrounding updating a
> schema on the file system and not seeing the changes get propagated. while I
> think that automatically detecting schema changes on disk may be unrealistic,
> I do think it would be useful to be able to update the schema without having
> to bounce the webapp. the forthcoming patch adds a method to SolrCore to do
> just that as well as a request handler to be able to call said method.
> The patch as it exists is a straw man for discussion. The one thing that
> concerned me was making IndexScheam schema non-final in SolrCore. I'm not
> quite sure why it needs to be final to begin with so perhaps someone can shed
> some light on the situation. Also, I think it would be useful to be able to
> upload a schema through the admin GUI, have it persisted to disk and then
> call relaodSchema()but that seemed like a good bit of effort for a patch that
> might not even be a good idea.
> I'd also point out that this specific problem is one I've been trying to
> address recently and while I think it could be solved with various dynamic
> fields the combination of all the options for fields seemed to create too
> many variables to make useful dynamic name patterns.
> Thoughts?
> - will
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
