You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Jason Gerlowski (JIRA)" <ji...@apache.org> on 2018/04/17 18:10:00 UTC
[jira] [Comment Edited] (SOLR-12224) there is no API to read
collection properties
[ https://issues.apache.org/jira/browse/SOLR-12224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16441281#comment-16441281 ]
Jason Gerlowski edited comment on SOLR-12224 at 4/17/18 6:09 PM:
-----------------------------------------------------------------
Small +1 to including the collection props in CLUSTERSTATUS. I get your point Shawn, that CLUSTERSTATUS is supposed to be about the cluster, not the collection. But "holding the line" on that distinction seems like a lost battle: we already allow filtering CLUSTERSTATUS by the collection(s)/shard(s) you care about, and the API includes many other bits of collection state in the response (shard hash ranges, replica/shard state, leadership, etc.). I'm not sure what's more intuitive in general, but speaking only for myself, CLUSTERSTATUS is usually the API I think to hit when I want to see the overview for a collection (which in my mind includes any properties). I don't care strongly, just my 2 cents.
I'm curious too whether anyone cares how this is exposed in the v2 API. That's the "future" I guess, so worth some discussion. Would we expose this under {{GET v2/c/collection-name}} (which lines up pretty well with {{action=CLUSTERSTATUS&collection=collection-name}}), or does it deserve its own collection subpath, like {{GET v2/c/collection-name/properties}}?
was (Author: gerlowskija):
Small +1 to including the collection props in CLUSTERSTATUS. I get your point Shawn, that CLUSTERSTATUS is supposed to be about the cluster, not the collection. But "holding the line" on that distinction seems like a lost battle: we already allow filtering CLUSTERSTATUS by the collection(s)/shard(s) you care about, and the API includes many other bits of collection state in the response (shard hash ranges, replica/shard state, leadership, etc.). I'm not sure what's more intuitive in general, but speaking only for myself, CLUSTERSTATUS is usually the API I think to hit when I want to see the overview for a collection. I don't care strongly, just my 2 cents.
I'm curious too whether anyone cares how this is exposed in the v2 API. That's the "future" I guess, so worth some discussion. Would we expose this under {{GET v2/c/collection-name}} (which lines up pretty well with {{action=CLUSTERSTATUS&collection=collection-name}}), or does it deserve its own collection subpath, like {{GET v2/c/collection-name/properties}}?
> there is no API to read collection properties
> ---------------------------------------------
>
> Key: SOLR-12224
> URL: https://issues.apache.org/jira/browse/SOLR-12224
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Affects Versions: 7.3
> Reporter: Hendrik Haddorp
> Priority: Major
>
> Solr 7.3 added the COLLECTIONPROP API call (https://lucene.apache.org/solr/guide/7_3/collections-api.html#collectionprop) that allows to set arbitrary properties on a collection. There is however no API call that returns the data. The only option is to manually read out the collectionprops.json file in ZK below the collection.
> Options could be that the COLLECTIONPROP command has an option to retrieve properties, have a special command to list the properties and/or to have the properties listed in the clusterstatus output for a collection.
> Would be great if SolrJ would also be supported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org