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

Julian Hyde jhyde at pentaho.com
Thu Dec 17 15:58:48 EST 2009


Ah, thanks, hadn't noticed that. I wouldn't be surprised if the Microsoft
folks introduced the 'single hierarchy exception' as a hack to make behavior
more similar to AS 2000.
 
I will change Mondrian to be compatible with that. With luck it will make
your test exceptions go away. If not you will hear from me...
 
Julian


  _____  

From: Matt Campbell [mailto:mkambol at gmail.com] 
Sent: Thursday, December 17, 2009 12:20 PM
To: jhyde at pentaho.com
Cc: Mondrian developer mailing list
Subject: Re: NativizeSetFunDefTest and mondrian.olap.SsasCompatibleNaming



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/c50f7514/attachment.html 


More information about the Mondrian mailing list