[
https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-14907:
------------------------------
Description:
After SOLR-10391 was implemented, users are now able to overwrite existing
configSets using the configSet API. However the files uploaded are still
required to be zipped and indexed from the base configSet path in ZK. Users
might want to just update a single file, such as a synonyms list, and not have
to tar it up first.
The proposed solution is to add parameters to the UPLOAD configSet action, to
allow this single-file use case. This would utilize the protections already
provided by the API, such as maintaining the trustiness of configSets being
modified.
This feature is part of the solution to replace managed resources, which is
planned to be deprecated and removed by 9.0 (SOLR-14766).
The following APIs are being proposed:
V1:
Adding to the configSet upload one urlParam, filePath:
{code}
"http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet&filePath=solrconfig.xml&overwrite=true";
{code}
V2:
* Uploading a configSet:
{code} PUT - /api/cluster/configs/{name}{code}
* Uploading a file in a configSet:
{code} PUT - /api/cluster/configs/{name}/{filename}{code}
was:
After SOLR-10391 was implemented, users are now able to overwrite existing
configSets using the configSet API. However the files uploaded are still
required to be zipped and indexed from the base configSet path in ZK. Users
might want to just update a single file, such as a synonyms list, and not have
to tar it up first.
The proposed solution is to add parameters to the UPLOAD configSet action, to
allow this single-file use case. This would utilize the protections already
provided by the API, such as maintaining the trustiness of configSets being
modified.
This feature is part of the solution to replace managed resources, which is
planned to be deprecated and removed by 9.0 (SOLR-14766).
The following APIs are being proposed:
V1:
Adding to the configSet upload one urlParam, filePath:
"http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet&filePath=solrconfig.xml&overwrite=true";
V2:
* Uploading a configSet:
** PUT - /cluster/configs/\{name}
* Uploading a file in a configSet:
** PUT - /cluster/configs/\{name}/\{filename}
> Support single file upload/overwrite in configSet API
> -----------------------------------------------------
>
> Key: SOLR-14907
> URL: https://issues.apache.org/jira/browse/SOLR-14907
> Project: Solr
> Issue Type: Improvement
> Components: configset-api
> Reporter: Houston Putman
> Assignee: Houston Putman
> Priority: Major
> Fix For: 8.7
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> After SOLR-10391 was implemented, users are now able to overwrite existing
> configSets using the configSet API. However the files uploaded are still
> required to be zipped and indexed from the base configSet path in ZK. Users
> might want to just update a single file, such as a synonyms list, and not
> have to tar it up first.
> The proposed solution is to add parameters to the UPLOAD configSet action, to
> allow this single-file use case. This would utilize the protections already
> provided by the API, such as maintaining the trustiness of configSets being
> modified.
> This feature is part of the solution to replace managed resources, which is
> planned to be deprecated and removed by 9.0 (SOLR-14766).
> The following APIs are being proposed:
> V1:
> Adding to the configSet upload one urlParam, filePath:
> {code}
> "http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet&filePath=solrconfig.xml&overwrite=true";
> {code}
> V2:
> * Uploading a configSet:
> {code} PUT - /api/cluster/configs/{name}{code}
> * Uploading a file in a configSet:
> {code} PUT - /api/cluster/configs/{name}/{filename}{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
