[
https://issues.apache.org/jira/browse/SOLR-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14255840#comment-14255840
]
Alexandre Rafalovitch commented on SOLR-6787:
---------------------------------------------
Looking at the patch, it seems an improvement of couple of universal pieces of
code plus hard-coding a specific collection setup and URL structure. This is a
very basic view, as I am not totally familiar with the codebase, but perhaps I
can help to find the middle ground.
The universal changes seem to be about allow post tool and other code to better
handle binary content. So, that's already generic.
The hardcoded schema/solrconfig look to me like they should be something like a
special-case configset that's perhaps stored in the distribution jar. Which
would be separate new, but I am sure useful, functionality. The hardcoded shard
requirements look to me like something that would be a documentation issue,
especially since we require the user to create the collection anyway. Or maybe
it should be a variable somewhere that can be carried along with the configset
(core.properties?)
The other part is about loading and serving a binary blob. We already have
BinaryField and in fact that's what's used under the covers in the hard-coded
schema. How do we populate/extract things from it now? This implementation
looks useful, it could just have an assertion/requirement that whatever the
query string is, the result should be a single item, single field which would
then be binary streamed to the user.
There was some de-duplication code. Could it not be an UpdateRequestProcessor
of some sort?
Finally, there is the convenience API that hardcodes blob name and version as
URL parameters. This may be hard to make generic but is it really that big a
deal given that this particular use-case is internal (right?). The internal
code could generate query parameters just as easily as the REST style.
> 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
