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


      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 cube="Sales2" access="all">
      <HierarchyGrant hierarchy="[Product]" access="none "></HierarchyGrant>

      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

      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.





            • Assignee:
              jhyde Julian Hyde
              Former Triage User Old Triage User (Inactive)
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created: