[Mondrian] MEMBER_ORDINAL: fubar when combined with native filtering?
John V. Sichi
jsichi at gmail.com
Wed Feb 21 05:31:31 EST 2007
Julian Hyde wrote:
> This change sounds like an improvement. If you can check in the change in
> the next day or so (disabled by default) I will run it through the full
> regression suite. If nothing seems broken, I will enable this change for
OK, I'm hoping to be able to check in soon. I ran into one snag so far
testing with Derby: the Customers table has fullname used for both Name
and Ordinal, and if I reference it twice in the select list, Derby
complains. And it complains in a different way if I try generating
aliases. None of the complaints are reasonable by SQL:2003 standards, so...
I downloaded the latest Derby (10.2.2.0) and the complaints are gone.
Assuming it passes all tests, is it OK to upgrade the checked-in version
(10.1)? Browsing the release notes for the last few revs, it looks like
they've added enhancements for GROUP BY expression and some ORDER BY
fixes. (The GROUP BY expression enhancement should allow FoodMart.xml
to be changed to use an expression for Name, but that can wait.)
> Please update schema.html to match the new semantics. I will back out
Just to clarify, I haven't actually added a new orderKey attribute to
the schema; I'm just changing what we do with the values produced by the
existing ordinalColumn/OrdinalExpression attribute. So what I will
document is that (when the new property is enabled):
- the ordinal column/expression can be of any datatype, but the JDBC
driver must return non-null objects which implement Comparable
- the values need only be unique with respect to the parent
Note that the current Mondrian.xml schema spec says this about
"The name of the column which holds member ordinals. Only applicable for
the last level in a hierarchy. If this column is not specified, the
hierarchy cannot be implemented in ROLAP mode."
The last two sentences are both false, right?
More information about the Mondrian