[jira] [Commented] (SOLR-15141) Deprecate/Remove V2RequestSupport

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

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

Jason Gerlowski commented on SOLR-15141:
----------------------------------------

I've pushed up a PR for master to remove V2RequestSupport, and one for branch_8x to deprecate it.

I don't plan to do anything with these though until there's a bit of consensus on how we _do_ want to support the V2 API in SolrJ.

My suggestion would be to handle v2 SolrJ differently for each API, depending on whether the SolrRequest classes in question rely on or expose v1 concepts. Examples below:
 * CollectionAdminRequest.CREATE doesn't really make sense in a v2 world (since there is no single "Collection Admin" v2 path, the name will make less and less sense as v2 APIs become prevalent). So CollectionAdminRequest.CREATE will need deprecated, and a new SolrRequest class will need created to support v2. So there's no need for a V2RequestSupport-like interface to switch between v1 and v2 within the same class.
 * Classes like SchemaRequest.AddField on the other hand (whose interfaces don't expose any v1-specific details) can handle v1 and v2 in the same class if desired. We have a few options for how to handle this. If we trust our v2 API tests enough, we could drop v1 and add v2 support at the same time (with no overlap). If overlap in v1 and v2 support is desired, we could use an interface _like_ the current {{V2RequestSupport}} to allow users to specify v1 vs v2. But unlike V2RequestSupport this will need to be done in a way that supports annotated-POJO-based v2 APIs. IMO it should also be done in a way that defaults to v2, to start increasing our confidence in the v2 code _by default_.

But that's just my 2-cents.  I'm sure others have thought about this more.

> Deprecate/Remove V2RequestSupport
> ---------------------------------
>
>                 Key: SOLR-15141
>                 URL: https://issues.apache.org/jira/browse/SOLR-15141
>             Project: Solr
>          Issue Type: Task
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: v2 API
>    Affects Versions: 8.8, master (9.0)
>            Reporter: Jason Gerlowski
>            Priority: Minor
>          Time Spent: 10m
>  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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org