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

David Eric Pugh commented on SOLR-15141:
----------------------------------------

Does SolrJ need to support both?   I use SolrJ so I don't have to think about 
API's...   I just use the Java objects....

 

Could we slowly remove V1 and add V2 only support to SolrJ over time?  Or does 
that change bubble up throughout the SolrJ client?

> Investigate V2RequestSupport's role in SolrJ's V2 API support
> -------------------------------------------------------------
>
>                 Key: SOLR-15141
>                 URL: https://issues.apache.org/jira/browse/SOLR-15141
>             Project: Solr
>          Issue Type: Task
>          Components: SolrJ, v2 API
>    Affects Versions: 8.8, main (9.0)
>            Reporter: Jason Gerlowski
>            Priority: Minor
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> The V2RequestSupport interface was the original plan for building support for 
> the v2 API into SolrJ's existing request objects.  It relies on 
> {{CollectionApiMapping.Meta}} to convert v1 request objects into instances of 
> the generic V2Request class.
> This worked well as the V2 APIs were originally conceived, but has developed 
> a few issues over time.
> # V2RequestSupport's reliance on the {{Meta}} mapping class means that it 
> only works with jsonspec-based v2 APIs and not the annotated-POJOs that the 
> community intends to use going forward for defining V2 APIs.
> # It requires users to create request objects that rely on v1 APIs and 
> concepts. e.g. there is no "Collection Admin" path in v2 APIs. 
> # Usage of the interface never took off.  It's only currently used by 
> CollectionAdminRequest.  So it's somewhat abandoned already.
> We should deprecate V2RequestSupport in 8.x and plan to remove it in 9.0.  In 
> parallel (and in different JIRAs), we can work on adding v2 support to SolrJ 
> one SolrRequest class at a time. (Classes that expose v2-compatible 
> abstractions can be switched over to v2 implementations under-the-hood.  
> Classes that don't (e.g. CollectionAdminRequest) can be deprecated and 
> replaced by a more v2-friendly SolrRequest implementation.)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

Reply via email to