[jira] [Commented] (SOLR-15736) Enforce ongoing v1<->v2 API consistency

["Jason Gerlowski (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-15736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17693171#comment-17693171 ] 

Jason Gerlowski commented on SOLR-15736:
----------------------------------------

While this work isn't yet complete, we have largely settled on a means of achieving this: moving the API logic into the v2 definition and having the v1 code reuse that logic by calling the v2 interfaces.  For APIs implemented in this way, it's impossible to add or remove parameters, etc. without doing so in the v2 code.

In light of that, this ticket has essentially become a duplicate of SOLR-16370.  There's no path to ensuring consistency that doesn't involve finishing SOLR-16370, and there's nothing additional required once SOLR-16370 is completed.  So I'm going to close this ticket out as a duplicate.

> Enforce ongoing v1<->v2 API consistency
> ---------------------------------------
>
>                 Key: SOLR-15736
>                 URL: https://issues.apache.org/jira/browse/SOLR-15736
>             Project: Solr
>          Issue Type: Improvement
>          Components: v2 API
>            Reporter: Jason Gerlowski
>            Assignee: Jason Gerlowski
>            Priority: Major
>              Labels: V2
>          Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Since its inception, keeping the v1 and v2 APIs in sync has been a serious challenge. Historically, nothing has enforced consistency across the two APIs - to the somewhat predictable result that developers continued to add parameters and even whole endpoints to v1 without realizing they were leaving out the similar changes to v2.
> SOLR-15737 strives to ensure that each v1 API has a v2 equivalent, but this only ensures consistency at a point in time. To prevent any new gaps from opening up, we should find some way to ensure that any further API additions include v2.
> Up for debate is what the best way to do this is.
> Though other better ones might be possible, one approach would be to refactor SolrJ's SolrRequest classes to be implemented to use the annotated v2 POJOs that define many V2 APIs. This would force devs looking to expose a new API param in SolrJ to first add it to the corresponding V2 Api POJO. (Though it wouldn't provide much enforcement for totally new API endpoints.)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org