[
https://issues.apache.org/jira/browse/SOLR-15737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17617657#comment-17617657
]
Jason Gerlowski commented on SOLR-15737:
----------------------------------------
Payload classes are the main way that POST/PUT-based v2 APIs get passed their
arguments/parameters, so usually the payload class gets a field for any
parameter that the v1 code uses. There are a few exceptions to this: most
notable are any parameters which are specified in the API path itself (e.g.
collection-name) and don't need duplicated in the request-body/payload.
So how do you know what parameters are used by the v1 version of the API?
There's no easy way, except for reading the docs and then the code. (Ideally
this information could be retrieved from the docs alone, but they can be out of
date or omit rare parameters, so it's usually good to go to the source-code as
a double-check, and see how the "SolrQueryRequest" object is used there.)
> 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
