[
https://issues.apache.org/jira/browse/DRILL-5723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16157879#comment-16157879
]
ASF GitHub Bot commented on DRILL-5723:
---------------------------------------
Github user ilooner commented on the issue:
https://github.com/apache/drill/pull/923
So it looks like Drill's treatment of OptionType and OptionScope is
inconsistent at present. To correct this I am doing the following:
- OptionType seems to be I'll defined. I think the intention is that it
defines the levels in which an option can be configured. This should be a
static property tied to an option (much like a validator). In reality it looks
like the OptionType of an option can be changed depending on where it is set,
which is incorrect behavior. I think this came about because it is the user's
responsibility to define the OptionType for an option value which is in correct.
- OptionScope will define the level at which the option was set
To solidify the semantics I am doing the following:
- OptionManagers no longer allow an option value to be set. Only the
following methods are exposed: ```
void setLocalOption(String name, boolean value);
void setLocalOption(String name, long value);
void setLocalOption(String name, double value);
void setLocalOption(String name, String value);
void setLocalOption(OptionValue.Kind kind, String name, String value);
``` Doing this prevents the possibility of defining an incorrect scope or
type. The option type is now determined by the static option definition. The
option scope is determined by the option manager on which the option was set.
- I have also cleaned up the OptionManager interface so that it does not
require the option type to be passed to the delete methods. This helps clean up
the semantics further because OptionType was being overloaded to define both
where an option can be set and which option manager can set it. This is unclear
because some options can be set exclusively at one level (e.g. only the session
level) whereas other options can be set at multiple levels (e.g. system and
session levels). It also introduces the possibility for error by allowing the
user to provide the wrong type to the wrong option manager.
> Support System/Session Internal Options And Additional Option System Fixes
> --------------------------------------------------------------------------
>
> 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.
> A bunch of other fixes to the Option system have been clubbed into this:
> * OptionValidators no longer hold default values. Default values are
> contained in the SystemOptionManager
> * Options have an OptionDefinition. The option definition includes:
> * A validator
> * Metadata about the options visibility, required permissions, and the
> scope in which it can be set.
> * The Option Manager interface has been cleaned up so that a Type is not
> required to be passed in in order to set and delete options
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
