[Mondrian] ClassCastException w/ null members

Paul Stoellberger p.stoellberger at gmail.com
Thu Nov 14 16:55:57 EST 2013


Is there any news on this?

I just did some more tests with saiku on mondrian 4 but ran into the issue as well.
Seems like its a blocker for using M4.

-Paul


On Sep 18, 2013, at 9:30 PM, Luc Boudreau wrote:

> 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
> 
> _______________________________________________
> 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/20131114/75bfb165/attachment.html 


More information about the Mondrian mailing list