[prev in list] [next in list] [prev in thread] [next in thread]
List: mondrian
Subject: [Mondrian] RE: NativizeSetFunDefTest and
From: "Julian Hyde" <jhyde () pentaho ! com>
Date: 2009-12-17 20:58:48
Message-ID: 25BC6DC307F84CE580552EB31A3760A8 () mackerel
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@gmail.com]
Sent: Thursday, December 17, 2009 12:20 PM
To: jhyde@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@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@gmail.com]
Sent: Wednesday, December 16, 2009 10:13 AM
To: jhyde@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@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
[Attachment #5 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18865"></HEAD>
<BODY>
<DIV><SPAN class=849145720-17122009><FONT color=#000080 size=2
face="Lucida Sans">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.</FONT></SPAN></DIV>
<DIV><SPAN class=849145720-17122009><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=849145720-17122009><FONT color=#000080 size=2
face="Lucida Sans">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...</FONT></SPAN></DIV>
<DIV><SPAN class=849145720-17122009><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=849145720-17122009><FONT color=#000080 size=2
face="Lucida Sans">Julian</FONT></SPAN></DIV><BR>
<BLOCKQUOTE
style="BORDER-LEFT: #000080 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; \
MARGIN-RIGHT: 0px" dir=ltr>
<DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
<HR tabIndex=-1>
<FONT size=2 face=Tahoma><B>From:</B> Matt Campbell [mailto:mkambol@gmail.com]
<BR><B>Sent:</B> Thursday, December 17, 2009 12:20 PM<BR><B>To:</B>
jhyde@pentaho.com<BR><B>Cc:</B> Mondrian developer mailing
list<BR><B>Subject:</B> Re: NativizeSetFunDefTest and
mondrian.olap.SsasCompatibleNaming<BR></FONT><BR></DIV>
<DIV></DIV><BR>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
<I>single</I> hierarchy in a dimension with the same name as a level,
that it will resolve to the level.
<DIV><BR></DIV>
<DIV>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 <I>does</I> 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.</DIV>
<DIV><BR></DIV>
<DIV><BR></DIV>
<DIV>
<DIV><BR>
<DIV class=gmail_quote>On Thu, Dec 17, 2009 at 2:42 PM, Julian Hyde <SPAN
dir=ltr><<A
href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE
style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex"
class=gmail_quote>
<DIV>
<DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">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.</FONT></SPAN></DIV>
<DIV><SPAN><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">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.</FONT></SPAN></DIV>
<DIV><SPAN><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">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.</FONT></SPAN></DIV>
<DIV><SPAN><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">select
head([Customer].members, 3) on 0 from [Warehouse and
Sales]</FONT></SPAN></DIV>
<DIV><SPAN><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">gives error "The
'Customer' dimension contains more than one hierarchy"</FONT></SPAN></DIV>
<DIV><SPAN><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">
<DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">select
head([Customer].[Customer].members, 3) on 0 from [Warehouse and
Sales]</FONT></SPAN></DIV>
<DIV><SPAN></SPAN> </DIV>
<DIV><SPAN>gives All, A. Catherince Binkley, A. Joyce Jarvis</SPAN></DIV>
<DIV><SPAN></SPAN> </DIV>
<DIV><SPAN>
<DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">select
head([Customer].[Customer].[Customers].members, 3) on 0 from [Warehouse and
Sales]</FONT></SPAN></DIV>
<DIV><SPAN></SPAN> </DIV>
<DIV><SPAN>
<DIV><SPAN>gives A. Catherince Binkley, A. Joyce Jarvis, Aaron
Carabellos.</SPAN></DIV>
<DIV><SPAN></SPAN> </DIV>
<DIV><SPAN>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.</SPAN></DIV>
<DIV><SPAN></SPAN> </DIV>
<DIV><SPAN>Julian</SPAN></DIV></SPAN></DIV></SPAN></DIV></FONT></SPAN></DIV><BR>
<BLOCKQUOTE
style="BORDER-LEFT: #000080 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; \
MARGIN-RIGHT: 0px" dir=ltr>
<DIV dir=ltr lang=en-us align=left>
<HR>
<FONT size=2 face=Tahoma><B>From:</B> Matt Campbell [mailto:<A
href="mailto:mkambol@gmail.com" target=_blank>mkambol@gmail.com</A>]
<BR><B>Sent:</B> Wednesday, December 16, 2009 10:13 AM<BR><B>To:</B> <A
href="mailto:jhyde@pentaho.com"
target=_blank>jhyde@pentaho.com</A><BR><B>Subject:</B> Re:
NativizeSetFunDefTest and
mondrian.olap.SsasCompatibleNaming<BR></FONT><BR></DIV>
<DIV>
<DIV></DIV>
<DIV class=h5>
<DIV></DIV>Hi Julian,
<DIV><BR></DIV>
<DIV>The failures are caused by Dimension.Level.Members queries being
interpreted as Dimension.Hierarchy.Members. For example, </DIV>
<DIV><BR></DIV>
<DIV>select [Gender].[Gender].members on 0 from sales</DIV>
<DIV><BR></DIV>
<DIV>returns</DIV>
<DIV><BR></DIV>
<DIV>
<DIV>Axis #0:</DIV>
<DIV>{}</DIV>
<DIV>Axis #1:</DIV>
<DIV>{[Gender].[All Gender]}</DIV>
<DIV>{[Gender].[All Gender].[F]}</DIV>
<DIV>{[Gender].[All Gender].[M]}</DIV>
<DIV>Row #0: 266,773</DIV>
<DIV>Row #0: 131,558</DIV>
<DIV>Row #0: 135,215</DIV>
<DIV><BR></DIV>
<DIV><BR></DIV>
<DIV>This is different than SSAS 2005/2008, which excludes the [All
Gender].</DIV>
<DIV><BR></DIV>
<DIV>
<DIV>F<SPAN style="WHITE-SPACE: pre"> </SPAN>M</DIV>
<DIV>$10,932.00<SPAN style="WHITE-SPACE: pre">
</SPAN>$10,696.00</DIV></DIV>
<DIV><BR></DIV>
<DIV><BR></DIV>
<DIV>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.</DIV>
<DIV><BR></DIV>
<DIV>-matt</DIV>
<DIV><FONT color=#000080 size=2 face="Lucida Sans"></FONT><BR></DIV><BR>
<DIV class=gmail_quote>On Wed, Dec 16, 2009 at 4:29 AM, Julian Hyde <SPAN
dir=ltr><<A href="mailto:jhyde@pentaho.com"
target=_blank>jhyde@pentaho.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE
style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: \
1ex" class=gmail_quote>
<DIV>
<DIV><SPAN><FONT color=#000080 size=2
face="Lucida Sans">Matt,</FONT></SPAN></DIV>
<DIV><SPAN><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">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.
<SPAN><FONT color=#000080 size=2 face="Lucida Sans">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.</FONT></SPAN></FONT></SPAN></DIV>
<DIV><SPAN><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">(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.)</FONT></SPAN></DIV>
<DIV><SPAN><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">Can you
please fix </FONT><FONT color=#000080 size=2
face="Lucida Sans">NativizeSetFunDefTest for this
option?</FONT></SPAN></DIV>
<DIV><SPAN><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">There are also
errors in NonEmptyTest, SchemaTest and XmlaBasicTest. I have not figured
out who owns there.</FONT></SPAN></DIV>
<DIV><SPAN><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV><FONT color=#888888>
<DIV><SPAN><FONT color=#000080 size=2
face="Lucida \
Sans">Julian</FONT></SPAN></DIV></FONT></DIV></BLOCKQUOTE></DIV><BR></DIV></DIV></DIV> \
</BLOCKQUOTE></DIV></BLOCKQUOTE></DIV><BR></DIV></DIV></BLOCKQUOTE></BODY></HTML>
_______________________________________________
Mondrian mailing list
Mondrian@pentaho.org
http://lists.pentaho.org/mailman/listinfo/mondrian
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic