|
|||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object org.eigenbase.xom.XMLUtil org.eigenbase.xom.XOMUtil mondrian.olap.Util mondrian.olap.fun.FunUtil mondrian.olap.fun.FunDefBase mondrian.olap.fun.CrossJoinFunDef
public class CrossJoinFunDef
Definition of the CrossJoin
MDX function.
Nested classes/interfaces inherited from class mondrian.olap.fun.FunUtil |
---|
FunUtil.SetWrapper |
Nested classes/interfaces inherited from class mondrian.olap.Util |
---|
Util.ErrorCellValue, Util.PropertyList |
Field Summary | |
---|---|
(package private) static ReflectiveMultiResolver |
Resolver
|
(package private) static mondrian.olap.fun.CrossJoinFunDef.StarCrossJoinResolver |
StarResolver
|
Fields inherited from class mondrian.olap.fun.FunDefBase |
---|
flags, parameterCategories, returnCategory, signature |
Fields inherited from class mondrian.olap.fun.FunUtil |
---|
BooleanNull, DoubleEmpty, DoubleNull, emptyStringArray, IntegerNull, NullMember |
Fields inherited from class mondrian.olap.Util |
---|
EmptyValue, JdbcVersion, nl, nullValue, PreJdk15, Retrowoven |
Constructor Summary | |
---|---|
CrossJoinFunDef(FunDef dummyFunDef)
|
Method Summary | ||
---|---|---|
Calc |
compileCall(ResolvedFunCall call,
ExpCompiler compiler)
Converts a call to this function into executable objects. |
|
protected ListCalc |
compileCallImmutableList(ResolvedFunCall call,
ExpCompiler compiler)
|
|
protected IterCalc |
compileCallIterable(ResolvedFunCall call,
ExpCompiler compiler)
|
|
protected ListCalc |
compileCallMutableList(ResolvedFunCall call,
ExpCompiler compiler)
|
|
static List<Member[]> |
crossJoin(List list1,
List list2)
|
|
Type |
getResultType(Validator validator,
Exp[] args)
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. |
|
protected
|
nonEmptyList(Evaluator evaluator,
List<T> list,
ResolvedFunCall call)
This is the entry point to the crossjoin non-empty optimizer code. |
|
protected List |
nonEmptyOptimizeList(Evaluator evaluator,
List list,
ResolvedFunCall call)
|
Methods inherited from class mondrian.olap.fun.FunDefBase |
---|
castType, createCall, getDescription, getName, getParameterCategories, getReturnCategory, getSignature, getSyntax, unparse, validateArg |
Methods inherited from class org.eigenbase.xom.XOMUtil |
---|
addAll, addAll, addChild, addChild, addChildren, addElement, concatenate, createDefaultParser, discard, discard, discard, discard, discard, discard, discard, discard, discard, getFirstInstance, toList, toVector, wrapperToXml |
Methods inherited from class org.eigenbase.xom.XMLUtil |
---|
getFirstTagName, printAtt, printAtt, printAtt, printAtt, printPCDATA, printPCDATA, printPCDATA, quoteAtt, quoteAtt, quoteAtt, quoteAtt, quotePCDATA, stringEncodeXML, stringHasXMLSpecials |
Methods inherited from class java.lang.Object |
---|
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
Field Detail |
---|
static final ReflectiveMultiResolver Resolver
static final mondrian.olap.fun.CrossJoinFunDef.StarCrossJoinResolver StarResolver
Constructor Detail |
---|
public CrossJoinFunDef(FunDef dummyFunDef)
Method Detail |
---|
public Type getResultType(Validator validator, Exp[] args)
FunDefBase
getResultType
in class FunDefBase
validator
- Validatorargs
- Arguments to the call to this operator
public Calc compileCall(ResolvedFunCall call, ExpCompiler compiler)
FunDef
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
.
compileCall
in interface FunDef
compileCall
in class FunDefBase
protected IterCalc compileCallIterable(ResolvedFunCall call, ExpCompiler compiler)
protected ListCalc compileCallImmutableList(ResolvedFunCall call, ExpCompiler compiler)
protected ListCalc compileCallMutableList(ResolvedFunCall call, ExpCompiler compiler)
protected List nonEmptyOptimizeList(Evaluator evaluator, List list, ResolvedFunCall call)
public static List<Member[]> crossJoin(List list1, List list2)
protected <T> List<T> nonEmptyList(Evaluator evaluator, List<T> list, ResolvedFunCall call)
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.
This method can be applied to members or tuples. Accordingly, the
type parameter T
can be either Member
or
Member[]
.
evaluator
- Evaluatorlist
- List of members or tuplescall
- Calling ResolvedFunCall used to determine what Measures
to use
|
|||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |