[Mondrian] ClassCastException w/ null members

Julian Hyde jhyde at pentaho.com
Wed Sep 18 14:24:09 EDT 2013

I agree, http://jira.pentaho.com/browse/MONDRIAN-1610 is important. The cause is that calc members have string keys whereas regular members have keys depending on their level, typically ints and often composite.

I would fix it if I could think of an efficient and maintainable solution. The simple fix is to add an 'if (... instanceof ...)' but sorting is performance-critical so we can't afford to do that.

Maybe the trick is to ensure that calc members have the same key type as the regular members. But we'd need to deal with the fact there might be duplicate keys. (To focus the mind: imagine that a level is based on a boolean column and has two members with keys false and true, plus a calc member.)


On Sep 18, 2013, at 5:18 AM, Matt Campbell <mcampbell at pentaho.com<mailto:mcampbell at pentaho.com>> wrote:

Moving Tom's discussion to a better list :).

Whilst we're talking wish list stuff(although technically the wrong list), MONDRIAN-1610 could do with being looked at as I've hit the problem in both my pubs demo and my solr driver. Because the documents don't always have every field  as they don't necessarily follow a strict DWH type idiom, Mondrian blows up pretty often.

Agreed, I think that one's important and something we'll hit all over the place.  I hadn't noticed you had already logged this issue and created the duplicate MONDRIAN-1711<http://jira.pentaho.com/browse/MONDRIAN-1711> a few days ago.
Mondrian mailing list
Mondrian at pentaho.org<mailto:Mondrian at pentaho.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20130918/4497e044/attachment-0001.html 

More information about the Mondrian mailing list