[jira] [Comment Edited] (CALCITE-2194) Ability to hide a schema
[
https://issues.apache.org/jira/browse/CALCITE-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394149#comment-16394149
]
Piotr Bojko edited comment on CALCITE-2194 at 3/10/18 6:01 PM:
---
There is no INDIRECT_SELECT in the code -, it is already removed now.
As for the Oracle example - it is solely on the implementation of
AuthorizationGuardFactory now. If someone would create some kind
OracleLikeAuthorizaionGuardFactory then the access to schemas would be exactly
like you've said. Someone can implement other authorization schemes.
What worries me is that your wanted auth scheme requires new relation to schema
- ownership. Having that said - I think that AuthorizationGuardFactory should
be declared not on the schema level but rather root schema, and gives it not
only the responsibility to create a decision maker about accessing to it
(guards) but also the responsibility to define ownership on each schema. With
such design AuthorizatonFactory could be able to handle ownership and roles or
access rights in each schema declared in a file or created under a connection.
Just a quick scratch here:
{code:json}
{
"version": "1.0",
"defaultSchema": "ENHANCED",
"authorization": {
"factory": "org.apache.calcite.access.PrincipalWithOwnershipAuthFactory",
"operand": {}
},
"schemas": [
{
"name": "CHINOOK",
"type": "jdbc",
"jdbcDriver": "org.hsqldb.jdbc.JDBCDriver",
"jdbcUrl": "jdbc:hsqldb:res:chinook",
"jdbcUser": "sa",
"jdbcPassword": "",
"authConfig": {
"sa": "SELECT"
}
},
{
"name": "ENHANCED",
"type": "custom",
"factory": "org.apache.calcite.schema.impl.AbstractSchema$Factory",
"operand": {},
"authConfig": {
"sa": "OWNER",
"user" : "SELECT"
},
"tables": [
...
]
}
]
}
{code}
With such design - user defines his AuthorizationFactory on root level. This
factory will handle creating guards on each schema using authConfig.
[~julianhyde] your particular preference (which I agree is a standard and a
cool addition to calcite which would cover vast area of application, even mine)
and defining ownership or any other information it needs to resolve
authorization to schema. In an example above PrincipalWithOwnershipAuthFactory
will be responsible for handling SELECT/INSERT/etc rights and OWNER role (not
built in to calcite but built in to this factory).
What do you think about above example? I can try to redesign the contribution
to this particular example, which can be more generic. I can provide your
wanted auth scheme (with a notion of an ownership) and present full usage in
chinook example/tests.
EDIT: already shipped that, see chinook.json as an example, ownership added.
Please note that the algorithm in PrincipalBasedAuthorization class covers what
have you said but additionally covers some corner cases, so you may have some
doubts there, hopefully minor :)
was (Author: ptrbojko):
There is no INDIRECT_SELECT in the code -, it is already removed now.
As for the Oracle example - it is solely on the implementation of
AuthorizationGuardFactory now. If someone would create some kind
OracleLikeAuthorizaionGuardFactory then the access to schemas would be exactly
like you've said. Someone can implement other authorization schemes.
What worries me is that your wanted auth scheme requires new relation to schema
- ownership. Having that said - I think that AuthorizationGuardFactory should
be declared not on the schema level but rather root schema, and gives it not
only the responsibility to create a decision maker about accessing to it
(guards) but also the responsibility to define ownership on each schema. With
such design AuthorizatonFactory could be able to handle ownership and roles or
access rights in each schema declared in a file or created under a connection.
Just a quick scratch here:
{code:json}
{
"version": "1.0",
"defaultSchema": "ENHANCED",
"authorization": {
"factory": "org.apache.calcite.access.PrincipalWithOwnershipAuthFactory",
"operand": {}
},
"schemas": [
{
"name": "CHINOOK",
"type": "jdbc",
"jdbcDriver": "org.hsqldb.jdbc.JDBCDriver",
"jdbcUrl": "jdbc:hsqldb:res:chinook",
"jdbcUser": "sa",
"jdbcPassword": "",
"authConfig": {
"sa": "SELECT"
}
},
{
"name": "ENHANCED",
"type": "custom",
"factory": "org.apache.calcite.schema.impl.AbstractSchema$Factory",
"operand": {},
"authConfig": {
"sa": "OWNER",
"user" : "SELECT"
},
"tables": [
...
]
}
]
}
{code}
With such design - user defines his AuthorizationFactory on root level. This
factory will handle creating guards on each schema using authConfig.
[~julianhyde] your particular preference (which I agree is
[jira] [Comment Edited] (CALCITE-2194) Ability to hide a schema
[
https://issues.apache.org/jira/browse/CALCITE-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16392630#comment-16392630
]
Piotr Bojko edited comment on CALCITE-2194 at 3/9/18 1:56 PM:
--
Ok, take your time.
For me the most important is whether SqlAccessEnum can be extended or not. With
INDIRECT_SELECT following schema:
{code}
{
"name": "HIDDEN_SCHEMA",
"type": "custom",
"factory": "some-factory",
"operand": {},
"access" : {
"factory" : "some-new-factory-for-user-based-access-logic",
"operand" : {
"user01" : "SELECT",
"user02" : "INDIRECT_SELECT"
"user03" : "SELECT, INDIRECT_SELECT"
}
}
}
{code}
* for user01 is forbidden to use it indirect through views from other schemas
* for user02 is hidden and it can access it only though views
* for user03 is open for all selects and views
By the time some patches to pull are delivered:
||Issue||Status||
|Reformattng, house style|todo|
|Periods|todo|
|Checkstyle on RexImpTable|done|
|SqlAccessEnum.INDIRECT_SELECT|explained, to be accepted or not|
|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|todo|
|messy .gitignore|done|
was (Author: ptrbojko):
Ok, take your time.
For me the most important is whether SqlAccessEnum can be extended or not. With
INDIRECT_SELECT following schema:
{code:json}
{
"name": "HIDDEN_SCHEMA",
"type": "custom",
"factory": "some-factory",
"operand": {},
"access" : {
"factory" : "some-new-factory-for-user-based-access-logic",
"operand" : {
"user01" : "SELECT",
"user02" : "INDIRECT_SELECT"
"user03" : "SELECT, INDIRECT_SELECT"
}
}
}
{code}
* for user01 is forbidden to use it indirect through views from other schemas
* for user02 is hidden and it can access it only though views
* for user03 is open for all selects and views
> 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)
[jira] [Comment Edited] (CALCITE-2194) Ability to hide a schema
[ https://issues.apache.org/jira/browse/CALCITE-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 ->
[jira] [Comment Edited] (CALCITE-2194) Ability to hide a schema
[
https://issues.apache.org/jira/browse/CALCITE-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Comment Edited] (CALCITE-2194) Ability to hide a schema
[
https://issues.apache.org/jira/browse/CALCITE-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Comment Edited] (CALCITE-2194) Ability to hide a schema
[
https://issues.apache.org/jira/browse/CALCITE-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16377586#comment-16377586
]
Piotr Bojko edited comment on CALCITE-2194 at 2/26/18 9:54 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.
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": "JIRA",
"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)
[jira] [Comment Edited] (CALCITE-2194) Ability to hide a schema
[
https://issues.apache.org/jira/browse/CALCITE-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16377586#comment-16377586
]
Piotr Bojko edited comment on CALCITE-2194 at 2/26/18 9:53 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": "JIRA",
"type": "custom",
"factory": "org.apache.calcite.schema.impl.AbstractSchema$Factory",
"operand": {},
"tables": [
{{code}
This will help to introduce for example role based access.
was (Author: ptrbojko):
[~julianhyde] - could give some hint about builtin user logic? How to get it
around SqlValidator? This should do the last piece.
> 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)
