Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Severe Severe
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • 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.

      Description

      Hi there, Mondrian Team and thank you for the excellent work so far.

      While using Mondrian we believe we've found a potential bug within the "hashCode()" method of "mondrian.rolap.RolapCubeHierarchy".

      What we were trying to do, was to create a single role that has grants defined for two different (physical) cubes which both contain the same hierarchy. Here's a simplified example:

      <Role name="Role">
      <SchemaGrant access="none">
      <CubeGrant cube="Sales" access="all">
      <HierarchyGrant hierarchy="[Product]" access="all "></HierarchyGrant>
      </CubeGrant>
      <CubeGrant cube="Sales2" access="all">
      <HierarchyGrant hierarchy="[Product]" access="none "></HierarchyGrant>
      </CubeGrant>
      </SchemaGrant>
      </Role>

      Now what is happening when Mondrian loads the schema file and creates an object from the role, is that only ONE of the two hierarchy-definitions is actually added to the Map of hierarchies within RoleImpl.java:

      private final Map<Hierarchy, HierarchyAccessImpl> hierarchyGrants =
      new HashMap<Hierarchy, HierarchyAccessImpl>();

      This is - by our judgement – due to the hierarchy itself being the HashMap's key. As we all know, HashMaps use their key-classes' hashCode()-methods as indicator whether a key-object is unique. And in case it is not, another already present object within the map will be replaced.

      Looking at the hashCode for RolapCubeHierarchy:

      public int hashCode()

      { return super.hashCode() ^ (getUniqueName() == null ? 0 : getUniqueName().hashCode()); }

      it's obvious, that – if present – the hierarchie's unique-name is basis for it's hashCode.
      Why is that so? Is there any reason for not taking in to account different hierarchy-grants for the same hierarchy riding in several cubes? Probably it is necessary to change a role's interface so Mondrian is able to use hierarchy-grant #1 only for queries on cube #1? In this case the current interface would be bad or at least incomplete design.

      So what we did to quick-fix the issue was simply to rewrite the hashCode()-method to:

      public int hashCode()

      { return super.hashCode() ^ (getUniqueName() == null ? 0 : (getUniqueName().hashCode() ^ getDimension().getCube().hashCode() ) ); }

      After this correction – which is probably not complete -, our tests showed no further problems and we were able to create the roles we had in mind. Hopefully my description of the problem was helpful and maybe you will include a fix in Mondrian's next release.

      Ferdinand

        Activity

        Hide
        Mondrian Importer User added a comment -
        {nobody}

        , 04/23/2008: IP, Artifact Created: 212.144.101.74 |

        {jhyde}, 04/23/2008: IP, Comment Added: 64.81.57.79 | {jhyde}

        , 04/23/2008: assigned_to, 100 |

        {jhyde}, 05/01/2008: IP, Comment Added: 66.92.12.96 | {jhyde}

        , 05/01/2008: status_id, 1 |

        {jhyde}, 05/01/2008: resolution_id, 100 | {jhyde}

        , 05/01/2008: assigned_to, 160824 |

        {jhyde}

        , 05/01/2008: close_date, 0

        Show
        Mondrian Importer User added a comment - {nobody} , 04/23/2008: IP, Artifact Created: 212.144.101.74 | {jhyde}, 04/23/2008: IP, Comment Added: 64.81.57.79 | {jhyde} , 04/23/2008: assigned_to, 100 | {jhyde}, 05/01/2008: IP, Comment Added: 66.92.12.96 | {jhyde} , 05/01/2008: status_id, 1 | {jhyde}, 05/01/2008: resolution_id, 100 | {jhyde} , 05/01/2008: assigned_to, 160824 | {jhyde} , 05/01/2008: close_date, 0
        Hide
        Mondrian Importer User added a comment -
        {jhyde}

        , 04/23/2008: Logged In: YES
        user_id=312935
        Originator: NO

        Duplicate of 1949936? Will please decide.

        Show
        Mondrian Importer User added a comment - {jhyde} , 04/23/2008: Logged In: YES user_id=312935 Originator: NO Duplicate of 1949936? Will please decide.
        Hide
        Mondrian Importer User added a comment -
        {jhyde}

        , 05/01/2008: Logged In: YES
        user_id=312935
        Originator: NO

        Duplicate of 1949936.

        Show
        Mondrian Importer User added a comment - {jhyde} , 05/01/2008: Logged In: YES user_id=312935 Originator: NO Duplicate of 1949936.

          People

          • Assignee:
            Julian Hyde
            Reporter:
            Unassigned User
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: