[
https://issues.apache.org/jira/browse/SOLR-15187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17289152#comment-17289152
]
Jason Gerlowski commented on SOLR-15187:
----------------------------------------
The linked PR gets us most of the way there for these APIs. And the cut in
duplication make this almost neutral in terms of LOC, which is cool.
Still missing is handling of the async and collection-name params for some APIs
- I skipped these in my initial pass because SolrJ has these params in a parent
class for several SolrRequest's, so I wanted to think a bit about how to mirror
that.
> Make SolrRequest objects v2-POJO based (for /v2/collections)
> ------------------------------------------------------------
>
> Key: SOLR-15187
> URL: https://issues.apache.org/jira/browse/SOLR-15187
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: v2 API
> Affects Versions: master (9.0)
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Solr supports two ways for developers to setup V2 APIs. APIs are either
> defined in a JSON 'apispec' file, or are defined as SolrJ POJOs. The
> community has decided previously that the POJO approach is the one to use
> going forward, as it cuts down on duplication and makes parameter editing
> simpler. An example of the POJO-based approach can be seen in SOLR-15118.
> We could take this approach a step further by implementing our SolrJ's
> request objects in terms of the canonical POJOs used for
> serialization/deserialization. This gets us a few benefits:
> * Further removes API definition duplication. The instance variables in
> (e.g.)
> [CollectionAdminRequest.Create|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/client/solrj/request/CollectionAdminRequest.java#L411]
> are near duplicates of those in
> [CreatePayload|https://github.com/apache/lucene-solr/blob/e89fba6fe7739cb213560b94b6a4a76e40c2e4a5/solr/solrj/src/java/org/apache/solr/client/solrj/request/beans/CreatePayload.java#L26].
> * Gives us a way to continue randomizing v1 vs v2 in SolrJ, which has
> previously only been (easily) possible using apispec-defined APIs. (See
> SOLR-15141 for more details on v1-v2 randomization.)
> * Provides a forcing function to make sure v2 APIs stay up to date - if
> SolrRequest objects are based on the v2 serde beans, then adding support in
> SolrJ would require an update of the relevant serde bean.
> Doing this across SolrJ exceeds a single JIRA ticket, as many v2 APIs are
> currently out of date and few use the new-ish POJO-based approach. This
> ticket only aims to do this for the SolrRequest classes whose /v2/collections
> APIs were recently converted to the POJO approach in SOLR-15118:
> * Backup
> * Restore
> * CreateAlias
> * CreateTimeRoutedAlias
> * CreateCategoryRoutedAlias
> * SetAliasProperty
> * DeleteAlias
> * Create
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
