[
https://issues.apache.org/jira/browse/CALCITE-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377586#comment-16377586
]
Piotr Bojko edited comment on CALCITE-2194 at 2/26/18 10:49 PM:
----------------------------------------------------------------
[~julianhyde] - could give some hint about builtin user logic? How to get it
around SqlValidator? This should do the last piece. If I can make it have
context of an logged in user in sqlvalidator - I would more generic approach,
something like this:
{code:java}
{
"version": "1.0",
"defaultSchema": "JIRA",
"schemas": [
{
"name": "HIDDEN_SCHEMA",
"type": "custom",
"factory": "some-factory",
"operand": {},
"access" : {
"factory" : "some-new-factory-for-user-based-access-logic",
"operarnds" : {"root","some-user"}
}
}, {
"name": "SOME_OTHER_SCHEMA",
"type": "custom",
"factory": "org.apache.calcite.schema.impl.AbstractSchema$Factory",
"operand": {},
"tables": [
{{code}
This will help to introduce for example role based access.
EDIT:
Prove me wrong but based on implementation of builtin SQL functions there is
rather a mock of user implementation
{code:java}
public class RexImpTable {
...
if (op == CURRENT_USER
|| op == SESSION_USER
|| op == USER) {
return Expressions.constant("sa");
} else if (op == SYSTEM_USER) {
return Expressions.constant(System.getProperty("user.name"));
...{code}
If the logic is of root and regular is based on Expressions.constant("sa") and
system property then I would rather propagate user from ConnectionInfo but I
need suggestion on how to propagate that to validation level and RexImlTable
lvl.
was (Author: ptrbojko):
[~julianhyde] - could give some hint about builtin user logic? How to get it
around SqlValidator? This should do the last piece. If I can make it have
context of an logged in user in sqlvalidator - I would more generic approach,
something like this:
{code:java}
{
"version": "1.0",
"defaultSchema": "JIRA",
"schemas": [
{
"name": "HIDDEN_SCHEMA",
"type": "custom",
"factory": "some-factory",
"operand": {},
"access" : {
"factory" : "some-new-factory-for-user-based-access-logic",
"operarnds" : {"root","some-user"}
}
}, {
"name": "SOME_OTHER_SCHEMA",
"type": "custom",
"factory": "org.apache.calcite.schema.impl.AbstractSchema$Factory",
"operand": {},
"tables": [
{{code}
This will help to introduce for example role based access.
> 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)
