[ https://issues.apache.org/jira/browse/SOLR-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14251750#comment-14251750 ]
Alexandre Rafalovitch commented on SOLR-6787: --------------------------------------------- Why do you need a user to create the collection first? Especially since the config/etc is hardcoded and it needs to be present on every node? Wouldn't it make sense for collection to be just auto-created on first access? Or is there a specific flexibility that only user can decide on? Also, if you have heterogeneous environment, the current implementation would require a union of all blobs, right? As in, every node will need to have all possible blobs/jars, not just the jars the collections on that node have. Finally, does the _.system_ collection show up on the Admin UI? Are there implications/restrictions of that? > 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