You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@drill.apache.org by "Paul Rogers (JIRA)" <ji...@apache.org> on 2017/08/15 23:52:00 UTC

[jira] [Commented] (DRILL-5723) Add An Internal Options Table

    [ https://issues.apache.org/jira/browse/DRILL-5723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128103#comment-16128103 ] 

Paul Rogers commented on DRILL-5723:
------------------------------------

As we discussed, there may be another option: to add metadata to the existing options.

Consider how we'd use the internals options. If the user can't change them, then they can go into our existing boot-time (config) options. We have many, many such options today. If some customer case requires a change to those options, the customer can make them in their {{drill-override.conf}} file as instructed by Support (who is, in turn, instructed by Development.)

So, if we want a "hidden" option that is set very occasionally, we can use a config option.

We'd want to use the equivalent of system/session options if the user might need to change the option per-query or per-user. For that, we have the session/system mechanism. If we wanted the hidden options to work the same, we'd have to add SQL syntax to change the options. And, if users start mucking with the options (under instruction of Support), we'd have to be able to see the option values (to, say, see if the user really did, in fact, make the change we requested.)

If we do all that, we reinvent the session/system option system. All so we can have options that the user is not supposed to change.

So, if we do have "emergency" options to be change per-query under instruction from Support, perhaps continue to store them in the current session/system option mechanism. What we actually want is to filter out the options from the normal option display (the query used to power the UI.)

On the other hand, if we want to filter out config options that are actually externalized Drill constants, we might need a different approach. We might want a white-list of options to display. That list could be generated from the {{drill-override-example.conf}} file: if we list the option in the example file, users can change it. If not, it is a private, internal option.

> Add An Internal Options Table
> -----------------------------
>
>                 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 a new internal.options table which holds hidden experimental 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 migrated to the the sys.options table.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)