[
https://issues.apache.org/jira/browse/DRILL-5723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16129234#comment-16129234
]
Timothy Farkas edited comment on DRILL-5723 at 8/16/17 10:47 PM:
-----------------------------------------------------------------
This is what I am thinking based on everyone's feedback:
* *Boot Internal Options:* Internal options which should not be modifiable at
runtime:
** These can already be configured by adding them to drill-override.conf as
Parth and Paul said. Options configured in this way would not be viewable from
the sys options table because they are not contained in the sys options table.
* *System/Session Internal Options:* Internal options which can be modifiable
at runtime:
** Currently not implemented and would be the primary focus of this feature.
These would be viewable and settable from the command line.
*System/Session internal options* would be stored in the SystemOptionManager
with the rest of the options. *System/Session internal options* would be
distinguished from *boot internal options* by a whitelist in
*drill-override.conf* where all internal options are prefixed in
*drill.internal.options*. *System/Session internal options* would be
distinguished from normal options by adding the concept of metadata to the
SystemOptionManager.
If the user tries to:
* *See the normal system options:* select * from sys.options
** The options are filtered by their metadata and only non internal options are
returned.
* *See the internal system options:* select * from internal.options
** internal.options is an alias for sys.options so this query also looks at the
data in the SystemOptionManager. But the use of this alias causes options to be
filtered by their meta data to only return internal options.
* *alter session set `<system/session internal option>` = 'value':*
** This should succeed.
Also this feature may be a good stepping stone to support permissions for
security parameters Parth mentioned. If we add the concept of meta data to the
system table as Paul has suggested, then maybe it could easily be extended to
hold permission / role information as well in the future.
was (Author: timothyfarkas):
This is what I am thinking based on everyone's feedback:
* *Unmodifiable Internal Options:* Internal options which should not be
modifiable at runtime:
** These can already be configured by adding them to drill-override.conf as
Parth said. Paul also suggested distinguishing between system constants and
unmodifiable internal options by adding a list of system constants to
drill-override-examples.conf
* *Modifiable Internal Options:* Internal options which should be modifiable at
runtime:
** Currently not implemented and would be the primary focus of this feature.
Internal options would be stored in the SystemOptionManager with the rest of
the options. Internal options would be distinguished from normal options by
adding the concept of metadata to the SystemOptionManager.
If the user tries to:
* *select * from sys.options:*
** The options are filtered by their metadata and only non internal options are
returned.
* *select * from internal.options:*
** internal.options is an alias for sys.options so this query also looks at the
data in the SystemOptionManager. But the use of this alias causes options to be
filtered by their meta data to only return internal options.
* *alter session set `<unmodifiable internal option>` = 'value':*
** This should fail
* *alter session set `<modifiable internal option>` = 'value':*
** This should succeed.
Also this feature may be a good stepping stone to support permissions for
security parameters Parth mentioned. If we add the concept of meta data to the
system table as Paul has suggested, then maybe it could easily be extended to
hold permission / role information as well in the future.
> Support Modifying 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 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)
