[Mondrian] ClassCastException w/ null members

Luc Boudreau lucboudreau at gmail.com
Wed Sep 18 15:30:22 EDT 2013


In an ideal world, I'd like all members of an attribute to be able to
compare to any other attribute in the context of a given hierarchy. That's
the core problem here.

What you propose, namely cheating with keys by placing 'undetermined' keys
at the end won't help with performance-driven requirements. As you
mentioned, the trick is to keep the algorithm simple enough so that a CPU
can effectively process the sort operation. To do that inside of the
regular Java APIs, we must stick to primitive types, like int or long and
such. But lo and behold, there is a disconnect here. In OLAP, a boolean or
an integer can be null, thus wrecking havok (with a k because it gets
really nasty).

That's why I say that trivial java APIs won't be of help. I've seen enough
ClassCastException to last me a lifetime at this point and I'd rather we
get this out of the way for good.

I'm also having problems figuring out how to fit parent-child attributes in
this. We know that parent-child relations between attributes must be
promoted to first class concepts in Mondrian in a somewhat near future. Add
to that our discussions about consolidating the cells vs. members
representation. With that in mind, the 'wider' approach becomes more
important for us to keep up with all the goodness coming up. It feels that
finding an efficient way to deal with member keys and how they are
processed within both the context of the core metadata and an ad-hoc query
will be key to all future developments.


On Wed, Sep 18, 2013 at 3:04 PM, Julian Hyde <jhyde at pentaho.com> wrote:

> On Sep 18, 2013, at 11:39 AM, Luc Boudreau <lucboudreau at gmail.com> wrote:
>
> > I don't think that we'll resolve this problem with trivial java
> constructs.
>
> You might be right. However, non-trivial constructs (e.g. comparators with
> 'if's or virtual methods) don't perform as well as trivial constructs
> because CPUs like things to be simple.
>
> Suppose that we force calc members to have the same key structure as
> regular members of that level, and give them a key value so that they
> collate last (perhaps equal to the last regular member). Could that work?
>
> 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/20130918/f1bd7f75/attachment.html 


More information about the Mondrian mailing list