[
https://issues.apache.org/jira/browse/SOLR-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14255192#comment-14255192
]
Yonik Seeley commented on SOLR-6787:
------------------------------------
{quote}
> That's my entire point... if it's hard to do X, look first into making X
> easier
We should do that too.
But it does not solve the problem
{quote}
It doesn't have to solve the *whole* top level use case you're thinking of...
that's not what I'm talking about at all.
I'm talking about API design in general. If X is hard, look to make it easier
in a way that benefits more than just the specific "problem" you're trying to
solve.
{quote}
> If it's easier to manage blobs this way
It won't be. Why would anyone want to store a blob and all the past versions of
it normally?
{quote}
People have asked to store blobs (binary fields), and people have asked for
versioning.
bq. I'm trying to dedupe a blob here , is it required normally ?
Yes, people have asked for deduping (that's why we have an update processor for
it now)
bq. I'm trying to ensure that there is always a name for a blob , is it
required normally ?
Yes, this is why required fields were added to the schema.
bq. This is a feature we need
The need for the *functionalltiy* of a feature says nothing about what form the
API/implementation should take.
Anyway, it feels like we're completely talking past each-other or something at
this point... it seemed pretty obvious to me that "blob" == "binary field".
> 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
