You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Piotr Bojko (JIRA)" <ji...@apache.org> on 2018/03/10 00:37:00 UTC

[jira] [Issue Comment Deleted] (CALCITE-2194) Ability to hide a schema

     [ https://issues.apache.org/jira/browse/CALCITE-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Piotr Bojko updated CALCITE-2194:
---------------------------------
    Comment: was deleted

(was: Hmm, removing INDIRECT_SELECT from an enum complicates 2 things. First one you have mentioned and this is a syntactic sugar which doesn't scare me. What scares me is the second part - what input the AuthorisationGuard should have to be fully aware of the situation of indirect access to schema or any other? 

I've removed mentioned INDIRECT_SELECT but expand input for AuthorizationGuard. During that expansion I've discovered that context in CalcitePrepareImpl.expandView is being taken directly from connection (with objectPath property NOT properly configured) whereas in TableMacroView one custom is prepared (with objectPath property configured ok). In this approach - my needed feature is not directly achievable, but achievable  - see chinnook.json in Calcite.Plus as an example.

Also I've removed indirect flag.
||Issue||Status||
|Reformattng, house style|todo|
|Periods|todo|
|Checkstyle on RexImpTable|done|
|SqlAccessEnum.INDIRECT_SELECT|done - removed|
|Immutability on RelOptTalbleImpl|It is still immutable, changes only in MySchemaPlus which is not immutable, changes are unsupported like for example RelOptTalbleImpl.MySchemaPlus.add methods|
|CalcitePrincipalFairy name and threadlocal implementation|todo|
|System.getProperty("user.name")|Number of usage not increased, used only for backward compatibility|
|boolean indirect not explained|done - flag removed|
|messy .gitignore|done|)

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