[
https://issues.apache.org/jira/browse/SOLR-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13822917#comment-13822917
]
Stefan Matheis (steffkes) commented on SOLR-5287:
-------------------------------------------------
so .. i got it, hopefully. what i'd say we do (in that separate ticket, as you
mentioned) is:
add a new page called "Files" (or something like that) which starts with a
typical file-tree, as we have it in the "Cloud"-Section already .. which
enables you to browse directories & files and view their contents.
right now this patch only allows file-uploads (or at least i didn't manage it
to accept raw text which i posted to this endpoint)? the code is using "input
streams" .. no idea if that is fileupload-specific?
because if we could post the content of a file .. we could offer two choices:
# upload a complete file, you have on your disk
# change into an "edit" mode .. and then post the changed file from within your
browser
which would basically mean you could modify your schema w/o the need to
download, modify & re-upload it.
that would be like we have it already on the "Data Import" Page .. where you
could send a {{dataConfig}} parameter, which then is used instead of the
persisted configuration (related code is in the
[DataImportHandler.java|http://svn.apache.org/viewvc/lucene/dev/trunk/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/DataImportHandler.java?view=markup#l129])
> Allow at least solrconfig.xml and schema.xml to be edited via the admin screen
> ------------------------------------------------------------------------------
>
> Key: SOLR-5287
> URL: https://issues.apache.org/jira/browse/SOLR-5287
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis, web gui
> Affects Versions: 4.5, 5.0
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Attachments: SOLR-5287.patch, SOLR-5287.patch, SOLR-5287.patch
>
>
> A user asking a question on the Solr list got me to thinking about editing
> the main config files from the Solr admin screen. I chatted briefly with
> [~steffkes] about the mechanics of this on the browser side, he doesn't see a
> problem on that end. His comment is there's no end point that'll write the
> file back.
> Am I missing something here or is this actually not a hard problem? I see a
> couple of issues off the bat, neither of which seem troublesome.
> 1> file permissions. I'd imagine lots of installations will get file
> permission exceptions if Solr tries to write the file out. Well, do a
> chmod/chown.
> 2> screwing up the system maliciously or not. I don't think this is an issue,
> this would be part of the admin handler after all.
> Does anyone have objections to the idea? And how does this fit into the work
> that [[email protected]] has been doing?
> I can imagine this extending to SolrCloud with a "push this to ZK" option or
> something like that, perhaps not in V1 unless it's easy.....
> Of course any pointers gratefully received. Especially ones that start with
> "Don't waste your effort, it'll never work (or be accepted)"...
> Because what scares me is this seems like such an easy thing to do that would
> be a significant ease-of-use improvement, so there _has_ to be something I'm
> missing.
> So if we go forward with this we'll make this the umbrella JIRA, the two
> immediate sub-JIRAs that spring to mind will be the UI work and the endpoints
> for the UI work to use.
> I think there are only two end-points here
> 1> list all the files in the conf (or arbitrary from <solr_home>/collection)
> directory.
> 2> write this text to this file
> Possibly later we could add "clone the configs from coreX to coreY".
> BTW, I've assigned this to myself so I don't lose it, but if anyone wants to
> take it over it won't hurt my feelings a bit....
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
