<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6001.18063" name=GENERATOR></HEAD>
<BODY
style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space">
<DIV dir=ltr align=left><SPAN class=922594819-14072008><FONT face=Verdana
color=#000080 size=2>Looks like we have very different opinions on this issue.
The way I see it, we have a half implemented feature. I think that most mondrian
users would see it that way too.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=922594819-14072008><FONT face=Verdana
color=#000080 size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=922594819-14072008><FONT face=Verdana
color=#000080 size=2>(I'd like to hear about other developers on the list feel
about this.)</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=922594819-14072008><FONT face=Verdana
color=#000080 size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=922594819-14072008><FONT face=Verdana
color=#000080 size=2>My decision principle in mondrian has been orthogonality:
every feature has to work with every other feature. It's not possible for
feature X to work in environment Y, then the implementation should fall back to
the basic implementation which works, and things are no worse than they would
have been without feature X.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=922594819-14072008><FONT face=Verdana
color=#000080 size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=922594819-14072008><FONT face=Verdana
color=#000080 size=2>Looking at the whole picture, of end-user perceptions,
maintainability, and simplicity, I would in general rather leave out a feature
than have it half implemented.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=922594819-14072008><FONT face=Verdana
color=#000080 size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=922594819-14072008><FONT face=Verdana
color=#000080 size=2>The mondrian.test.highCardDimensions flag is a neat trick
to ensure orthogonality. It shows up losts of test failures because
high-cardinality dimensions are partially implemented. The solution is not to
remove the mondrian.test.highCardDimensions test, but to fix (or remove)
high-cardinality dimensions support. You appeal for the community to help
implement high-cardinality support, but I don't see that happening, at least not
in the time scales we need.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=922594819-14072008><FONT face=Verdana
color=#000080 size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=922594819-14072008><FONT face=Verdana
color=#000080 size=2>One idea that may help us fix it. There's a lot in common
between high-cardinality dimensions and the ITERABLE result style (see <A
href="http://mondrian.pentaho.org/api/src-html/mondrian/calc/ResultStyle.html">http://mondrian.pentaho.org/api/src-html/mondrian/calc/ResultStyle.html</A>),
which causes functions to return their results as iterators rather than lists.
Richard Emberson did a lot of work on that feature, and it is now a fully
orthogonal part of the architecture; if a function isn't implemented in the
ITERABLE style, mondrian creates an adapter to implement it in the LIST style.
In other words, the system fails gracefull. Every so often, someone contributes
an implementation of another function in ITERABLE style.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=922594819-14072008><FONT face=Verdana
color=#000080 size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=922594819-14072008><FONT face=Verdana
color=#000080 size=2>Is there a way to leverage this in order to get
high-cardinality dimensions to the status of a fully-implemented
feature?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=922594819-14072008><FONT face=Verdana
color=#000080 size=2></FONT></SPAN> </DIV><SPAN
class=922594819-14072008></SPAN><FONT face=Verdana><FONT color=#000080><FONT
size=2>Julian<SPAN class=922594819-14072008></SPAN></FONT></FONT></FONT><BR>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000080 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Luis F. Canals
[mailto:luisf.canals@gmail.com] <B>On Behalf Of </B>Luis F.
Canals<BR><B>Sent:</B> Sunday, July 13, 2008 11:47 PM<BR><B>To:</B>
jhyde@pentaho.com<BR><B>Cc:</B> jorge.lopez@stratebi.com;
javier.gimenez@stratebi.com; mondrian@pentaho.org<BR><B>Subject:</B> Re: Test
failures with high-cardinality dimensions<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV>
<DIV>Hi all,</DIV>
<DIV><BR></DIV>
<DIV>about this question, problem arises when using functions with high
cardinality dimensions not implemented (or not implementable) for this kind of
dimensions.</DIV>
<DIV>Since not every function or query will work for high cardinality
dimensions, I think it's not a good idea to use
"mondrian.test.highCardDimensions=...". The solution would be to use
mondrian/rolap/HighDimensionsTest (or simiar) and include any tests related
with high dimensions into it instead of this kind of "blind" tests for all
functions.</DIV>
<DIV><BR></DIV>
<DIV>So the first thing to do is: move from testing every functions against
high card. dimensions to detailed tests function by function for suitable
ones.</DIV>
<DIV><BR></DIV>
<DIV>The key question here is the limitations for the meaning of "high
cardility" feature: high cardinality dimensions are able to be managed. But
the use of functions with these kind of dimensions can't be equivalent to
usual dimensions. Mainly, all functions that require the whole set of elements
to produce a result will not work for high cardinality dimensions
(obviously).</DIV>
<DIV><BR></DIV>
<DIV>At this time, we have no human sructure to refactor everything and
implement all possible functions to work with high dimension property
(Mondrian is a very big project). </DIV>
<DIV>It's a continuous task, open for everyone, ans sould be done by
everyone.</DIV>
<DIV><BR></DIV>
<DIV>The first (and most difficult) step has been done: Mondrian can read high
cardinality dimensions; the second step (implement all suitable functions to
work for high cardimality dimensions) is drafted, with "head", "count",
"filter" and "non empty" functions already running. </DIV>
<DIV><BR></DIV>
<DIV>I see here an opportunity to "transfer knowledge": it would be better
that someone (different than us) made propper changes to implement "Ancestor"
function (if has sense) for high cardilanity dimensions. For example, for
"Ancestor" function, the approach would be:</DIV>
<DIV> The first question: Would Ancestor work for high cardinality
dimensions? </DIV>
<DIV> Second question: How would it work for h.c.
dimensions?</DIV>
<DIV> Then, implement it.</DIV>
<DIV><BR></DIV>
<DIV><BR></DIV>
<DIV>Best regards!</DIV>
<DIV><BR></DIV></DIV><BR>
<DIV apple-content-edited="true"><SPAN class=Apple-style-span
style="WORD-SPACING: 0px; FONT: 12px Arial; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: 2; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0">
<DIV
style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space">
<DIV>- Luis F. Canals</DIV>
<DIV> CISM</DIV>
<DIV> <A
href="mailto:luis.canals@stratebi.com">luis.canals@stratebi.com</A></DIV>
<DIV><BR></DIV></DIV></SPAN><BR class=Apple-interchange-newline></DIV><BR>
<DIV>
<DIV>On 06/07/2008, at 19:48, Julian Hyde wrote:</DIV><BR
class=Apple-interchange-newline>
<BLOCKQUOTE type="cite">
<DIV>
<DIV><SPAN lang=EN>
<P><SPAN class=956503317-06072008><FONT face=Verdana color=#000080
size=2>Luis, Jorge, Javier,</FONT></SPAN></P>
<P><SPAN class=956503317-06072008><FONT face=Verdana color=#000080
size=2>There are still some errors with high-cardinality dimensions. See
below; and also search for 'execHighCardTest' in <A
href="http://www.hydromatic.net/buildlogs/mondrian-marmalade.hydromatic.net-20080705-change11263.log.bz2">http://www.hydromatic.net/buildlogs/mondrian-marmalade.hydromatic.net-20080705-change11263.log.bz2</A>.</FONT></SPAN></P>
<P><SPAN class=956503317-06072008><FONT face=Verdana color=#000080 size=2>Do
you know about these? Any idea what the cause is? When can they be
fixed?</FONT></SPAN></P>
<P><SPAN class=956503317-06072008><FONT face=Verdana color=#000080
size=2>Julian</FONT></SPAN></P>
<P>Running test with JDK=jdk1.6 retroweave= database=oracle props={
mondrian.test.highCardDimensions=Store}</P>
<P>[java] 1)
testAncestorNumeric(mondrian.olap.fun.FunctionTest)mondrian.olap.MondrianException:
Mondrian Error:Failed to parse query 'select
{Ancestor([Store].[USA].[Washington], 1)} on columns from [Sales
Ragged]'</P>
<P>[java] 2)
testAncestorWithHiddenParent(mondrian.olap.fun.FunctionTest)mondrian.olap.MondrianException:
Mondrian Error:Failed to parse query 'select {Ancestor([Store].[All
Stores].[Israel].[Haifa], [Store].[Store Country])} on columns from [Sales
Ragged]'</P>
<P>[java] 3)
testOrdinal(mondrian.olap.fun.FunctionTest)mondrian.olap.MondrianException:
Mondrian Error:Failed to parse query 'with member [Measures].[Foo] as
'[Store].[All Stores].[USA].[Washington].ordinal' select {[Measures].[Foo]}
on columns from [Sales Ragged]'</P>
<P>[java] 4)
testLead(mondrian.test.RaggedHierarchyTest)mondrian.olap.MondrianException:
Mondrian Error:Failed to parse query 'select {[Store].[All
Stores].[Mexico].[DF].Lead(1)} on columns from [Sales Ragged]'</P>
<P>[java] 5)
testParentOfHaifa(mondrian.test.RaggedHierarchyTest)mondrian.olap.MondrianException:
Mondrian Error:Failed to parse query 'select
{[Store].[Israel].[Haifa].Parent} on columns from [Sales Ragged]'</P>
<P>[java] 6)
testPrevMemberOfHaifa(mondrian.test.RaggedHierarchyTest)mondrian.olap.MondrianException:
Mondrian Error:Failed to parse query 'select
{[Store].[Israel].[Haifa].PrevMember} on columns from [Sales Ragged]'</P>
<P>[java] 7)
testNextMemberOfTelAviv(mondrian.test.RaggedHierarchyTest)mondrian.olap.MondrianException:
Mondrian Error:Failed to parse query 'select {[Store].[Israel].[Tel
Aviv].NextMember} on columns from [Sales Ragged]'</P>
<P>[java] 8)
testNextMemberOfBC(mondrian.test.RaggedHierarchyTest)mondrian.olap.MondrianException:
Mondrian Error:Failed to parse query 'select {[Store].[All
Stores].[Canada].[BC].NextMember} on columns from [Sales Ragged]'</P>
<P>[java] 9)
testAncestorOfHaifa(mondrian.test.RaggedHierarchyTest)mondrian.olap.MondrianException:
Mondrian Error:Failed to parse query 'select
{Ancestor([Store].[Israel].[Haifa], [Store].[Store State])} on columns from
[Sales Ragged]'</P>
<P>[java] 10)
testDataSourceChangeListenerPlugin(mondrian.rolap.DataSourceChangeListenerTest)java.lang.ClassCastException:
mondrian.rolap.NoCacheMemberReader cannot be cast to
mondrian.rolap.SmartMemberReader</P>
<P>[java] 11)
testLookupMemberCache(mondrian.rolap.NonEmptyTest)java.lang.ClassCastException:
mondrian.rolap.NoCacheMemberReader cannot be cast to
mondrian.rolap.SmartMemberReader</P>
<P>[java] 12)
testLookupMember2(mondrian.rolap.NonEmptyTest)mondrian.olap.MondrianException:
Mondrian Error:Failed to parse query 'select {[Store].[USA].[Washington]} on
columns from [Sales Ragged]'</P>
<P>[java] 1)
testCrossJoinAsteriskQuery(mondrian.olap.fun.FunctionTest)junit.framework.ComparisonFailure:
Expected:</P>
<P>[java] 2)
testCalculatedMemberInCube(mondrian.test.TestCalculatedMembers)junit.framework.ComparisonFailure:
Expected:</P>
<P>[java] 3)
testHierarchize(mondrian.test.RaggedHierarchyTest)junit.framework.ComparisonFailure:
Expected:</P>
<P>[java] 4)
testDescendantsOfRootAtCity(mondrian.test.RaggedHierarchyTest)junit.framework.ComparisonFailure:
Expected:</P>
<P>[java] Tests run: 1856, Failures: 4, Errors:
12</P></SPAN></DIV></DIV></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></BODY></HTML>