[
https://issues.apache.org/jira/browse/SOLR-15141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435940#comment-17435940
]
Jason Gerlowski commented on SOLR-15141:
----------------------------------------
It's a good question. My tentative thought is that while I hate it and wish it
wasn't so, we probably do need to support both simultaneously. (Please,
please, please convince me otherwise!)
You're right that external SolrJ users shouldn't care what API version is used
under the hood - it's all just "Java objects". But SolrJ has internal clients
too: the most important one being our tests, which use SolrJ almost exclusively
for API calls. We can switch (e.g.) {{CollectionAdminRequest.CREATE}} over to
using v2 without affecting a single external user, but doing so would
effectively remove all coverage of Solr's v1
{{/solr/admin/collections?action=CREATE}} API from the test suite! That's the
real benefit of simultaneous v1+v2 support in SolrJ IMO: it ensures that our
tests cover both v1 and v2 while we as a project straddle both API versions.
So that's my gut feeling - I'd love to be convinced out of it or overruled
though. Maybe losing v1 test coverage is fine as long as it's accompanied by
the deprecation of that v1 API? Maybe it's fine as long as we're highlighting
the v2 API in the ref-guide? Maybe coverage of both v1 and v2 is unrealistic or
prohibitive and we shouldn't attempt it? idk.
> 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
