[
https://issues.apache.org/jira/browse/SOLR-5459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13826443#comment-13826443
]
Erick Erickson commented on SOLR-5459:
--------------------------------------
What do people think? Particularly [[email protected]] and [~steffkes]?
Loading things from Zk for every file save will be slow. OTOH, having this will
prevent people from shooting themselves in the foot. I see two ways to go about
this
1> every file save goes through the verification process. This is kind of
expensive for, say, changing the synonyms file. Or all the language files.
Or....
2> we (well, Stefan) provides a "test config" button that does this. This would
just be setting the "op" param to test, as "op=test". The user could save as
many different files as they wanted and then test once.
All in all, I like <2> better. It should still allow someone to recover from
messing things up provided they test before reloading the core. And it allows
people to bypass the whole verification process if, for some reason, creating
the temp core and trying to load it is broken due to my coding skill
deficiencies...
> Try loading a temporary core when saving a file in the admin UI config
> editing mode
> -----------------------------------------------------------------------------------
>
> Key: SOLR-5459
> URL: https://issues.apache.org/jira/browse/SOLR-5459
> Project: Solr
> Issue Type: Improvement
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Attachments: SOLR-5459.patch
>
>
> SOLR-5287 adds the ability to shoot yourself in the foot by changing core
> config files such that the core can't load, leading to having to go out into
> the filesystem and manually edit the files until you _can_ reload the core.
> This is clumsy at best.
> Mark Miller suggested creating a temporary core and trying to reload it
> before saving the "real" changes, which gives us an approach to the problem
> that seems relatively easy to implement.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
