[
https://issues.apache.org/jira/browse/SOLR-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14251925#comment-14251925
]
Yonik Seeley commented on SOLR-6787:
------------------------------------
{quote}
> why there would be a separate/different API to get/set the value of such a
> field.
Tell me how can I do that today.
{quote}
That's my entire point... if it's hard to do X, look first into making X easier
rather than creating a different method.
At the end of the day, there may still be some little things that warrant
separate API calls to make it easier. But if anything is identified to make
generic APIs more usable, that's a win.
Another way to look at it: It appears you've created an API specific to
".system"... but why should it be specific? If it's easier to manage blobs
this way, shouldn't users be able to use this on whatever collections / fields
they want?
> API to manage blobs in Solr
> ----------------------------
>
> Key: SOLR-6787
> URL: https://issues.apache.org/jira/browse/SOLR-6787
> Project: Solr
> Issue Type: Sub-task
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6787.patch, SOLR-6787.patch
>
>
> A special collection called .system needs to be created by the user to
> store/manage blobs. The schema/solrconfig of that collection need to be
> automatically supplied by the system so that there are no errors
> APIs need to be created to manage the content of that collection
> {code}
> #create your .system collection first
> http://localhost:8983/solr/admin/collections?action=CREATE&name=.system&replicationFactor=2
> #The config for this collection is automatically created . numShards for this
> collection is hardcoded to 1
> #create a new jar or add a new version of a jar
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
> @mycomponent.jar http://localhost:8983/solr/.system/blob/mycomponent
> # GET on the end point would give a list of jars and other details
> curl http://localhost:8983/solr/.system/blob
> # GET on the end point with jar name would give details of various versions
> of the available jars
> curl http://localhost:8983/solr/.system/blob/mycomponent
> # GET on the end point with jar name and version with a wt=filestream to get
> the actual file
> curl http://localhost:8983/solr/.system/blob/mycomponent/1?wt=filestream >
> mycomponent.1.jar
> # GET on the end point with jar name and wt=filestream to get the latest
> version of the file
> curl http://localhost:8983/solr/.system/blob/mycomponent?wt=filestream >
> mycomponent.jar
> {code}
> Please note that the jars are never deleted. a new version is added to the
> system everytime a new jar is posted for the name. You must use the standard
> delete commands to delete the old entries
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
