[
https://issues.apache.org/jira/browse/SOLR-15751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687167#comment-17687167
]
Jason Gerlowski commented on SOLR-15751:
----------------------------------------
Hi [~Ajava] - sorry for the big delay in getting back to you here. (A blocker
for the v2 API work cropped up right around the time of your question and it's
kept me occupied until recently, see SOLR-16531)
bq. should we create a ColStatusAPI class with an endpoint
/v2/collections/<collName> or simply add the missing parameters to the existing
CollectionStatusAPI
IMO the latter. The way I look at these endpoints, they're offering similar or
identical functionality - just in differing levels of detail. So I think it'd
be best have the functionality in the same endpoint (and the same Java class).
That makes sense to me at least, though I'm curious what your inclination was?
> Create a v2 equivalent for 'COLSTATUS'
> --------------------------------------
>
> Key: SOLR-15751
> URL: https://issues.apache.org/jira/browse/SOLR-15751
> Project: Solr
> Issue Type: Sub-task
> Components: v2 API
> Reporter: Jason Gerlowski
> Priority: Major
> Labels: V2, newdev
>
> Solr's 'COLSTATUS' command under the v1 \{{/solr/admin/collections}} endpoint
> has no full v2 equivalent. The \{{/v2/collections/<collName>}} API has
> similar (identical?) output as a vanilla COLSTATUS request, but COLSTATUS can
> also return detailed index information that \{{/v2/collections/<collName>}}
> cannot expose. We should add parameters to this v2 API to expose similar data
> to achieve parity with the v1 COLSTATUS API.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
