[
https://issues.apache.org/jira/browse/SOLR-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505938
]
Will Johnson commented on SOLR-265:
-----------------------------------
After doing some more thinking about the issue after I submitted the
patch I agree that there probably are some threading issues to work out.
I was working on another approach that was much larger (only keep 1 copy
in SolrCore accessible by getSchema() and add protection there) but that
required a much larger code change than the one posted so I went with
the shorter to at least promote discussion. If the single schema
getter() makes sense, I'll be happy to provide such a patch.
There do seem to be other alternatives though:
First is a ModifySchema handler that could support adding fields etc
which should be easier to defend against from a synchronization
standpoint. At least there are fewer times when fields.clear() has been
called but new values have not been added back. As this is all I care
about at the moment I'd be happy, but I assume someone might want to do
something else more complex.
The second is to wrap up the clear/repopulate methods with some basic
protection but actually allow different schemas inside a single request.
This could be done by requiring all new schemas to be 'compatible' in
some defined way. Since there doesn't seem to be any validation that
goes on if I stop the app, change the schema and then restart it,
compatible might just mean valid xml. If field 'new_x' suddenly appears
during the middle of my post it shouldn't have any effect as my posted
data won't contain 'new_x.' from a client's contractual perspective, if
you want new fields processed correctly you have to wait for
updateSchema to finish.
In any case, it seems to me that restarting a webapp and suffering
downtime is a heavy price to pay just to add a new field or even to just
change an existing field property.
- will
> 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.
