[Mondrian] Re: NativizeSetFunDefTest and mondrian.olap.SsasCompatibleNaming

[Matt Campbell]

In the version of FoodMart I'm running on SSAS 2005 the Gender dimension is
truly its own dimension, not an attribute hierarchy under Customers.  In
this case, selecting Gender.Gender.members returns the same set as
Gender.Gender.Gender.members.  It appears that if there is a *single* hierarchy
in a dimension with the same name as a level, that it will resolve to the
level.

In the Adventure Works cube the Employee dimension has an Employee hierarchy
and an Employee level.  Unlike Gender in Foodmart, however, it has other
hierarchies as well.  In that case, Employee.Employee *does* refer to the
hierarchy, and Employee.Employee.Employee the level.  So it looks like the
behavior were seeing with Gender.Gender in Foodmart is specific to cases
where the dimension has only a single hierarchy and the hierarchy and level
names are the same.  That is fairly common in the current Mondrian Foodmart
schema.



On Thu, Dec 17, 2009 at 2:42 PM, Julian Hyde <jhyde at pentaho.com> wrote:

>  I think that's because in FoodMart 2005 the Gender hierarchy belongs to
> the Customer dimension. So yes, Gender.Gender is short for the level
> Customers.Gender.Gender, and Gender is short for the hierarchy
> Customers.Gender.
>
> In Mondrian it's a bit different -- the Gender hierarchy belongs to the
> Gender dimension, so Gender.Gender properly refers to the hierarchy, not the
> level.
>
> However, if we use a more representative example, Customer, which is the
> name of a dimension, hierarchy and a level, we get the following behavior on
> SSAS 2005, which is consistent with Mondrian with SsasCompatibleNaming=true.
>
> select head([Customer].members, 3) on 0 from [Warehouse and Sales]
>
> gives error "The 'Customer' dimension contains more than one hierarchy"
>
>  select head([Customer].[Customer].members, 3) on 0 from [Warehouse and
> Sales]
>
> gives All, A. Catherince Binkley, A. Joyce Jarvis
>
>  select head([Customer].[Customer].[Customers].members, 3) on 0 from
> [Warehouse and Sales]
>
>  gives A. Catherince Binkley, A. Joyce Jarvis, Aaron Carabellos.
>
> I really do want to achieve  total compatability with Ssas name-resolution.
> If you can find cases where Mondrian differs, please point them out on this
> list or log a bug.
>
> Julian
>
>  ------------------------------
> *From:* Matt Campbell [mailto:mkambol at gmail.com]
> *Sent:* Wednesday, December 16, 2009 10:13 AM
> *To:* jhyde at pentaho.com
> *Subject:* Re: NativizeSetFunDefTest and
> mondrian.olap.SsasCompatibleNaming
>
> Hi Julian,
>
> The failures are caused by Dimension.Level.Members queries being
> interpreted as Dimension.Hierarchy.Members.  For example,
>
> select  [Gender].[Gender].members on 0 from sales
>
> returns
>
>  Axis #0:
> {}
> Axis #1:
> {[Gender].[All Gender]}
> {[Gender].[All Gender].[F]}
> {[Gender].[All Gender].[M]}
> Row #0: 266,773
> Row #0: 131,558
> Row #0: 135,215
>
>
> This is different than SSAS 2005/2008, which excludes the [All Gender].
>
>  F M
> $10,932.00 $10,696.00
>
>
> We can change the tests to match the currently expected syntax for
> referring to a level, but I wonder if the real fix here is to modify
> Mondrian to be consistent with SSAS behavior.
>
> -matt
>
>
> On Wed, Dec 16, 2009 at 4:29 AM, Julian Hyde <jhyde at pentaho.com> wrote:
>
>>  Matt,
>>
>> If I run the test suite with mondrian.olap.SsasCompatibleNaming=true, I
>> get lots of errors from NativizeSetFunDefTest. This is one of those options
>> for which the test suite needs to pass regardless of the setting. It's
>> important that the test suite works with this option set to true, because
>> this will be the default behavior of mondrian in 4.0.
>>
>> (You weren't to know that this parameter was important. We're setting up a
>> hudson instance that tests all of these obscure parameters, and runs on
>> multiple databases and jdks regularly.)
>>
>> Can you please fix NativizeSetFunDefTest for this option?
>>
>> There are also errors in NonEmptyTest, SchemaTest and XmlaBasicTest. I
>> have not figured out who owns there.
>>
>> Julian
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20091217/562fdc82/attachment.html