[ 
https://issues.apache.org/jira/browse/SOLR-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14255951#comment-14255951
 ] 

Yonik Seeley commented on SOLR-6787:
------------------------------------

bq. If these were the requirements , I fail to see them captured in a ticket.

I think you're maybe confusing open source development with commercial software 
development ;-)
We don't really work off of "requirements", and we certainly strive to do 
better than just meet requirements.
We need to thinking about the *potential* requirements/desires of the thousands 
of users (and potential new users) of Solr.
We need to think hard about APIs since they tend to stick around a long time.

I was essentially asking "can we do better?".  It doesn't mean the answer is 
"yes"... but you should have hopefully thought about it.

Here's some stupid simple hypothetical examples of what I'm talking about:

Hypothetical:  I need to add three numbers together in a function query... I'm 
going to add a "add3(x,y,z)".  Can we do better?  yeah... maybe we should just 
make the existing "add()" take any number of arguments.  There was no 
"requirement" to do more than 3... but that doesn't matter in the slightest.

Hypothetical: My common function add(mul(a,b),mul(c,d)) was too slow for my 
requirements, so I added a custom add_prods(a,b,c,d) that gets rid of the 
overhead and is now faster.  Can we do better?  Yes... let's not change the API 
for this special case and instead look for these patterns and automatically 
optimize them. 


> 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

Reply via email to