Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Severe Severe
    • Resolution: Fixed
    • 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

      With Mondrian 3.0.4 the following exception occurs:

      java.lang.ClassCastException: mondrian.rolap.RolapLevel
       at mondrian.rolap.SqlMemberSource.chooseAggStar(SqlMemberSource.java:574)
       at mondrian.rolap.SqlMemberSource.makeChildMemberSql(SqlMemberSource.java:502)
       at mondrian.rolap.SqlMemberSource.getMemberChildren2(SqlMemberSource.java:719)
       at mondrian.rolap.SqlMemberSource.getMemberChildren(SqlMemberSource.java:653)
       at mondrian.rolap.SqlMemberSource.getMemberChildren(SqlMemberSource.java:628)
       at mondrian.rolap.SmartMemberReader.readMemberChildren(SmartMemberReader.java:237)
       at mondrian.rolap.SmartMemberReader.getMemberChildren(SmartMemberReader.java:201)
       at mondrian.rolap.RolapCubeHierarchy$RolapCubeHierarchyMemberReader.readMemberChildren(RolapCubeHierarchy.java:472)
       at mondrian.rolap.RolapCubeHierarchy$RolapCubeHierarchyMemberReader.getMemberChildren(RolapCubeHierarchy.java:568)
       at mondrian.rolap.RolapSchemaReader.getMemberChildren(RolapSchemaReader.java:290)
       at mondrian.olap.DelegatingSchemaReader.getMemberChildren(DelegatingSchemaReader.java:194)
       at mondrian.olap.fun.DescendantsFunDef.descendantsByDepth(DescendantsFunDef.java:163)
       at mondrian.olap.fun.DescendantsFunDef.access$500(DescendantsFunDef.java:31)
       at mondrian.olap.fun.DescendantsFunDef$2.evaluateList(DescendantsFunDef.java:100)
       at mondrian.olap.fun.SetFunDef$ListSetCalc$1.evaluateVoid(SetFunDef.java:131)
       at mondrian.olap.fun.SetFunDef$ListSetCalc.evaluateList(SetFunDef.java:204)
       at mondrian.olap.fun.CrossJoinFunDef$BaseListCalc.evaluateList(CrossJoinFunDef.java:1106)
       at mondrian.calc.impl.AbstractListCalc.evaluate(AbstractListCalc.java:67)
       at mondrian.rolap.RolapResult.evaluateExp(RolapResult.java:794)
       at mondrian.rolap.RolapResult.access$100(RolapResult.java:46)
       at mondrian.rolap.RolapResult$RolapResultEvaluatorRoot.evaluateNamedSet(RolapResult.java:1194)
       at mondrian.rolap.RolapEvaluator.evaluateNamedSet(RolapEvaluator.java:884)
       at mondrian.mdx.NamedSetExpr$1.evaluateList(NamedSetExpr.java:78)
       at mondrian.olap.fun.SetFunDef$ListSetCalc$2.evaluateVoid(SetFunDef.java:149)
       at mondrian.olap.fun.SetFunDef$ListSetCalc.evaluateList(SetFunDef.java:204)
       at mondrian.olap.fun.HierarchizeFunDef$1.evaluateList(HierarchizeFunDef.java:48)
       at mondrian.calc.impl.AbstractListCalc.evaluate(AbstractListCalc.java:67)
       at mondrian.rolap.RolapResult.executeAxis(RolapResult.java:694)
       at mondrian.rolap.RolapResult.evalLoad(RolapResult.java:557)
       at mondrian.rolap.RolapResult.loadMembers(RolapResult.java:532)
       at mondrian.rolap.RolapResult.<init>(RolapResult.java:254)
       at mondrian.rolap.RolapConnection.execute(RolapConnection.java:597)

      It appears that an instance RolapLevel is being returned unexpectedly (instead of RolapCubeLevel) from Level.getChildLevel(). Still working on a Mondrian test case to reproduce this problem with FoodMart. I saw some similar trackers pertaining to ClassCastException however it was not the same stack trace. Not sure if those trackers are directly related to this problem.

        Activity

        Hide
        Mondrian Importer User added a comment -
        {rthar}, 12/03/2008: IP, Artifact Created: 12.183.217.250 |
        {nobody}, 12/03/2008: IP, Comment Added: 98.199.65.80 |
        {jhyde}, 12/04/2008: IP, Comment Added: 66.92.12.96 |
        {ptran01}, 12/09/2008: IP, Comment Added: 12.183.217.250 |
        {rthar}, 01/23/2009: IP, Comment Added: 12.183.217.250 |
        {jhyde}, 01/23/2009: IP, Comment Added: 66.92.12.96 |
        {jhyde}, 01/23/2009: assigned_to, 100 |
        {nobody}, 01/26/2009: IP, Comment Added: 12.183.217.250 |
        {willgorman}, 01/26/2009: IP, Comment Added: 64.132.248.34 |
        {willgorman}, 01/26/2009: status_id, 1 |
        {willgorman}, 01/26/2009: resolution_id, 100 |
        {willgorman}, 01/26/2009: allow_comments, 1 |
        {willgorman}, 01/26/2009: close_date, 0
        Show
        Mondrian Importer User added a comment - {rthar}, 12/03/2008: IP, Artifact Created: 12.183.217.250 | {nobody}, 12/03/2008: IP, Comment Added: 98.199.65.80 | {jhyde}, 12/04/2008: IP, Comment Added: 66.92.12.96 | {ptran01}, 12/09/2008: IP, Comment Added: 12.183.217.250 | {rthar}, 01/23/2009: IP, Comment Added: 12.183.217.250 | {jhyde}, 01/23/2009: IP, Comment Added: 66.92.12.96 | {jhyde}, 01/23/2009: assigned_to, 100 | {nobody}, 01/26/2009: IP, Comment Added: 12.183.217.250 | {willgorman}, 01/26/2009: IP, Comment Added: 64.132.248.34 | {willgorman}, 01/26/2009: status_id, 1 | {willgorman}, 01/26/2009: resolution_id, 100 | {willgorman}, 01/26/2009: allow_comments, 1 | {willgorman}, 01/26/2009: close_date, 0
        Hide
        Mondrian Importer User added a comment -
        {nobody}, 12/03/2008: RolapCubeLevel childLevel = (RolapCubeLevel) member.getLevel().getChildLevel(); <-- Exception thrown here.

        mondrian.rolap.SqlMemberSource:

         public Level getChildLevel() {
                int childDepth = depth + 1;
                Level[] levels = hierarchy.getLevels();
                Level returnLevel = (childDepth < levels.length) ? levels[childDepth] : null;
                return returnLevel;
            }

         
        The getChildLevel() returns a mondrian.rolap.RolapLevel rather than the mondrian.rolap.RolapCubeLevel which is why it's throwing the ClassCastException. I'm not sure why it's returning a mondrian.rolap.RolapLevel. The code comment inside chooseAggStar() indicates that it should always return RolapCubeLevel.

                // childLevel will always end up being a RolapCubeLevel, but the API
                // calls into this method can be both shared RolapMembers and
                // RolapCubeMembers so this cast is necessary for now. Also note that
                // this method will never be called in the context of a virtual cube
                // so baseCube isn't necessary for retrieving the correct column
        Show
        Mondrian Importer User added a comment - {nobody}, 12/03/2008: RolapCubeLevel childLevel = (RolapCubeLevel) member.getLevel().getChildLevel(); <-- Exception thrown here. mondrian.rolap.SqlMemberSource:  public Level getChildLevel() {         int childDepth = depth + 1;         Level[] levels = hierarchy.getLevels();         Level returnLevel = (childDepth < levels.length) ? levels[childDepth] : null;         return returnLevel;     }   The getChildLevel() returns a mondrian.rolap.RolapLevel rather than the mondrian.rolap.RolapCubeLevel which is why it's throwing the ClassCastException. I'm not sure why it's returning a mondrian.rolap.RolapLevel. The code comment inside chooseAggStar() indicates that it should always return RolapCubeLevel.         // childLevel will always end up being a RolapCubeLevel, but the API         // calls into this method can be both shared RolapMembers and         // RolapCubeMembers so this cast is necessary for now. Also note that         // this method will never be called in the context of a virtual cube         // so baseCube isn't necessary for retrieving the correct column
        Hide
        Mondrian Importer User added a comment -
        {jhyde}, 12/04/2008: Can you please post the MDX? Looks like a duplicate of http://jira.pentaho.com/browse/BISERVER-1462 ; the DESCENDANTS function seems to be involved in both bugs.
        Show
        Mondrian Importer User added a comment - {jhyde}, 12/04/2008: Can you please post the MDX? Looks like a duplicate of http://jira.pentaho.com/browse/BISERVER-1462 ; the DESCENDANTS function seems to be involved in both bugs.
        Hide
        Mondrian Importer User added a comment -
        {ptran01}, 12/09/2008: Here is an example MDX:

        WITH
          SET [#DataSet#] AS
            {Descendants([Time].[All],3)}
        SELECT
          {
            [Measures].[SAL_AMT]
           ,[Measures].[File_Margin_Percent]
          } ON COLUMNS
         ,NON EMPTY
            Hierarchize({[#DataSet#]}) ON ROWS
        FROM [Transaction]
        Show
        Mondrian Importer User added a comment - {ptran01}, 12/09/2008: Here is an example MDX: WITH   SET [#DataSet#] AS     {Descendants([Time].[All],3)} SELECT   {     [Measures].[SAL_AMT]    ,[Measures].[File_Margin_Percent]   } ON COLUMNS  ,NON EMPTY     Hierarchize({[#DataSet#]}) ON ROWS FROM [Transaction]
        Hide
        Mondrian Importer User added a comment -
        {rthar}, 01/23/2009: I was able to create a test case based on the FoodMart dataset to reproduce the problem with the Mondrian tip. The test involves a query using the Descendants function(). The problem appears to be data dependent as I was required to have only one non empty child under one parent to reproduce the problem. I used the Store dimension (specifically, USA member, CA member and CA children). The cube Sales2 only contains rows pertaining to CA. Based on the stack trace it appears tracker 2166695 is related to this issue. Below is the test I added to TestAggregationManager.java and mondrian properties to reproduce the problem. Let me know if I can be of further assistance.

        Thanks,

        Robin


            public void testClassCastException() {

             // In order to reproduce the problem it was necessary to only have one
             // non empty member under USA. In the cube definition below we create a cube
             // with only CA data to achieve this.
                String salesCube1 =
                    "<Cube name=\"Sales2\" defaultMeasure=\"Unit Sales\">\n" +
                    " <Table name=\"sales_fact_1997\" >\n" +
                    "<SQL dialect=\"generic\">" +
                    "\"sales_fact_1997\".\"store_id\" in (select distinct \"store_id\" from \"store\" where \"store\".\"store_state\" = 'CA')" +
                    "</SQL>" +
                    " </Table>\n" +
                    " <DimensionUsage name=\"Store\" source=\"Store\" foreignKey=\"store_id\"/>\n" +
                    " <DimensionUsage name=\"Product\" source=\"Product\" foreignKey=\"product_id\"/>\n" +
                    " <Measure name=\"Unit Sales\" column=\"unit_sales\" aggregator=\"sum\" formatString=\"Standard\"/>\n" +
                    " <Measure name=\"Store Sales\" column=\"store_sales\" aggregator=\"sum\" formatString=\"Standard\"/>\n" +
                    "</Cube>\n";
                
                TestContext testContext =
                    TestContext.create(
                        null,
                        salesCube1,
                        null,
                        null,
                        null,
                        null);
                
                // First query all children of the USA. This should only return CA since all the
                // other states were filtered out. CA will be put in the member cache
                String query1 = "WITH SET [#DataSet#] as " +
             "'NonEmptyCrossjoin({[Product].[All Products]}, {[Store].[All Stores].[USA].Children})' " +
             "SELECT {[Measures].[Unit Sales]} on columns, " +
             "NON EMPTY Hierarchize({[#DataSet#]}) on rows FROM [Sales2]";
                
                Result result1 = testContext.executeQuery(query1);
                System.out.println(TestContext.toString(result1));
                
                // Now query the children of CA using the descendants function
                // This is where the ClassCastException occurs
                String query2 = "WITH SET [#DataSet#] as " +
              "'{Descendants([Store].[All Stores], 3)}' " +
              "SELECT {[Measures].[Unit Sales]} on columns, " +
              "NON EMPTY Hierarchize({[#DataSet#]}) on rows FROM [Sales2]";

                Result result2 = testContext.executeQuery(query2);
                System.out.println(TestContext.toString(result2));
                       
            }

        mondrian.properties:

        mondrian.rolap.aggregates.Use=false
        mondrian.rolap.aggregates.Read=false
        mondrian.native.nonempty.enable=true
        mondrian.native.crossjoin.enable=true
        Show
        Mondrian Importer User added a comment - {rthar}, 01/23/2009: I was able to create a test case based on the FoodMart dataset to reproduce the problem with the Mondrian tip. The test involves a query using the Descendants function(). The problem appears to be data dependent as I was required to have only one non empty child under one parent to reproduce the problem. I used the Store dimension (specifically, USA member, CA member and CA children). The cube Sales2 only contains rows pertaining to CA. Based on the stack trace it appears tracker 2166695 is related to this issue. Below is the test I added to TestAggregationManager.java and mondrian properties to reproduce the problem. Let me know if I can be of further assistance. Thanks, Robin     public void testClassCastException() {      // In order to reproduce the problem it was necessary to only have one      // non empty member under USA. In the cube definition below we create a cube      // with only CA data to achieve this.         String salesCube1 =             "<Cube name=\"Sales2\" defaultMeasure=\"Unit Sales\">\n" +             " <Table name=\"sales_fact_1997\" >\n" +             "<SQL dialect=\"generic\">" +             "\"sales_fact_1997\".\"store_id\" in (select distinct \"store_id\" from \"store\" where \"store\".\"store_state\" = 'CA')" +             "</SQL>" +             " </Table>\n" +             " <DimensionUsage name=\"Store\" source=\"Store\" foreignKey=\"store_id\"/>\n" +             " <DimensionUsage name=\"Product\" source=\"Product\" foreignKey=\"product_id\"/>\n" +             " <Measure name=\"Unit Sales\" column=\"unit_sales\" aggregator=\"sum\" formatString=\"Standard\"/>\n" +             " <Measure name=\"Store Sales\" column=\"store_sales\" aggregator=\"sum\" formatString=\"Standard\"/>\n" +             "</Cube>\n";                  TestContext testContext =             TestContext.create(                 null,                 salesCube1,                 null,                 null,                 null,                 null);                  // First query all children of the USA. This should only return CA since all the         // other states were filtered out. CA will be put in the member cache         String query1 = "WITH SET [#DataSet#] as " +      "'NonEmptyCrossjoin({[Product].[All Products]}, {[Store].[All Stores].[USA].Children})' " +      "SELECT {[Measures].[Unit Sales]} on columns, " +      "NON EMPTY Hierarchize({[#DataSet#]}) on rows FROM [Sales2]";                  Result result1 = testContext.executeQuery(query1);         System.out.println(TestContext.toString(result1));                  // Now query the children of CA using the descendants function         // This is where the ClassCastException occurs         String query2 = "WITH SET [#DataSet#] as " +       "'{Descendants([Store].[All Stores], 3)}' " +       "SELECT {[Measures].[Unit Sales]} on columns, " +       "NON EMPTY Hierarchize({[#DataSet#]}) on rows FROM [Sales2]";         Result result2 = testContext.executeQuery(query2);         System.out.println(TestContext.toString(result2));                     } mondrian.properties: mondrian.rolap.aggregates.Use=false mondrian.rolap.aggregates.Read=false mondrian.native.nonempty.enable=true mondrian.native.crossjoin.enable=true
        Hide
        Mondrian Importer User added a comment -
        {jhyde}, 01/23/2009: Thanks for the test case.

        Assigning to Will. He gets all ClassCastException issues. :)
        Show
        Mondrian Importer User added a comment - {jhyde}, 01/23/2009: Thanks for the test case. Assigning to Will. He gets all ClassCastException issues. :)
        Hide
        Mondrian Importer User added a comment -
        {nobody}, 01/26/2009: I attempted the following change below in RolapCubeHierarchy.readMemberChildren():

                    for (RolapCubeMember member : parentRolapCubeMemberList) {
                        lookup.put(
                             getUniqueNameForMemberWithoutHierarchy(
                                          member.getRolapMember()), member);
                
                        // RT
                        // pass RolapCubeMember instance
                        //rolapParents.add(member.getRolapMember());
                        rolapParents.add(member);
                          
                        ....

        The change involves passing in instance of RolapCubeMember instances instead of RolapMember to the parent list. This appears to fix the test case however several other Mondrian Unit tests fail as a result which appear to be related to table alias.
        Show
        Mondrian Importer User added a comment - {nobody}, 01/26/2009: I attempted the following change below in RolapCubeHierarchy.readMemberChildren():             for (RolapCubeMember member : parentRolapCubeMemberList) {                 lookup.put(                      getUniqueNameForMemberWithoutHierarchy(                                   member.getRolapMember()), member);                          // RT                 // pass RolapCubeMember instance                 //rolapParents.add(member.getRolapMember());                 rolapParents.add(member);                                    .... The change involves passing in instance of RolapCubeMember instances instead of RolapMember to the parent list. This appears to fix the test case however several other Mondrian Unit tests fail as a result which appear to be related to table alias.
        Hide
        Mondrian Importer User added a comment -
        {willgorman}, 01/26/2009: fixed in change #12284. This fix will be available in Mondrian 3.1
        Show
        Mondrian Importer User added a comment - {willgorman}, 01/26/2009: fixed in change #12284. This fix will be available in Mondrian 3.1

          People

          • Assignee:
            Will Gorman
            Reporter:
            rthar
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: