[prev in list] [next in list] [prev in thread] [next in thread]
List: mondrian
Subject: Re: [Mondrian] ClassCastException w/ null members
From: Luc Boudreau <lucboudreau () gmail ! com>
Date: 2013-09-18 19:30:22
Message-ID: CAKTEAx-gXKDes7jHMsK1D_2gcFx69i5UWVFdPsm1W+kedj7Hvg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@pentaho.com> wrote:
> On Sep 18, 2013, at 11:39 AM, Luc Boudreau <lucboudreau@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@pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>
[Attachment #5 (text/html)]
<div dir="ltr">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. <div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><div><br></div><div>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. </div>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 18, \
2013 at 3:04 PM, Julian Hyde <span dir="ltr"><<a href="mailto:jhyde@pentaho.com" \
target="_blank">jhyde@pentaho.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="im">On Sep 18, 2013, at 11:39 AM, Luc Boudreau \
<<a href="mailto:lucboudreau@gmail.com">lucboudreau@gmail.com</a>> wrote:<br>
<br>
> I don't think that we'll resolve this problem with trivial java \
constructs.<br> <br>
</div>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.<br> <br>
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?<br> <span class="HOEnZb"><font \
color="#888888"><br> Julian<br>
</font></span><div class="HOEnZb"><div \
class="h5">_______________________________________________<br> Mondrian mailing \
list<br> <a href="mailto:Mondrian@pentaho.org">Mondrian@pentaho.org</a><br>
<a href="http://lists.pentaho.org/mailman/listinfo/mondrian" \
target="_blank">http://lists.pentaho.org/mailman/listinfo/mondrian</a><br> \
</div></div></blockquote></div><br></div>
_______________________________________________
Mondrian mailing list
Mondrian@pentaho.org
http://lists.pentaho.org/mailman/listinfo/mondrian
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic