[Mondrian] NamedSet, StrToSet, work arounds

Charlie Hubbard charlie at fuseanalytics.com
Wed Jul 19 14:00:15 EDT 2017


Thanks Julian but when you say this it doesn't leave me hopeful. :-/

First the SetType looks like it does allows a null elementType value except
for getArity() call.  All other calls protect themselves from elementType==
null.  So if that was changed do something like:

int getArity() {
   return elementType != null ? elementType.getArity() : -1;
}

Then that could signify to compilation code that I can't tell you this
right now so deal with it.  I have been through the code, and looked at
Type.getArity() calls.  There are a few that could be moved from
compilation to eval time without real impact.  Others might take work to do
that.  Some calls I was able to refactor them a bit so they could perform
their compilation duties if that calls returns a positive number otherwise
they are delayed until query time.  That way you get the best of both
worlds.  I suspect that strategy could fix all cases of this across the
functions.

There might even be a fancier way of handling knowing right now vs delaying
transparently using something like a promise, but that may be too "smart."
 But the idea is that the promise would call you back the moment it has
enough information to evaluate itself.  That could be immediately during
compilation or wait until query time.  And this would handle any situation
not just for getArity().

I think if some changes like this were made then it could be easier to make
StrToSet work as the standard version does because effectively evaluating
that expression is delaying things till query time.

Thoughts?

Charlie


On Wed, Jul 19, 2017 at 12:44 PM, Julian Hyde <julianhyde at gmail.com> wrote:

> I don’t have any concrete suggestions but I feel your pain.
>
> Mondrian tries very hard to figure out the dimensionality of each
> expression at prepare time. It exploits that type information to generate
> more efficient code. But situations where the type cannot be known at
> prepare time are not well supported.
>
> I don’t recall why named sets in the schema are treated differently (from
> a type-checking perspective) from named sets in a query. If there is no
> inherent reason for this maybe you can improve how Mondrian derives the
> dimensionality of a schema named set when it is used in a query.
>
> Julian
>
> On Jul 18, 2017, at 1:33 PM, Charlie Hubbard <charlie at fuseanalytics.com>
> wrote:
>
> So I have a NameSet that is defined at the query scope, but I have
> CalculatedMeasures that are defined in the schema that I'd like to refer to
> that NamedSet.  The reason the NamedSet is defined outside of the schema is
> because the user can alter it.  If I define both NamedSet and Calculated
> Measures at query scope then my query works fine.
>
> So I tried to use StrToSet to work around this doing something like:
>
> StrToSet("[MyNamedSet]", [Date].[YearQuarterMonth])
>
> But that doesn't work as I get an error:
>
> Member [MyNamedSet] cannot be found.
>
> After digging through the code in StrToSet() it assumes that the string
> contains a member/tuple of the hierarchies provided in the 2nd+ arguments.
> This would work fine in Microsoft SAAS as it treats the StrToSet as a
> dynamic expression that results in a Set.  StrToSet in Mondrian is much
> more limited.
>
> So I decided I'd try and write a UDF that let's me provide the name of a
> NamedSet and it returns the NamedSet to work around Mondrian trying to
> resolve the NamedSet at schema load time.
>
> Set asNamedSet("[MyNamedSet]")
>
> However, Mondrian doesn't offer any way for a UDF, or FunDef for that
> matter, to lookup NamedSets through the Evaulator.  After using some
> reflection to break into Query.scopedNamedSets I could get the NamedSet by
> name.  After that my query failed because some eager compliation logic.
> For example doing this:
>
> asNamedSet("[MyNamedSet]").Item(0).Hierarchy
>
> Blows up because when the schema is loaded it tries to check the arity of
> the SetType and the parameters it's passed.  If that was done closer to
> query execution it'd be fine.
>
> So my question is how can I do this in Mondrian?  I'd like to delay
> expressions to be more late which I think is possible in most cases.  It
> just seems like I'm blocked at every point.
>
> I'm using Mondrian 4.3.
>
> Charlie
>
> --
> Charlie Hubbard | Chief Technology Officer
> Fuse Analytics  | 404.234.8094 <(404)%20234-8094>
> _______________________________________________
> 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
>
>


-- 
Charlie Hubbard | Chief Technology Officer
Fuse Analytics  | 404.234.8094
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20170719/18fc416b/attachment-0001.html 


More information about the Mondrian mailing list