lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Gerlowski (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-12224) there is no API to read collection properties
Date Tue, 17 Apr 2018 18:10:00 GMT

    [ 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


Mime
View raw message