Package mondrian.olap.fun

Class CrossJoinFunDef

  • All Implemented Interfaces:
    FunDef
    Direct Known Subclasses:
    NonEmptyCrossJoinFunDef
    public class CrossJoinFunDef
extends FunDefBase
    Definition of the CrossJoin MDX function.
    Since:
    Mar 23, 2006
    Author:
    jhyde

    • Constructor Detail

      • CrossJoinFunDef

        public CrossJoinFunDef​(FunDef dummyFunDef)

    • Method Detail

      • getResultType

        public Type getResultType​(Validator validator,
                          Exp[] args)
        Description copied from class: FunDefBase
        Returns the type of a call to this function with a given set of arguments.

        The default implementation makes the coarse assumption that the return type is in some way related to the type of the first argument. Operators whose arguments don't follow the requirements of this implementation should override this method.

        If the function definition says it returns a literal type (numeric, string, symbol) then it's a fair guess that the function call returns the same kind of value.

        If the function definition says it returns an object type (cube, dimension, hierarchy, level, member) then we check the first argument of the function. Suppose that the function definition says that it returns a hierarchy, and the first argument of the function happens to be a member. Then it's reasonable to assume that this function returns a member.

        Overrides:
        getResultType in class FunDefBase
        Parameters:
        validator - Validator
        args - Arguments to the call to this operator
        Returns:
        result type of a call this function

      • compileCall

        public Calc compileCall​(ResolvedFunCall call,
                        ExpCompiler compiler)
        Description copied from interface: FunDef
        Converts a call to this function into executable objects.

        The result must implement the appropriate interface for the result type. For example, a function which returns an integer must return an object which implements IntegerCalc.

        Specified by:
        compileCall in interface FunDef
        Overrides:
        compileCall in class FunDefBase

      • nonEmptyList

        protected TupleList nonEmptyList​(Evaluator evaluator,
                                 TupleList list,
                                 ResolvedFunCall call)
        This is the entry point to the crossjoin non-empty optimizer code.

        What one wants to determine is for each individual Member of the input parameter list, a 'List-Member', whether across a slice there is any data.

        But what data?

        For Members other than those in the list, the 'non-List-Members', one wants to consider all data across the scope of these other Members. For instance, if Time is not a List-Member, then one wants to consider data across All Time. Or, if Customer is not a List-Member, then look at data across All Customers. The theory here, is if there is no data for a particular Member of the list where all other Members not part of the list are span their complete hierarchy, then there is certainly no data for Members of that Hierarchy at a more specific Level (more on this below).

        When a Member that is a non-List-Member is part of a Hierarchy that has an All Member (hasAll="true"), then its very easy to make sure that the All Member is used during the optimization. If a non-List-Member is part of a Hierarchy that does not have an All Member, then one must, in fact, iterate over all top-level Members of the Hierarchy!!! - otherwise a List-Member might be excluded because the optimization code was not looking everywhere.

        Concerning default Members for those Hierarchies for the non-List-Members, ignore them. What is wanted is either the All Member or one must iterate across all top-level Members, what happens to be the default Member of the Hierarchy is of no relevant.

        The Measures Hierarchy has special considerations. First, there is no All Measure. But, certainly one need only involve Measures that are actually in the query... yes and no. For Calculated Measures one must also get all of the non-Calculated Measures that make up each Calculated Measure. Thus, one ends up iterating across all Calculated and non-Calculated Measures that are explicitly mentioned in the query as well as all Calculated and non-Calculated Measures that are used to define the Calculated Measures in the query. Why all of these? because this represents the total scope of possible Measures that might yield a non-null value for the List-Members and that is what we what to find. It might be a super set, but thats ok; we just do not want to miss anything.

        For other Members, the default Member is used, but for Measures one should look for that data for all Measures associated with the query, not just one Measure. For a dense dataset this may not be a problem or even apparent, but for a sparse dataset, the first Measure may, in fact, have not data but other Measures associated with the query might. Hence, the solution here is to identify all Measures associated with the query and then for each Member of the list, determine if there is any data iterating across all Measures until non-null data is found or the end of the Measures is reached.

        This is a non-optimistic implementation. This means that an element of the input parameter List is only not included in the returned result List if for no combination of Measures, non-All Members (for Hierarchies that have no All Members) and evaluator default Members did the element evaluate to non-null.

        Parameters:
        evaluator - Evaluator
        list - List of members or tuples
        call - Calling ResolvedFunCall used to determine what Measures to use
        Returns:
        List of elements from the input parameter list that have evaluated to non-null.