[
https://issues.apache.org/jira/browse/SOLR-15736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17573807#comment-17573807
]
Jason Gerlowski commented on SOLR-15736:
----------------------------------------
[~dsmiley] raised this "ongoing consistency" issue in a recent {{dev@}}
[thread|https://lists.apache.org/thread/43xy1drq8wswg6vpo9b11rkvdqtqomlv]
regarding the v2 API, and suggested a specific approach: move the actual API
logic from RequestHandler classes into their v2 counterparts, replacing the RH
code with some shim logic to reformat the SolrRequest and invoke the
appropriate API class.
This keeps the v1 and v2 endpoints in sync, and has the nice side effect of
slimming down the v1 RequestHandler classes.
I've tried this approach out in the PR
[here|https://github.com/apache/solr/pull/955] and like it reasonably well.
Curious what others think!
> 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: 10m
> 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: [email protected]
For additional commands, e-mail: [email protected]
