Uploaded image for project: 'Pentaho Analysis - Mondrian'
  1. Pentaho Analysis - Mondrian
  2. MONDRIAN-1575

Push down access-control constraints to SQL



    • Type: Improvement
    • Status: Open
    • Severity: Medium
    • Resolution: Unresolved
    • Affects Version/s: 3.6.x (5.0.0 GA Backlog)
    • Fix Version/s: Backlog
    • Component/s: None
    • Labels:
    • Story Points:
    • Notice:
      When an issue is open, the "Fix Version/s" field conveys a target, not necessarily a commitment. When an issue is closed, the "Fix Version/s" field conveys the version that the issue was fixed in.


      Mondrian should be smarter about applying declarative security constraints when executing queries.

      Just adding security reduces performance substantially because of the very large number of calls Mondrian makes to evaluate security. (This is another example of poor large-dimension performance.)


      0. Create a sub interface to Role which can be queried by Mondrian to know if optimized constraints are possible on specific metadata element. ie:

      public List<String> getAccessibleMembers(RolapCubeDimension dim);
      public List<String> getAccessibleMembers(RolapCubeHierarchy dim);
      public List<String> getAccessibleMembers(RolapCubeLevel level);
      public List<String> getAccessibleMembers(RolapCubeMember member);

      All methods can return 'null' if it can't tell which exact members are accessible. This will happen often because you might only be able to establish that list on a per-level basis or per-dimension, but not both at the same time. 5d.

      1. Change behavior of MDX functions in an access-controlled context.
      <Level>.Members. [City].Members becomes equivalent to [USA].[CA].Children if current role can only see California.
      Similarly Descendants
      Not worth the effort for functions that only return one member, e.g. PrevMember or Parent.
      Not sure whether we would optimize at prepare time (i.e. generate a different tree of MDX operators) or at runtime (i.e. change behavior of functions or SchemaReader calls).
      Cost 3d for Descendants and <Level>.Members; then see if it's worth applying further optimizations.

      2. In native queries, apply above transformations before we translate MDX functions to SQL. Could yield much more efficient SQL. 10d.

      Commit to .members, .decendants, and other obvious members. This is not a full-blown push-down strategy.

      QA Requirements: Dev comes up with role definitions and different reports. QA can verify that the SQL was pushed down correctly. Dev has to write more to extend Food Mart sample data.

      Doc Requirements: The current documentation in the Analysis guide does not have to be changed.

        PractiTest Integration


            Issue Links



                Unassigned Unassigned
                jhyde Julian Hyde (Inactive)
                0 Vote for this issue
                4 Start watching this issue