[
https://issues.apache.org/jira/browse/CALCITE-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16392092#comment-16392092
]
Piotr Bojko edited comment on CALCITE-2194 at 3/8/18 11:33 PM:
---------------------------------------------------------------
Thx for quick feedback.
* reformatting is my bad, will try to fix
* periods - to be fixed
* RexImpTable - it was a hocus pocus to me, but suddenly the files just blows
with errors. Totally forgot to look at it after the poc was done. My bad - will
inwestigate this further
* Full access instead hidden feature - you're the boss, win win :)
* as for Fairy - I'm not stick to names I can rename it. ThreadLocal like
implementation was the quickest solution to drag the principal for almost all
of the calcite stack - spring implements such features in the same threadlocal
way. Any suggestion how can propagate the principal and I would try to ship it.
* System.getProperty - previous implementation of
USER/CURRENT_USER/SESSION_USER had used "user.name" property. I've added the
fallback to previous behaviour in case an end user has not provided the user on
the connection.
* boolean indirect and INDIRECT_SELECT was provided to implement my needed
case. You map the user to INDIRECT_SELECT in schema now and this user can use
such schema only through views from another schema. You can map user to SELECT
in schema (but not INDIRECT_SELECT) and such user can use schema only through
direct selects and not through views from other schemas.
* .gitgnore - will fix
What do you think in general about the change? Do you consider to accept the
change to calcite after patching you doubts? For me only the
"SqlAccessEnum.INDIRECT_SELECT" change is something more than an implementation
and it is your call whether to accept another access type or to look to
redesign my change.
If in general the change has a good direction I would how to design my project
in which calcite plays a role. Thx in advance :)
was (Author: ptrbojko):
Thx for quick feedback.
* reformatting is my bad, will try to fix
* periods - to be fixed
* RexImpTable - it was a hocus pocus to me, but suddenly the files just blows
with errors. Totally forgot to look at it after the poc was done. My bad - will
inwestigate this further
* Full access instead hidden feature - you're the boss, win win :)
* as for Fairy - I'm not stick to names I can rename it. ThreadLocal like
implementation was the quickest solution to drag the principal for almost all
of the calcite stack - spring implements such features in the same threadlocal
way. Any suggestion how can propagate the principal and I would try to ship it.
* System.getProperty - previous implementation of
USER/CURRENT_USER/SESSION_USER had used "user.name" property. I've added the
fallback to previous behaviour in case an end user has not provided the user on
the connection.
* boolean indirect and INDIRECT_SELECT was provided to implement my needed
case. You map the user to INDIRECT_SELECT in schema now and this user can use
such schema only through views from another schema. You can map user to SELECT
in schema (but not INDIRECT_SELECT) and such user can use schema only through
direct selects and not through views from other schemas.
* .gitgnore - will fix
What do you think in general about the change? Do you consider to accept the
change to calcite after patching you doubts? For me only the
"SqlAccessEnum.INDIRECT_SELECT" change is something more than an implementation
and it is your call whether to accept another access type or to look to
redesign my change.
> Ability to hide a schema
> ------------------------
>
> Key: CALCITE-2194
> URL: https://issues.apache.org/jira/browse/CALCITE-2194
> Project: Calcite
> Issue Type: New Feature
> Components: core
> Affects Versions: 1.16.0
> Reporter: Piotr Bojko
> Assignee: Piotr Bojko
> Priority: Minor
>
> See:
> [https://mail-archives.apache.org/mod_mbox/calcite-dev/201711.mbox/ajax/%3C6F6E52D4-6860-4384-A1CB-A2301D05394D%40apache.org%3E]
> I've looked into the core and the notion of an user could be hard to achieved
> now.
> Though, I am able to implement the "hidden schema" feature through following
> changes:
> # JsonSchema - add a holder for the feature, boolean flag or flags field
> with enum (CACHED which now exists as a separate flag - some deprecation
> could be needed, HIDDEN)
> # CalciteSchema - pass through of a flag
> # RelOptSchema - pass through of a flag
> # CalciteCatalogReader - pass through of a flag
> # Other derivatives of RelOptSchema - mocked value, false
> # RelOptTable and impl - pass through of a flag
> # SqlValidatorImpl - validation whether object from hidden schema is used
> (in the same places like validateAccess)
> # ViewTableMacro.apply -> Schemas.analyzeView ->
> CalcitePrepareImpl.analyzeView -> CalcitePrepareImpl.parse_ ->
> CalcitePrepareImpl.CalcitePrepareImpl - this path of execution should build
> SqlValidatorImpl which has the check from point 7 disabled-
> Such feature could be useful for end users.
> If the solution is ok - I can contribute it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
