[
https://issues.apache.org/jira/browse/DRILL-5723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16151145#comment-16151145
]
ASF GitHub Bot commented on DRILL-5723:
---------------------------------------
Github user paul-rogers commented on a diff in the pull request:
https://github.com/apache/drill/pull/923#discussion_r136661867
--- Diff:
exec/java-exec/src/test/java/org/apache/drill/exec/server/rest/StatusResourcesTest.java
---
@@ -0,0 +1,80 @@
+/*
+ * 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.drill.exec.server.rest;
+
+import org.apache.drill.exec.ExecConstants;
+import org.apache.drill.exec.server.options.OptionValidator;
+import org.apache.drill.exec.server.options.TypeValidators;
+import org.apache.drill.test.ClientFixture;
+import org.apache.drill.test.ClusterFixture;
+import org.apache.drill.test.FixtureBuilder;
+import org.apache.drill.test.RestClientFixture;
+import org.junit.Assert;
+import org.junit.Test;
+
+import static org.apache.drill.test.TestConfigLinkage.MOCK_PROPERTY;
+import static
org.apache.drill.test.TestConfigLinkage.createMockPropValidator;
+
+public class StatusResourcesTest {
+ @Test
+ public void testRetrieveInternalOption() throws Exception {
+ TypeValidators.StringValidator stringValidator =
createMockPropValidator();
+
+ FixtureBuilder builder = ClusterFixture.builder().
+ configProperty(ExecConstants.HTTP_ENABLE, true).
+ configProperty(OptionValidator.OPTION_DEFAULTS_ROOT + MOCK_PROPERTY,
"a").
+ putValidator(MOCK_PROPERTY, stringValidator);
+
+ try (ClusterFixture cluster = builder.build();
+ ClientFixture client = cluster.clientFixture()) {
+ RestClientFixture restClientFixture = cluster.restClientFixture();
+
+ Assert.assertNull(restClientFixture.getStatusOption(MOCK_PROPERTY));
+ StatusResources.OptionWrapper option =
restClientFixture.getStatusInternalOption(MOCK_PROPERTY);
+ Assert.assertEquals("a", option.getValueAsString());
+
+ client.alterSystem(MOCK_PROPERTY, "c");
--- End diff --
This test shows the value in allowing "extended" options defined outside of
the usual big table in `SystemOptionManager`.
In fact, we can take a step back and say that having a global table is
always a bad idea: it introduces tight coupling. Tight coupling makes it much
harder to do unit testing. For an open source tool such as Drill, which should
allow extensions, tight coupling is counter-productive to the goal of
extensibility.
So, I wonder, can we add a mechanism that allows other modules (and tests)
to add options? Just brainstorming a bit...
* For code modules, provide a config setting that names a class that builds
options. The Drillbit, during initialization, scans for these classes (the way
it scans for, say, storage plugins), instantiates the class, and calls a method
to define the options.
* The easiest way to define options is to add an `OptionBuilder` class,
created by the Drillbit in the constructor, that is available up to some point
in time, such as once the Drillbit starts running.
The API might be:
```
Drillbit bit = new Drillbit();
bit.optionBuilder().add(new OptionDefinition("my.option", ...));
bit.run();
```
The `add()` method can be called from tests (perhaps with added
`ClusterFixture` support) and from the module-specific option builder.
Two issues in this model:
* Is there any reason to add options after the Drillbit starts? Doing so
adds complexity.
* Do we have code in Drillbit startup that uses the option manager? If so,
some careful sequencing would be needed to call this code only *after* the
options are built.
> Support System/Session Internal Options
> ---------------------------------------
>
> Key: DRILL-5723
> URL: https://issues.apache.org/jira/browse/DRILL-5723
> Project: Apache Drill
> Issue Type: New Feature
> Reporter: Timothy Farkas
> Assignee: Timothy Farkas
>
> This is a feature proposed by [~ben-zvi].
> Currently all the options are accessible by the user in sys.options. We would
> like to add internal options which can be altered, but are not visible in the
> sys.options table. These internal options could be seen by another alias
> select * from internal.options. The intention would be to put new options we
> weren't comfortable with exposing to the end user in this table.
> After the options and their corresponding features are considered stable they
> could be changed to appear in the sys.option table.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
