[Mondrian] MEMBER_ORDINAL: fubar when combined with native filtering?

[John V. Sichi]

Julian Hyde wrote:
> John,
> 
> 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
> RC1.

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 
ordinalColumn:

"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?

JVS