You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Jason Gerlowski (Jira)" <ji...@apache.org> on 2021/02/23 15:38:00 UTC

[jira] [Created] (SOLR-15187) Make SolrRequest objects v2-POJO based (for /v2/collections)

Jason Gerlowski created SOLR-15187:
--------------------------------------

             Summary: 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


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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org