Pentaho Analysis - Mondrian
  1. Pentaho Analysis - Mondrian
  2. MONDRIAN-229

NON EMPTY when hierarchy's default member is not 'all'

    Details

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

      What should be the behavior of an MDX query when a
      hierarchy's default member is not 'all'?

      See the testcase in mondrian.rolap.aggmatcher.Checkin_7641.

      Richard Emberson writes:

      > Regarding check in 7887:
      > I've just checked in a junit (Checkin_7641.java and
      > Checkin_7641.csv) along with a change to
      > RolapResult.java that shows the issue
      > associated with Checkin 7641. I defined a new property,
      > "mondrian.test.checkin.7641". If it is non-null, then
      > the Checkin 7641 code is not used and if it is null,
      > then the code is used. The junit sets the property,
      > runs a query, removes the property,
      > re-runs the query and then compares the two result.
      >
      > I do not intend for the RolapResult code changes
      > associated with this checkin to remain a part of the
      > code base, but its the only way to demonstrate the
      > issue.

      Matt Campbell had some issues with the performance of
      the code Richard added to RolapResult. First, let's
      decide whether the behavior is correct. Second, let's
      figure out a way to implement the behavior more
      efficiently. Assigning to you, Matt.

      Julian

        Activity

        Hide
        Mondrian Importer User added a comment -
        {mkambol}, 11/01/2006: assigned_to, 1479052
        Show
        Mondrian Importer User added a comment - {mkambol}, 11/01/2006: assigned_to, 1479052
        Hide
        Mondrian Importer User added a comment -
        {avix}, 10/30/2006: Logged In: YES
        user_id=36405

        I think the change is wrong. What does the spec say? For
        example with foodmart

        select
        NON EMPTY Crossjoin({[Time][1998]},
        [Customer].[Name].members) on columns,
        NON EMPTY [Product].[Name].members on rows
        where [Measures].[Unit Sales]

        then I would expect the customers who bought in 1998 (time
        defined in crossjoin) on the columns and the Products that
        were sold in 1997 (default-member) in the rows.
        Show
        Mondrian Importer User added a comment - {avix}, 10/30/2006: Logged In: YES user_id=36405 I think the change is wrong. What does the spec say? For example with foodmart select NON EMPTY Crossjoin({[Time][1998]}, [Customer].[Name].members) on columns, NON EMPTY [Product].[Name].members on rows where [Measures].[Unit Sales] then I would expect the customers who bought in 1998 (time defined in crossjoin) on the columns and the Products that were sold in 1997 (default-member) in the rows.
        Hide
        Mondrian Importer User added a comment -
        {mkambol}, 11/01/2006: Logged In: YES
        user_id=1479052

        I ran a quick test in Analysis Services to check its
        behavior, using a similar query. I set the default time
        member to be [Time].[1997].[Q1].[1], then ran the query below.

        select
        NON EMPTY
        Crossjoin({[Time].[1997].[Q2].[4]},
        [Customers].[Country].members) on columns,
        NON EMPTY [Product].[All Products].[Drink].[Alcoholic
        Beverages].[Beer and Wine].[Beer].[Portsmouth].children on rows
        from sales

        This returns the products that were sold in Q2.4, NOT in the
        default member Q1.1. I'm not sure what the spec says, but
        I'm usually in favor of consistency with AS.

        I'm actually not aware of the performance issues that Julian
        mentions, so I'm assigning this back to Richard.
        Show
        Mondrian Importer User added a comment - {mkambol}, 11/01/2006: Logged In: YES user_id=1479052 I ran a quick test in Analysis Services to check its behavior, using a similar query. I set the default time member to be [Time].[1997].[Q1].[1], then ran the query below. select NON EMPTY Crossjoin({[Time].[1997].[Q2].[4]}, [Customers].[Country].members) on columns, NON EMPTY [Product].[All Products].[Drink].[Alcoholic Beverages].[Beer and Wine].[Beer].[Portsmouth].children on rows from sales This returns the products that were sold in Q2.4, NOT in the default member Q1.1. I'm not sure what the spec says, but I'm usually in favor of consistency with AS. I'm actually not aware of the performance issues that Julian mentions, so I'm assigning this back to Richard.
        Hide
        Mondrian Importer User added a comment -
        {jhyde}, 11/01/2006: Logged In: YES
        user_id=312935

        In change 8048, I've added Matt's test
        NonEmptyTest.testNonEmptyWithWeirdDefaultMember. The
        behavior of this test is consistent with MSAS 2000 SP1.
        Show
        Mondrian Importer User added a comment - {jhyde}, 11/01/2006: Logged In: YES user_id=312935 In change 8048, I've added Matt's test NonEmptyTest.testNonEmptyWithWeirdDefaultMember. The behavior of this test is consistent with MSAS 2000 SP1.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: