[
https://issues.apache.org/jira/browse/SOLR-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14241513#comment-14241513
]
Yonik Seeley commented on SOLR-6787:
------------------------------------
I'm not sure if there was a previous discussion that covers some of my
questions here... so I'll just shoot:
I think I understand some of the motivations around a special collection... but
I don't understand why there needs to be special APIs.
We should be able to support binary field types, and if our support is lacking,
we should fix that. Same with more REST-like APIs to query the collection or
retrieve data, and same for document versioning.
As far as the motivations for this issue... I see SOLR-6801 being linked. But
can a request handler / component in solrconfig.xml make use of a jar in
.system? Does this mean that .system will somehow need to come up before every
other collection in a cloud setup (or even in a stand-alone setup). Or is
persistence being handled some other way?
In some ways it feels like we're starting from the bottom up (which can be a
fine approach) without the use-cases / high level designs / goals being
documented or hashed out (unless I've missed some of these discussions...
pointers welcome). Does this stuff relate at all to the goal of providing a
smaller download and having an easier plugin mechanism for the stuff that's in
contrib?
> 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 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
