[Mondrian] RE: Change 12424

Matt Campbell mkambol at gmail.com
Wed Mar 18 10:15:31 EDT 2009


So I ran into a small hurdle with updating the OracleDialect.  The proper
syntax in oracle is something like
ORDER BY "time_by_day"."the_year" DESC NULLS LAST

The .forceNullsCollateLast() is called independently of placing the ASC or
DESC.  Placing ASC/DESC in the statement needs to happen before the call to
forceNullsCollateLast(), however, to work properly with Oracle (although not
with MySQL).

I see a couple options:
1)  modify the definition of forceNullsCollateLast() to take a parameter to
specify ascending or descending.
2)  require that the expression, including the ASC or DESC, be passed to
forceNullsCollateLast().  The Oracle dialect can then make sure the NULLS
LAST happens after the ASC/DESC.

Any preference?


On Wed, Mar 18, 2009 at 9:29 AM, Matt Campbell <mkambol at gmail.com> wrote:

> testNullCollation fails for a similar reason.  It was formerly not invoking
> native top count, since the redundant curly braces ("{[Store].[Store
> Name].members}") were causing it to fail native evaluation checks.  Now that
> it does invoke native evaluation it exposes a bug in the Oracle dialect.
>  The native query orders by both the [Store Name] ordinal and [store sqft],
> but omits the NULLS LAST expression.  Oracle requires the NULLS LAST
> expression for proper collation, which is not captured in the dialect.  I'll
> look into making this change.
> On another note, I'm not sure that testNullCollation was ever testing what
> it was intended to.  It appears to be testing the the ordering of members
> with NULL ordinals correctly puts them at the end.  The [HQ] member in the
> test is set to have a null ordinal.  The query used in the test, however,
> uses a topcount function, and HQ does not fall into the topcount set.  So
> this would never actually validate that HQ was placed at the end.
>
>
>
>
> On Wed, Mar 18, 2009 at 7:39 AM, Matt Campbell <mkambol at gmail.com> wrote:
>
>> I had posted about the failed testTopCount last week and never heard a
>> response.  I think we should probably disable that test until high
>> cardinality functionality is fixed with top count (it currently only works
>> if native top count fails).  Here's the background: ----
>> The test appears to be intended to show that the HighCardinality code will
>> return the correct number of tuples when a TopCount function is used.  In
>> the definition of TopBottomCountFunDef, however, if a nativeEvaluator is
>> found, the expression will be evaluated with ResultStyle.LIST--which causes
>> it to use SqlTupleReader, rather than the HighCardSqlTupleReader.  So if
>> native top count actually is used, then the high cardinality code is not
>> executed.
>> This test formerly passed because it the queries it uses have redundant
>> set braces, which caused native evaluation to fail.  Running the same query
>> without the redundant set braces would have caused a test failure prior to
>> my change yesterday.
>>
>> Another problem appears to be that the ResultLimit property has two
>> different purposes in SqlTupleReader and HighCardSqlTupleReader.  In
>> SqlTupleReader if the results fetched exceeds the limit than an exception
>> will be thrown.  With HighCardSqlTupleReader, it seems to be used to set the
>> size of the internal LinkedList used for holding tuples, but will not throw
>> an exception.  Note that the Target class is the one that maintains this
>> LinkedList, it's used by HighCardSqlTupleReader.
>>
>> I'm looking for suggestions on the best way to address this.  It seems
>> like there probably should be a separate property for the HighCard version
>> of result limit.  It also seems like if it is intended to work with
>> TopCount, then it shouldn't be dependent on native evaluation failing.  The
>> test only accidentally passed before, since the set braces should be
>> unnecessary.
>>
>> 2009/3/18 Julian Hyde <jhyde at pentaho.com>
>>
>>>  Change 12424 also broke HighCardinalityTest.testTopCount:
>>>
>>> [java] 1)
>>> testTopCount(mondrian.rolap.HighDimensionsTest)mondrian.olap.ResourceLimitExceededException:
>>> Mondrian Error:Number of members to be read exceeded limit (40)
>>>
>>> [java] at
>>> mondrian.resource.MondrianResource$_Def10.ex(MondrianResource.java:991)
>>>
>>> [java] at
>>> mondrian.rolap.SqlTupleReader.prepareTuples(SqlTupleReader.java:428)
>>>
>>> [java] at
>>> mondrian.rolap.SqlTupleReader.readMembers(SqlTupleReader.java:498)
>>>
>>> [java] at
>>> mondrian.rolap.RolapNativeSet$SetEvaluator.executeList(RolapNativeSet.java:202)
>>>
>>> [java] at
>>> mondrian.rolap.RolapNativeSet$SetEvaluator.execute(RolapNativeSet.java:157)
>>>
>>> [java] at
>>> mondrian.olap.fun.TopBottomCountFunDef$3.evaluateList(TopBottomCountFunDef.java:83)
>>>
>>> [java] at
>>> mondrian.calc.impl.AbstractListCalc.evaluateMemberList(AbstractListCalc.java:92)
>>>
>>> [java] at
>>> mondrian.calc.impl.AbstractExpCompiler$MemberListIterCalc.evaluateMemberIterable(AbstractExpCompiler.java:544)
>>>
>>> [java] at
>>> mondrian.calc.impl.AbstractMemberIterCalc.evaluate(AbstractMemberIterCalc.java:55)
>>>
>>> [java] at mondrian.rolap.RolapResult.executeAxis(RolapResult.java:727)
>>>
>>> [java] at mondrian.rolap.RolapResult.evalLoad(RolapResult.java:578)
>>>
>>> [java] at mondrian.rolap.RolapResult.loadMembers(RolapResult.java:553)
>>>
>>> [java] at mondrian.rolap.RolapResult.<init>(RolapResult.java:269)
>>>
>>> [java] at
>>> mondrian.rolap.RolapConnection.execute(RolapConnection.java:560)
>>>
>>> [java] at
>>> mondrian.rolap.HighDimensionsTest.execHighCardTest(HighDimensionsTest.java:197)
>>>
>>> [java] at
>>> mondrian.rolap.HighDimensionsTest.testTopCount(HighDimensionsTest.java:124)
>>>
>>> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>
>>> [java] at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>
>>> [java] at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>
>>> [java] at
>>> mondrian.test.MondrianTestRunner$2.run(MondrianTestRunner.java:129)
>>>
>>> [java] at java.lang.Thread.run(Thread.java:619)
>>>
>>>  ------------------------------
>>> *From:* Julian Hyde [mailto:jhyde at pentaho.com] *On Behalf Of *Julian
>>> Hyde
>>> *Sent:* Tuesday, March 17, 2009 2:12 PM
>>> *To:* 'Matt Campbell'
>>> *Cc:* 'Mondrian developer mailing list'
>>> *Subject:* Change 12424
>>>
>>>  Matt,
>>>
>>> Change 12424 broke CompatibilityTest.testNullCollation on Oracle. Can you
>>> take a look please.
>>>
>>>
>>> [java] [0] .............F...
>>>
>>> [java] There was 1 failure:
>>>
>>> [java] 1)
>>> testNullCollation(mondrian.test.CompatibilityTest)junit.framework.ComparisonFailure:
>>> Expected:
>>>
>>> [java] Axis #0:
>>>
>>> [java] {}
>>>
>>> [java] Axis #1:
>>>
>>> [java] {[Measures].[Store Sqft]}
>>>
>>> [java] Axis #2:
>>>
>>> [java] {[Store].[All Stores].[Store 3]}
>>>
>>> [java] {[Store].[All Stores].[Store 18]}
>>>
>>> [java] {[Store].[All Stores].[Store 9]}
>>>
>>> [java] {[Store].[All Stores].[Store 10]}
>>>
>>> [java] {[Store].[All Stores].[Store 20]}
>>>
>>> [java] Row #0: 39,696
>>>
>>> [java] Row #1: 38,382
>>>
>>> [java] Row #2: 36,509
>>>
>>> [java] Row #3: 34,791
>>>
>>> [java] Row #4: 34,452
>>>
>>> [java]
>>>
>>> [java] Actual:
>>>
>>> [java] Axis #0:
>>>
>>> [java] {}
>>>
>>> [java] Axis #1:
>>>
>>> [java] {[Measures].[Store Sqft]}
>>>
>>> [java] Axis #2:
>>>
>>> [java]
>>>
>>> [java] Actual java:
>>>
>>> [java] fold(
>>>
>>> [java] "Axis #0:\n" +
>>>
>>> [java] "{}\n" +
>>>
>>> [java] "Axis #1:\n" +
>>>
>>> [java] "{[Measures].[Store Sqft]}\n" +
>>>
>>> [java] "Axis #2:\n")
>>>
>>> [java] expected:<...ore Sqft]}
>>>
>>> [java] Axis #2:
>>>
>>> [java] [{[Store].[All Stores].[Store 3]}
>>>
>>> [java] {[Store].[All Stores].[Store 18]}
>>>
>>> [java] {[Store].[All Stores].[Store 9]}
>>>
>>> [java] {[Store].[All Stores].[Store 10]}
>>>
>>> [java] {[Store].[All Stores].[Store 20]}
>>>
>>> [java] Row #0: 39,696
>>>
>>> [java] Row #1: 38,382
>>>
>>> [java] Row #2: 36,509
>>>
>>> [java] Row #3: 34,791
>>>
>>> [java] Row #4: 34,452
>>>
>>> [java] ]> but was:<...ore Sqft]}
>>>
>>> [java] Axis #2:
>>>
>>> [java] []>
>>>
>>> [java] at
>>> mondrian.test.TestContext.assertEqualsVerbose(TestContext.java:881)
>>>
>>> [java] at
>>> mondrian.test.TestContext.assertEqualsVerbose(TestContext.java:849)
>>>
>>> [java] at
>>> mondrian.test.TestContext.assertQueryReturns(TestContext.java:818)
>>>
>>> [java] at
>>> mondrian.test.CompatibilityTest.testNullCollation(CompatibilityTest.java:381)
>>>
>>> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>
>>> [java] at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>
>>> [java] at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>
>>> [java] at
>>> mondrian.test.MondrianTestRunner$2.run(MondrianTestRunner.java:129)
>>>
>>> [java] at java.lang.Thread.run(Thread.java:619)
>>>
>>>
>>>
>>>
>>>
>>> Julian
>>>
>>>
>>> _______________________________________________
>>> Mondrian mailing list
>>> Mondrian at pentaho.org
>>> http://lists.pentaho.org/mailman/listinfo/mondrian
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20090318/e3130470/attachment.html 


More information about the Mondrian mailing list