[prev in list] [next in list] [prev in thread] [next in thread]
List: mondrian
Subject: Re: [Mondrian] when iif has a tuple and a member as its arguments
From: "Matt Campbell" <mkambol () gmail ! com>
Date: 2008-01-31 17:05:35
Message-ID: 5bea6e60801310905h6a090378l42fd660db1d62adf () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Julian,
Harun is working on Ajit's team. Would it be okay if they check in the
change he suggested? They wanted to get some confirmation that their
solution was correct.
-matt
On Jan 31, 2008 11:38 AM, Julian Hyde <jhyde@pentaho.org> wrote:
> Thanks. Logged as bug 1883611
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1883611&group_id=35
> 302&atid=414613 for tracking. Will fix in 3.0.
>
> Julian
>
> > -----Original Message-----
> > From: mondrian-bounces@pentaho.org
> > [mailto:mondrian-bounces@pentaho.org] On Behalf Of Harun Pathan
> > Sent: Thursday, January 31, 2008 6:54 AM
> > To: mondrian@pentaho.org
> > Subject: [Mondrian] when iif has a tuple and a member as its
> > arguments weget an exception
> >
> > Hi,
> >
> > When we run this mdx we get an error stacktrace for which is as below.
> >
> > WITH
> > MEMBER [Gender].agg
> > AS 'IIF(1=1, ([Gender].[All Gender],measures.[unit
> > sales]),([Gender].[All Gender]) )', SOLVE_ORDER = 4
> > SELECT {[Measures].[unit sales]} ON 0,
> > {{[Gender].[Gender].MEMBERS},{([Gender].agg)}} on 1 FROM sales
> >
> > Caused by: mondrian.olap.MondrianException: Mondrian Error:Internal
> > error: could not derive type
> > at
> > mondrian.resource.MondrianResource$_Def0.ex(MondrianResource.java:777)
> > at mondrian.olap.Util.newInternal(Util.java:1333)
> > at mondrian.olap.fun.FunDefBase.createCall(FunDefBase.java:245)
> > at
> > mondrian.mdx.UnresolvedFunCall.accept(UnresolvedFunCall.java:101)
> > at mondrian.olap.Query$StackValidator.validate(Query.java:1229)
> > at mondrian.olap.Formula.accept(Formula.java:131)
> > at mondrian.olap.Query$StackValidator.validate(Query.java:1304)
> > at mondrian.olap.Query.resolve(Query.java:571)
> > at mondrian.olap.Query.resolve(Query.java:433)
> > at mondrian.olap.Query.<init>(Query.java:217)
> > at mondrian.olap.Query.<init>(Query.java:177)
> > at mondrian.olap.Parser.makeQuery(Parser.java:850)
> > at
> > mondrian.olap.CUP$Parser$actions.CUP$Parser$do_action(Parser.j
> > ava:1683)
> > at mondrian.olap.Parser.do_action(Parser.java:684)
> > at java_cup.runtime.lr_parser.parse(lr_parser.java:569)
> > at mondrian.olap.Parser.parseInternal(Parser.java:754)
> >
> > What we saw is that when the iif function is resolved it tries to get
> > a common result type between its arguments.There is no common
> > resulttype between a TupleType and a MemberType.
> > Currently in the TupleType the result type gets resolved to a
> > ScalarType when the other type is a ScalarType and to a TupleType when
> > the other one is a Tuple and in all other cases null.
> > Currently in the MemberType the result type gets resolved to null for
> > the above example when the incoming tuple has more than one argument
> > in it.
> > is it valid if the return type is resolved to a ScalarType when the
> > IIF gets a TupleType and MemberType as its arguments.
> >
> > Code changes in TupleType :
> > //currently this check isnt there.
> > if (type instanceof MemberType) {
> > return getValueType().computeCommonType(type,
> > conversionCount);
> > }
> >
> > Code changes in MemberType:
> >
> > if (type instanceof TupleType) {
> > TupleType tupleType = (TupleType) type;
> > if (tupleType.elementTypes.length == 1) {
> > return new TupleType(new Type[]
> > {type}).computeCommonType(tupleType, conversionCount);
> > } else {
> > return
> > computeCommonType(tupleType.getValueType(),conversionCount);// this is
> > the code change, earlier returned null
> > }
> > }
> > _______________________________________________
> > Mondrian mailing list
> > Mondrian@pentaho.org
> > http://lists.pentaho.org/mailman/listinfo/mondrian
> >
>
> _______________________________________________
> Mondrian mailing list
> Mondrian@pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>
[Attachment #5 (text/html)]
Julian,<br>Harun is working on Ajit's team. Would it be okay if they check \
in the change he suggested? They wanted to get some confirmation that their \
solution was correct.<br>-matt<br><br><div class="gmail_quote">On Jan 31, 2008 11:38 \
AM, Julian Hyde <<a href="mailto:jhyde@pentaho.org">jhyde@pentaho.org</a>> \
wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Thanks. Logged as bug \
1883611<br><a href="http://sourceforge.net/tracker/index.php?func=detail&aid=1883611&group_id=35302&atid=414613" \
target="_blank">http://sourceforge.net/tracker/index.php?func=detail&aid=1883611&group_id=35<br>
302&atid=414613</a> for tracking. Will fix in 3.0.<br><font \
color="#888888"><br>Julian<br></font><div><div></div><div class="Wj3C7c"><br>> \
-----Original Message-----<br>> From: <a \
href="mailto:mondrian-bounces@pentaho.org">mondrian-bounces@pentaho.org</a><br> > \
[mailto:<a href="mailto:mondrian-bounces@pentaho.org">mondrian-bounces@pentaho.org</a>] \
On Behalf Of Harun Pathan<br>> Sent: Thursday, January 31, 2008 6:54 AM<br>> \
To: <a href="mailto:mondrian@pentaho.org">mondrian@pentaho.org</a><br> > Subject: \
[Mondrian] when iif has a tuple and a member as its<br>> arguments weget an \
exception<br>><br>> Hi,<br>><br>> When we run this mdx we get an error \
stacktrace for which is as below.<br>><br> > WITH<br>> MEMBER \
[Gender].agg<br>> AS 'IIF(1=1, ([Gender].[All Gender],measures.[unit<br>> \
sales]),([Gender].[All Gender]) )', SOLVE_ORDER = 4<br>> SELECT \
{[Measures].[unit sales]} ON 0,<br>> \
{{[Gender].[Gender].MEMBERS},{([Gender].agg)}} on 1 FROM sales<br> ><br>> \
Caused by: mondrian.olap.MondrianException: Mondrian Error:Internal<br>> error: \
could not derive type<br>> at<br>> \
mondrian.resource.MondrianResource$_Def0.ex(MondrianResource.java:777)<br>> \
at mondrian.olap.Util.newInternal(Util.java:1333)<br> > \
at mondrian.olap.fun.FunDefBase.createCall(FunDefBase.java:245)<br>> \
at<br>> \
mondrian.mdx.UnresolvedFunCall.accept(UnresolvedFunCall.java:101)<br>> \
at mondrian.olap.Query$StackValidator.validate(Query.java:1229)<br> \
> at mondrian.olap.Formula.accept(Formula.java:131)<br>> \
at \
mondrian.olap.Query$StackValidator.validate(Query.java:1304)<br>> \
at mondrian.olap.Query.resolve(Query.java:571)<br>> at \
mondrian.olap.Query.resolve(Query.java:433)<br> > at \
mondrian.olap.Query.<init>(Query.java:217)<br>> at \
mondrian.olap.Query.<init>(Query.java:177)<br>> at \
mondrian.olap.Parser.makeQuery(Parser.java:850)<br>> \
at<br>> mondrian.olap.CUP$Parser$actions.CUP$Parser$do_action(Parser.j<br> > \
ava:1683)<br>> at \
mondrian.olap.Parser.do_action(Parser.java:684)<br>> at \
java_cup.runtime.lr_parser.parse(lr_parser.java:569)<br>> at \
mondrian.olap.Parser.parseInternal(Parser.java:754)<br> ><br>> What we saw is \
that when the iif function is resolved it tries to get<br>> a common result type \
between its arguments.There is no common<br>> resulttype between a TupleType and a \
MemberType.<br>> Currently in the TupleType the result type gets resolved to a<br> \
> ScalarType when the other type is a ScalarType and to a TupleType when<br>> \
the other one is a Tuple and in all other cases null.<br>> Currently in the \
MemberType the result type gets resolved to null for<br>> the above example when \
the incoming tuple has more than one argument<br> > in it.<br>> is it valid if \
the return type is resolved to a ScalarType when the<br>> IIF gets a TupleType and \
MemberType as its arguments.<br>><br>> Code changes in TupleType :<br>> \
//currently this check isnt there.<br> > if (type instanceof MemberType) {<br>> \
return \
getValueType().computeCommonType(type,<br>> conversionCount);<br>> \
}<br>><br>> Code changes in MemberType:<br>><br>> if (type instanceof \
TupleType) {<br> > TupleType tupleType = (TupleType) \
type;<br>> if (tupleType.elementTypes.length == 1) \
{<br>> return new \
TupleType(new Type[]<br>> {type}).computeCommonType(tupleType, \
conversionCount);<br> > } else {<br>> \
return<br>> \
computeCommonType(tupleType.getValueType(),conversionCount);// this is<br>> the \
code change, earlier returned null<br>> \
}<br>> }<br>> _______________________________________________<br> > \
Mondrian mailing list<br>> <a \
href="mailto:Mondrian@pentaho.org">Mondrian@pentaho.org</a><br>> <a \
href="http://lists.pentaho.org/mailman/listinfo/mondrian" \
target="_blank">http://lists.pentaho.org/mailman/listinfo/mondrian</a><br> \
><br><br>_______________________________________________<br>Mondrian mailing \
list<br><a href="mailto:Mondrian@pentaho.org">Mondrian@pentaho.org</a><br><a \
href="http://lists.pentaho.org/mailman/listinfo/mondrian" \
target="_blank">http://lists.pentaho.org/mailman/listinfo/mondrian</a><br> \
</div></div></blockquote></div><br>
_______________________________________________
Mondrian mailing list
Mondrian@pentaho.org
http://lists.pentaho.org/mailman/listinfo/mondrian
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic