Re: [DISCUSS] On removing Cube ACL

2017-08-19 Thread Li Yang
(correct) So it does not *simplify *anything. A clear removal is still preferred, in my opinion. On Sun, Aug 20, 2017 at 1:16 PM, Li Yang wrote: > I think we are looking for a clear attitude here. Leaving an extension > point is the same to say "cube level ACL shall be

Re: [DISCUSS] On removing Cube ACL

2017-08-19 Thread Li Yang
I think we are looking for a clear attitude here. Leaving an extension point is the same to say "cube level ACL shall be kept in design". Because we still have to think about how the extension point works with project/model ACL etc. So it does not simply anything. On Tue, Aug 15, 2017 at 11:59

Re: [DISCUSS] On removing Cube ACL

2017-08-15 Thread Luke Han
Data Model level is better than Cube level. How about to leave extend point there for people who want to keep Cube Level ACL? Best Regards! - Luke Han On Tue, Aug 15, 2017 at 5:30 PM, Li Yang wrote: > So we can still control who can (or cannot)

Re: [DISCUSS] On removing Cube ACL

2017-08-15 Thread Li Yang
So we can still control who can (or cannot) access a cube by defining ACL on tables, right? On Mon, Aug 7, 2017 at 2:26 PM, ShaoFeng Shi wrote: > It makes sense for me. Will the Cube ACL info be migrated (from Cube to > Table) when it is done? > > 2017-08-07 10:37

[DISCUSS] On removing Cube ACL

2017-08-06 Thread hongbin ma
Current ACL design is based on very early versions where kylin merely had simple concepts like projects and cubes. With the advent of Kylin v2.0, and several new concepts like Data Model ( http://kylin.apache.org/docs/gettingstarted/concepts.html) and Query Pushdown (KYLIN-2515), the original