[
https://issues.apache.org/jira/browse/CALCITE-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16384686#comment-16384686
]
Piotr Bojko edited comment on CALCITE-2194 at 3/3/18 4:07 PM:
--------------------------------------------------------------
I have a working POC now in mentioned branch.
# Each schema can be decorated with access definition as in previous comment
# I haven't changed Table nor Schema interfaces itself - it would cause a
serious API change for Calcite end-users. The access information is placed on
CalciteSchema level - as far I know Calcite this is a decoration for schema for
adding external views, etc, so it could be decorated with access info also.
# Principal is build on information from Connection - so
DriverManager.getConnection("jdbc:calcite:", "sa", "sa") will mark the
Principal to be sa.
# Principal is handled in Fairy kind of service - because it guesses on behalf
which principal current flow of processing is being done. Internally
PrincipalFairy uses thread local.
Current stopper is MaterializedViewTable.MATERIALIZATION_CONNECTION which
prevents to pass through the principal information to processing the views. I
wonder whether existing connection created by user can be used instead of this
static?
The second question is about SqlAccessEnum, can it be freely extended above
SELECT, UPDATE, INSERT, DELETE? I want to add INDIRECT_SELECT to mark schema
which is meant to be hidden.
was (Author: ptrbojko):
I have a working POC now in mentioned branch.
# Each schema can be decorated with access definition as in previous comment
# I haven't changed Table nor Schema interfaces itself - it would cause a
serious API change for Calcite end-users. The access information is placed on
CalciteSchema level - as far I know Calcite this is a decoration for schema for
adding external views, etc, so it could be decorated with access info also.
# Principal is build on information from Connection - so
DriverManager.getConnection("jdbc:calcite:", "sa", "sa") will mark the
Principal to be sa.
# Principal is handled in Fairy kind of service - because it guesses on behalf
which principal current flow of processing is being done. Internally
PrincipalFairy uses thread local.
Current stopper is MaterializedViewTable.MATERIALIZATION_CONNECTION which
prevents to pass through the principal information to processing the views. I
wonder whether existing connection created by user can be used instead of this
static?
> 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)
