drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DRILL-5723) Support System/Session Internal Options And Additional Option System Fixes
Date Thu, 07 Sep 2017 23:56:00 GMT

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

    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
> * 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

View raw message