[
https://issues.apache.org/jira/browse/SOLR-15737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17617353#comment-17617353
]
Sanjay edited comment on SOLR-15737 at 10/13/22 11:43 PM:
----------------------------------------------------------
Thanks for the detailed info!
As per my understanding, [~gerlowskija] Collection API when create backup they
do rely on 'BACKUPCORE' action. But they never call 'BACKUPCORE' action via
HTTP(afaik).
And If no one (Needs confirmation from others) uses the HTTP version of
'BACKUPCORE', then do we even need to create v2 api for it?
was (Author: duttsanjay):
As per my understanding, [~gerlowskija] Collection API when create backup they
do rely on 'BACKUPCORE' action. But they never call 'BACKUPCORE' action via
HTTP(afaik).
And If no one (Needs confirmation from others) uses the HTTP version of
'BACKUPCORE', then do we even need to create v2 api for it?
> Ensure all (desired) v1 APIs have v2 equivalent
> -----------------------------------------------
>
> Key: SOLR-15737
> URL: https://issues.apache.org/jira/browse/SOLR-15737
> Project: Solr
> Issue Type: Improvement
> Components: v2 API
> Reporter: Jason Gerlowski
> Priority: Major
> Labels: V2, newdev
>
> Nothing in Solr's build system enforced consistency across v1<->v2, so as a
> result today, many v1 APIs (or API sub-commands) have no v2 counterpart. In
> some rare cases this was intentional (e.g.
> \{{/solr/admin/collections?action=MIGRATESTATEFORMAT}} ), but in most cases
> it's the result of unintentional omission.
> This ticket aims to remedying this, by finding v1 APIs without a v2
> counterpart and adding them where desired.
--
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
