gerlowskija commented on code in PR #1412: URL: https://github.com/apache/solr/pull/1412#discussion_r1131186601
########## solr/core/src/java/org/apache/solr/jersey/SubResponseAccumulatingJerseyResponse.java: ########## @@ -0,0 +1,55 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.solr.jersey; + +import com.fasterxml.jackson.annotation.JsonProperty; + +/** + * Represents API responses composed of the responses of various sub-requests. + * + * <p>Many Solr APIs, particularly those historically reliant on overseer processing, return a + * response to the user that is composed in large part of the responses from all sub-requests made + * during the APIs execution. (e.g. the collection-deletion response itself contains the responses + * from the 'UNLOAD' call send to each core.) This class encapsulates those responses as possible. + */ +public class SubResponseAccumulatingJerseyResponse extends SolrJerseyResponse { + + @JsonProperty("requestid") + public String requestId; Review Comment: I _think_ that Solr spits out 'requestid' here because that's the name of the parameter that [v1 REQUESTSTATUS](https://solr.apache.org/guide/6_6/collections-api.html#CollectionsAPI-requeststatus) has taken, historically. Definitely something worth cleaning up at some point. (Personally my preference would be for something more explicit, like `asynchronous-request-id`, but admittedly that's probably too verbose for most people's tastes.) I'd be onboard with any option that helped requestid be less overloaded. That said - definitely beyond the scope of this ticket to make any field naming changes, unfortunately. Changing the response format would impact v1 APIs as well, have backcompat implications, etc. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
