You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@druid.apache.org by GitBox <gi...@apache.org> on 2021/07/09 22:00:23 UTC

[GitHub] [druid] capistrant opened a new pull request #11429: Implement configurable internally generated query context

capistrant opened a new pull request #11429:
URL: https://github.com/apache/druid/pull/11429


   <!-- Thanks for trying to help us make Apache Druid be the best it can be! Please fill out as much of the following information as is possible (where relevant, and remove it when irrelevant) to help make the intention and scope of this PR clear in order to ease review. -->
   
   <!-- Please read the doc for contribution (https://github.com/apache/druid/blob/master/CONTRIBUTING.md) before making this PR. Also, once you open a PR, please _avoid using force pushes and rebasing_ since these make it difficult for reviewers to see what you've changed in response to their reviews. See [the 'If your pull request shows conflicts with master' section](https://github.com/apache/druid/blob/master/CONTRIBUTING.md#if-your-pull-request-shows-conflicts-with-master) for more details. -->
   
   <!-- Replace XXXX with the id of the issue fixed in this PR. Remove this section if there is no corresponding issue. Don't reference the issue in the title of this pull-request. -->
   
   <!-- If you are a committer, follow the PR action item checklist for committers:
   https://github.com/apache/druid/blob/master/dev/committer-instructions.md#pr-and-issue-action-item-checklist-for-committers. -->
   
   ### Description
   
   <!-- Describe the goal of this PR, what problem are you fixing. If there is a corresponding issue (referenced above), it's not necessary to repeat the description here, however, you may choose to keep one summary sentence. -->
   
   <!-- Describe your patch: what did you change in code? How did you fix the problem? -->
   
   <!-- If there are several relatively logically separate changes in this PR, create a mini-section for each of them. For example: -->
   
   Gives operator the ability to add a query context to internally generated SegmentMetadata Queries. The broker runs these queries with a blank context today. This PR allows a context map to be defined in runtime.properties using the config `druid.broker.internal.query.config.context`. For instance, you could set a query priority by giving that config this value: `{ "context": {"priority": 5}}`
   
   <!--
   In each section, please describe design decisions made, including:
    - Choice of algorithms
    - Behavioral aspects. What configuration values are acceptable? How are corner cases and error conditions handled, such as when there are insufficient resources?
    - Class organization and design (how the logic is split between classes, inheritance, composition, design patterns)
    - Method organization and design (how the logic is split between methods, parameters and return types)
    - Naming (class, method, API, configuration, HTTP endpoint, names of emitted metrics)
   -->
   
   
   <!-- It's good to describe an alternative design (or mention an alternative name) for every design (or naming) decision point and compare the alternatives with the designs that you've implemented (or the names you've chosen) to highlight the advantages of the chosen designs and names. -->
   
   This way requires coder to know that they need to procure and pass in this context config to internally generated queries. I thought it would be cool if there was some way to rig everything up to have internal queries not require the coder to remember/know this, but couldn't think of a way. Definitely open to ideas in that space.
   
   <!-- If there was a discussion of the design of the feature implemented in this PR elsewhere (e. g. a "Proposal" issue, any other issue, or a thread in the development mailing list), link to that discussion from this PR description and explain what have changed in your final design compared to your original proposal or the consensus version in the end of the discussion. If something hasn't changed since the original discussion, you can omit a detailed discussion of those aspects of the design here, perhaps apart from brief mentioning for the sake of readability of this PR description. -->
   
   <!-- Some of the aspects mentioned above may be omitted for simple and small changes. -->
   
   <hr>
   
   ##### Key changed/added classes in this PR
    * `BrokerInternalQueryConfig`
    * `CliBroker`
    * `DruidSchema`
   
   <hr>
   
   <!-- Check the items by putting "x" in the brackets for the done things. Not all of these items apply to every PR. Remove the items which are not done or not relevant to the PR. None of the items from the checklist below are strictly necessary, but it would be very helpful if you at least self-review the PR. -->
   
   This PR has:
   - [X] been self-reviewed.
   - [X] added documentation for new or modified features or behaviors.
   - [X] added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
   - [ ] added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
   - [ ] added unit tests or modified existing tests to cover new code paths, ensuring the threshold for [code coverage](https://github.com/apache/druid/blob/master/dev/code-review/code-coverage.md) is met.
   - [ ] added integration tests.
   - [X] been tested in a test Druid cluster.
   


-- 
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: commits-unsubscribe@druid.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org

[GitHub] [druid] suneet-s commented on a change in pull request #11429: Implement configurable internally generated query context

Posted by GitBox <gi...@apache.org>.
suneet-s commented on a change in pull request #11429:
URL: https://github.com/apache/druid/pull/11429#discussion_r712679761



##########
File path: docs/configuration/index.md
##########
@@ -1737,6 +1737,16 @@ line.
 
 See [general query configuration](#general-query-configuration).
 
+###### Broker Generated Query Configuration Supplementation
+
+The Broker generates queries internally. This configuration section describes how an operator can augment the configuration
+of these queries.

Review comment:
       nit: I think an example here of why someone would want to set this functionality will be helpful to Druid operators.

##########
File path: server/src/main/java/org/apache/druid/client/BrokerInternalQueryConfig.java
##########
@@ -0,0 +1,40 @@
+/*
+ * 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.druid.client;
+
+import com.fasterxml.jackson.annotation.JsonProperty;
+
+import java.util.Map;
+
+/**
+ * This class contains configuration that internally generated Druid queries
+ * should add to their query payload. The runtime properties for this class
+ * have the prefix "druid.broker.internal.query.config."
+ */
+public class BrokerInternalQueryConfig
+{
+  @JsonProperty
+  private Map<String, Object> context;

Review comment:
       Does this need an `@Nullable` annotation since the default here is null? Would it be possible to use the JsonCreator constructor and set this to an empty map so we don't have to deal with null elsewhere?

##########
File path: server/src/test/java/org/apache/druid/client/BrokerInternalQueryConfigTest.java
##########
@@ -0,0 +1,64 @@
+/*
+ * 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.druid.client;
+
+import com.fasterxml.jackson.databind.ObjectMapper;
+import org.apache.druid.segment.TestHelper;
+import org.junit.Assert;
+import org.junit.Test;
+
+import java.util.HashMap;
+import java.util.Map;
+
+public class BrokerInternalQueryConfigTest
+{
+  private static final ObjectMapper MAPPER = TestHelper.makeJsonMapper();
+
+  @Test
+  public void testSerde() throws Exception

Review comment:
       Can you add a test for an improperly configured map.
   
   If a user configures the context incorrectly, for example `{` Is the expected behavior that the broker will fail to start?




-- 
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: commits-unsubscribe@druid.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org

[GitHub] [druid] capistrant commented on a change in pull request #11429: Implement configurable internally generated query context

Posted by GitBox <gi...@apache.org>.
capistrant commented on a change in pull request #11429:
URL: https://github.com/apache/druid/pull/11429#discussion_r721412069



##########
File path: server/src/test/java/org/apache/druid/client/BrokerInternalQueryConfigTest.java
##########
@@ -0,0 +1,64 @@
+/*
+ * 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.druid.client;
+
+import com.fasterxml.jackson.databind.ObjectMapper;
+import org.apache.druid.segment.TestHelper;
+import org.junit.Assert;
+import org.junit.Test;
+
+import java.util.HashMap;
+import java.util.Map;
+
+public class BrokerInternalQueryConfigTest
+{
+  private static final ObjectMapper MAPPER = TestHelper.makeJsonMapper();
+
+  @Test
+  public void testSerde() throws Exception

Review comment:
       I agree that failure to startup is a fine choice for this. I added a test for the malformed config as well as an additional test for default behavior using a Guice injector. 




-- 
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: commits-unsubscribe@druid.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org

[GitHub] [druid] suneet-s commented on pull request #11429: Implement configurable internally generated query context

Posted by GitBox <gi...@apache.org>.
suneet-s commented on pull request #11429:
URL: https://github.com/apache/druid/pull/11429#issuecomment-916608046


   @capistrant This seems cool! For my own curiosity (and maybe as a practical example for the docs), Could you explain why it would be beneficial to have the segmentMetadata queries at a higher priority than the other queries running on the cluster.


-- 
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: commits-unsubscribe@druid.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org

[GitHub] [druid] capistrant commented on pull request #11429: Implement configurable internally generated query context

Posted by GitBox <gi...@apache.org>.
capistrant commented on pull request #11429:
URL: https://github.com/apache/druid/pull/11429#issuecomment-934718216


   > > > seems reasonable to me.
   > > > What sort of integration test do you think would be needed to validate this change?
   > > 
   > > 
   > > Ya, I have continued to think about an integration test here but I am not sure there is anything straightforward. In a live cluster, the only way to test that the context override is honored would be by analyzing query metric output or query log output (at least that I can think of). So I plan to instead look at DruidSchema for opportunities to test that the config is honored
   > 
   > Sounds good to me. I think if there is a unit test that validates the context in BrokerInternalQueryConfigTest is used by the DruidSchema#runSegmentMetadataQuery method - that should be sufficient testing to get this change merged.
   
   I ended up refactoring a bit. After looking at the code, I didn't really get why DruidSchema#runSegmentMetadataQuery was a static method. I could certainly undo that and think I could still test successfully. I added a test that confirms the query is submitted with proper context override. The test is a little big ugly since I couldn't leverage the existing schema object used in junit setup. I needed a DruidSchema object with the lifecycle factory and the underlying lifecycle as mock objects and the existing schema did not provide.


-- 
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: commits-unsubscribe@druid.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org

[GitHub] [druid] capistrant commented on pull request #11429: Implement configurable internally generated query context

Posted by GitBox <gi...@apache.org>.
capistrant commented on pull request #11429:
URL: https://github.com/apache/druid/pull/11429#issuecomment-931669321


   > @capistrant This seems cool! For my own curiosity (and maybe as a practical example for the docs), Could you explain why it would be beneficial to have the segmentMetadata queries at a higher priority than the other queries running on the cluster.
   
   What it comes down to is an operators opinion though. Perhaps, operators  would not want to give these queries a higher priority, and I think that is just fine. The flexibility to choose is really the goal here.
   
   My personal opinion is that these broker generated metadata queries are of utmost importance and should never be waiting in line behind other queries within a historical node. I think this because I always want my brokers to have the freshest metadata possible, and therefore I want the queries to achieve that freshness to run with a high priority relative to other queries being submitted. For instance, in one of the production clusters I help run, our services layer that submits queries for users assigns them priorities of 0, 10, 20, or 30. In this case, keeping a default of 0 for the broker generated metadata queries would put them on par with our known "slow queries" (relatively speaking) when it comes to prioritization on historicals. Whereas we think they should be 30, in step with the most important queries on the cluster.


-- 
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: commits-unsubscribe@druid.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org

[GitHub] [druid] capistrant commented on pull request #11429: Implement configurable internally generated query context

Posted by GitBox <gi...@apache.org>.
capistrant commented on pull request #11429:
URL: https://github.com/apache/druid/pull/11429#issuecomment-933553102


   > seems reasonable to me.
   > 
   > What sort of integration test do you think would be needed to validate this change?
   
   Ya, I have continued to think about an integration test here but I am not sure there is anything straightforward. In a live cluster, the only way to test that the context override is honored would be by analyzing query metric output or query log output (at least that I can think of). So I plan to instead look at DruidSchema for opportunities to test that the config is honored 


-- 
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: commits-unsubscribe@druid.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org

[GitHub] [druid] suneet-s commented on pull request #11429: Implement configurable internally generated query context

Posted by GitBox <gi...@apache.org>.
suneet-s commented on pull request #11429:
URL: https://github.com/apache/druid/pull/11429#issuecomment-933788660


   > > seems reasonable to me.
   > > What sort of integration test do you think would be needed to validate this change?
   > 
   > Ya, I have continued to think about an integration test here but I am not sure there is anything straightforward. In a live cluster, the only way to test that the context override is honored would be by analyzing query metric output or query log output (at least that I can think of). So I plan to instead look at DruidSchema for opportunities to test that the config is honored
   
   Sounds good to me. I think if there is a unit test that validates the context in BrokerInternalQueryConfigTest is used by the DruidSchema#runSegmentMetadataQuery method - that should be sufficient testing to get this change merged.


-- 
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: commits-unsubscribe@druid.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org

[GitHub] [druid] suneet-s commented on pull request #11429: Implement configurable internally generated query context

Posted by GitBox <gi...@apache.org>.
suneet-s commented on pull request #11429:
URL: https://github.com/apache/druid/pull/11429#issuecomment-936566920


   Yay! re-triggering the tests worked! Thanks @capistrant 


-- 
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: commits-unsubscribe@druid.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org

[GitHub] [druid] suneet-s merged pull request #11429: Implement configurable internally generated query context

Posted by GitBox <gi...@apache.org>.
suneet-s merged pull request #11429:
URL: https://github.com/apache/druid/pull/11429


   


-- 
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: commits-unsubscribe@druid.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org

[GitHub] [druid] capistrant commented on a change in pull request #11429: Implement configurable internally generated query context

Posted by GitBox <gi...@apache.org>.
capistrant commented on a change in pull request #11429:
URL: https://github.com/apache/druid/pull/11429#discussion_r719802728



##########
File path: server/src/test/java/org/apache/druid/client/BrokerInternalQueryConfigTest.java
##########
@@ -0,0 +1,64 @@
+/*
+ * 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.druid.client;
+
+import com.fasterxml.jackson.databind.ObjectMapper;
+import org.apache.druid.segment.TestHelper;
+import org.junit.Assert;
+import org.junit.Test;
+
+import java.util.HashMap;
+import java.util.Map;
+
+public class BrokerInternalQueryConfigTest
+{
+  private static final ObjectMapper MAPPER = TestHelper.makeJsonMapper();
+
+  @Test
+  public void testSerde() throws Exception

Review comment:
       Expected behavior is good question. I guess I'd personally be okay with either. It may be less confusing to an operator if the service just didn't start. Otherwise we could have some explicit WARN logging and startup with a null context. Which do you think would be best?




-- 
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: commits-unsubscribe@druid.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org

[GitHub] [druid] suneet-s commented on a change in pull request #11429: Implement configurable internally generated query context

Posted by GitBox <gi...@apache.org>.
suneet-s commented on a change in pull request #11429:
URL: https://github.com/apache/druid/pull/11429#discussion_r719835368



##########
File path: server/src/test/java/org/apache/druid/client/BrokerInternalQueryConfigTest.java
##########
@@ -0,0 +1,64 @@
+/*
+ * 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.druid.client;
+
+import com.fasterxml.jackson.databind.ObjectMapper;
+import org.apache.druid.segment.TestHelper;
+import org.junit.Assert;
+import org.junit.Test;
+
+import java.util.HashMap;
+import java.util.Map;
+
+public class BrokerInternalQueryConfigTest
+{
+  private static final ObjectMapper MAPPER = TestHelper.makeJsonMapper();
+
+  @Test
+  public void testSerde() throws Exception

Review comment:
       I think making the service fail to start would be preferred.
   
   In this case a warn log would likely be ignored since you wouldn't really have a need to check the logs until someone notices something strange with the priority of the generated metadata queries - which I think would be very hard to debug.




-- 
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: commits-unsubscribe@druid.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org

[GitHub] [druid] capistrant edited a comment on pull request #11429: Implement configurable internally generated query context

Posted by GitBox <gi...@apache.org>.
capistrant edited a comment on pull request #11429:
URL: https://github.com/apache/druid/pull/11429#issuecomment-934718216


   > > > seems reasonable to me.
   > > > What sort of integration test do you think would be needed to validate this change?
   > > 
   > > 
   > > Ya, I have continued to think about an integration test here but I am not sure there is anything straightforward. In a live cluster, the only way to test that the context override is honored would be by analyzing query metric output or query log output (at least that I can think of). So I plan to instead look at DruidSchema for opportunities to test that the config is honored
   > 
   > Sounds good to me. I think if there is a unit test that validates the context in BrokerInternalQueryConfigTest is used by the DruidSchema#runSegmentMetadataQuery method - that should be sufficient testing to get this change merged.
   
   I ended up refactoring a bit. After looking at the code, I didn't really get why DruidSchema#runSegmentMetadataQuery was a static method so I changed it to an instance method and ended up exposing that for test. I could certainly undo that and think I could still test successfully. I added a test that confirms the query is submitted with proper context override. The test is a little big ugly since I couldn't leverage the existing schema object used in junit setup. I needed a DruidSchema object with the lifecycle factory and the underlying lifecycle as mock objects and the existing schema did not provide.


-- 
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: commits-unsubscribe@druid.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org