PDA

View Full Version : [Mondrian] RE: Generic IIF implementation for your review



Julian Hyde
04-12-2007, 01:51 PM
I'm not against introducing variant values into mondrian, but the impact
of this change might be insidious, because we're blowing a hole in the
strong typing system. Once a variant is introduced, it needs to work
correctly in any expression.

Consider these examples:

1. Iif(1 = 1, 2, 3) + 4

2. Iif(1 = 1, "Foo", 3) + 4

In each case, what do you expect to happen, and what actually happens?

#1 currently type-checks as an integer expression, but after your change
it will be <variant> + <int>, and I'm not sure how that gets
type-checked or evaluated.

#2 currently gives a compile-time exception, which can be fixed using
casts:

Iif(1 = 1, "Foo", Cast(3 as string)) + Cast(4 as string)

So, a simpler solution might be to fix the type inference/validation of
the Iif function. Require the arguments to be of the same type (using
'cast' if necessary), make sure that we give a useful error message if
the arguments are of incompatible types, and make Iif return the same
type as its 2nd and 3rd arguments.

Note that everything which applies to Iif probably applies to CASE also.

Julian

PS Please send future emails to the mondrian dev list unless they
contain proprietary/sensitive material.



_____

From: Thiyagu Palanisamy [mailto:tpalanis (AT) thoughtworks (DOT) com]
Sent: Tuesday, April 10, 2007 6:39 AM
To: julianhyde (AT) speakeasy (DOT) net
Cc: Matthew.Campbell (AT) thomson (DOT) com; Ajit Vasudeo Joglekar;
RenoMondrian (AT) thoughtworks (DOT) com
Subject: Generic IIF implementation for your review



Hi Julian,

We have come up with a solution to make IIf MDX function to take
(boolean, variant, variant) and return a (variant) similar to MSAS so as
to avoid all permutations and combinations of parameter types and
different return types decided at run time.

We realized that currently there is no support for BasicType or AnyType
or VariantType that we can readily use. We were looking for late binding
support rather than the current early binding (compilation) that takes
place. We initially thought of a base class to all the specific Type
classes but realized that there could be substantial changes and still
no guarantee of making it work. Then we thought of adding just another
Type (VariantType) and providing special handling for it where ever
required.

We have been able to successfully run all tests with this generic IIf.

We have attached the zip file containing all the modified files. Files
are based on revision no : 9071 (Couldn't get packChange to work in our
machine)

Extracting the attached archive in /home/open will copy and replace the
modified files.




We have not checked in into perforce because of few fundamental changes
that we feel should be reviewed first. Could you please review this?

Thanks & Regards,
Ajit &Thiyagu - Pairing



_______________________________________________
Mondrian mailing list
Mondrian (AT) pentaho (DOT) org
http://lists.pentaho.org/mailman/listinfo/mondrian

Haridasan T
04-14-2007, 01:51 PM
Not able to flush Cache.



Giving error
javax.servlet.ServletException: javax.servlet.jsp.JspException: Unable to
compile class for JSP An error occurred at line: 10 in the jsp file:
/WEB-INF/queries/ar.jsp Generated servlet error:
mondrian.rolap.CachePoolcannot be resolved to a type

javax.servlet.ServletException: javax.servlet.jsp.JspException: Unable
to compile class for JSP

An error occurred at line: 10 in the jsp file: /WEB-INF/queries/ar.jsp
Generated servlet error:mondrian.rolap.CachePool cannot be resolved to a type

---

se code below

---

<%@ page import="mondrian.olap.*;" %>

<%@ page session="true" contentType="text/html; charset=ISO-8859-1" %>

<%@ taglib uri="http://www.tonbeller.com/jpivot" prefix="jp" %>

<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>







<%

mondrian.rolap.CachePool.flush();

%>



<jp:mondrianQuery id="query01" jdbcDriver="oracle.jdbc.driver.OracleDriver"
jdbcUrl="jdbc:oracle:thin:@localhost:1521:XE " jdbcUser="ABCD"
jdbcPassword="ABCD"

catalogUri="/WEB-INF/queries/ar.xml">





select {
[Measures].[Outstanding],[Measures].[Days_60],[Measures].[Days_90],[Measures].[Days_120],[Measures].[Over_120]}
on columns,NON EMPTY

{([Country].[All country],[Location].[All location],[Area].[All
area],[Customer].[All customer])} on rows

from ar

</jp:mondrianQuery>

<c:set var="title01" scope="session">TEST-2s </c:set>






On 4/12/07, Julian Hyde <julianhyde (AT) speakeasy (DOT) net> wrote:
>
> I'm not against introducing variant values into mondrian, but the impact
> of this change might be insidious, because we're blowing a hole in the
> strong typing system. Once a variant is introduced, it needs to work
> correctly in any expression.
>
> Consider these examples:
>
> 1. Iif(1 = 1, 2, 3) + 4
>
> 2. Iif(1 = 1, "Foo", 3) + 4
>
> In each case, what do you expect to happen, and what actually happens?
>
> #1 currently type-checks as an integer expression, but after your change
> it will be <variant> + <int>, and I'm not sure how that gets type-checked or
> evaluated.
>
> #2 currently gives a compile-time exception, which can be fixed using
> casts:
>
> Iif(1 = 1, "Foo", Cast(3 as string)) + Cast(4 as string)
>
> So, a simpler solution might be to fix the type inference/validation of
> the Iif function. Require the arguments to be of the same type (using 'cast'
> if necessary), make sure that we give a useful error message if the
> arguments are of incompatible types, and make Iif return the same type as
> its 2nd and 3rd arguments.
>
> Note that everything which applies to Iif probably applies to CASE also.
>
> Julian
>
> PS Please send future emails to the mondrian dev list unless they contain
> proprietary/sensitive material.
>
> ------------------------------
> *From:* Thiyagu Palanisamy [mailto:tpalanis (AT) thoughtworks (DOT) com]
> *Sent:* Tuesday, April 10, 2007 6:39 AM
> *To:* julianhyde (AT) speakeasy (DOT) net
> *Cc:* Matthew.Campbell (AT) thomson (DOT) com; Ajit Vasudeo Joglekar;
> RenoMondrian (AT) thoughtworks (DOT) com
> *Subject:* Generic IIF implementation for your review
>
>
>
> Hi Julian,
>
> We have come up with a solution to make IIf MDX function to take (boolean,
> variant, variant) and return a (variant) similar to MSAS so as to avoid all
> permutations and combinations of parameter types and different return types
> decided at run time.
>
> We realized that currently there is no support for BasicType or AnyType or
> VariantType that we can readily use. We were looking for late binding
> support rather than the current early binding (compilation) that takes
> place. We initially thought of a base class to all the specific Type
> classes but realized that there could be substantial changes and still no
> guarantee of making it work. Then we thought of adding just another Type
> (VariantType) and providing special handling for it where ever required.
>
> We have been able to successfully run all tests with this generic IIf.
>
> We have attached the zip file containing all the modified files. Files are
> based on revision no : 9071 (Couldn't get packChange to work in our
> machine)
>
> Extracting the attached archive in /home/open will copy and replace the
> modified files.
>
>
>
>
> We have not checked in into perforce because of few fundamental changes
> that we feel should be reviewed first. Could you please review this?
>
> Thanks & Regards,
> Ajit &Thiyagu - Pairing
>
>
> _______________________________________________
> Mondrian mailing list
> Mondrian (AT) pentaho (DOT) org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>
>


--
http://cfo-portal.blogspot.com/

_______________________________________________
Mondrian mailing list
Mondrian (AT) pentaho (DOT) org
http://lists.pentaho.org/mailman/listinfo/mondrian

Julian Hyde
04-14-2007, 04:34 PM
Haridasan,

CachePool is now mondrian.rolap.cache.CachePool.

Julian

PS Please don't log your problems in reply to utterly unrelated email
threads. It makes it confusing for people browsing the archives.


_____

From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org]
On Behalf Of Haridasan T
Sent: Saturday, April 14, 2007 10:42 AM
To: Mondrian developer mailing list
Subject: Re: [Mondrian] RE: Generic IIF implementation for your review




Not able to flush Cache.



Giving error


javax.servlet.ServletException: javax.servlet.jsp.JspException: Unable
to compile class for JSP An error occurred at line: 10 in the jsp file:
/WEB-INF/queries/ar.jsp Generated servlet error:
mondrian.rolap.CachePool cannot be resolved to a type

javax.servlet.ServletException: javax.servlet.jsp.JspException: Unable
to compile class for JSP



An error occurred at line: 10 in the jsp file: /WEB-INF/queries/ar.jsp

Generated servlet error:

mondrian.rolap.CachePool cannot be resolved to a type

---

se code below

---

<%@ page import="mondrian.olap.*;" %>

<%@ page session="true" contentType="text/html; charset=ISO-8859-1" %>

<%@ taglib uri="http://www.tonbeller.com/jpivot" prefix="jp" %>

<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>







<%

mondrian.rolap.CachePool.flush();

%>



<jp:mondrianQuery id="query01"
jdbcDriver="oracle.jdbc.driver.OracleDriver"
jdbcUrl="jdbc:oracle:thin:@localhost:1521:XE " jdbcUser="ABCD"
jdbcPassword="ABCD"

catalogUri="/WEB-INF/queries/ar.xml">





select {
[Measures].[Outstanding],[Measures].[Days_60],[Measures].[Days_90],[Meas
ures].[Days_120],[Measures].[Over_120]} on columns,NON EMPTY

{([Country].[All country],[Location].[All location],[Area].[All
area],[Customer].[All customer])} on rows

from ar

</jp:mondrianQuery>

<c:set var="title01" scope="session">TEST-2s </c:set>







On 4/12/07, Julian Hyde <julianhyde (AT) speakeasy (DOT) net> wrote:

I'm not against introducing variant values into mondrian, but the impact
of this change might be insidious, because we're blowing a hole in the
strong typing system. Once a variant is introduced, it needs to work
correctly in any expression.

Consider these examples:

1. Iif(1 = 1, 2, 3) + 4

2. Iif(1 = 1, "Foo", 3) + 4

In each case, what do you expect to happen, and what actually happens?

#1 currently type-checks as an integer expression, but after your change
it will be <variant> + <int>, and I'm not sure how that gets
type-checked or evaluated.

#2 currently gives a compile-time exception, which can be fixed using
casts:

Iif(1 = 1, "Foo", Cast(3 as string)) + Cast(4 as string)

So, a simpler solution might be to fix the type inference/validation of
the Iif function. Require the arguments to be of the same type (using
'cast' if necessary), make sure that we give a useful error message if
the arguments are of incompatible types, and make Iif return the same
type as its 2nd and 3rd arguments.

Note that everything which applies to Iif probably applies to CASE also.

Julian

PS Please send future emails to the mondrian dev list unless they
contain proprietary/sensitive material.



_____

From: Thiyagu Palanisamy [mailto:tpalanis (AT) thoughtworks (DOT) com]
Sent: Tuesday, April 10, 2007 6:39 AM
To: julianhyde (AT) speakeasy (DOT) net
Cc: Matthew.Campbell (AT) thomson (DOT) com; Ajit Vasudeo Joglekar;
RenoMondrian (AT) thoughtworks (DOT) com
Subject: Generic IIF implementation for your review



Hi Julian,

We have come up with a solution to make IIf MDX function to take
(boolean, variant, variant) and return a (variant) similar to MSAS so as
to avoid all permutations and combinations of parameter types and
different return types decided at run time.

We realized that currently there is no support for BasicType or AnyType
or VariantType that we can readily use. We were looking for late binding
support rather than the current early binding (compilation) that takes
place. We initially thought of a base class to all the specific Type
classes but realized that there could be substantial changes and still
no guarantee of making it work. Then we thought of adding just another
Type (VariantType) and providing special handling for it where ever
required.

We have been able to successfully run all tests with this generic IIf.

We have attached the zip file containing all the modified files. Files
are based on revision no : 9071 (Couldn't get packChange to work in our
machine)

Extracting the attached archive in /home/open will copy and replace the
modified files.




We have not checked in into perforce because of few fundamental changes
that we feel should be reviewed first. Could you please review this?

Thanks & Regards,
Ajit &Thiyagu - Pairing



_______________________________________________
Mondrian mailing list
Mondrian (AT) pentaho (DOT) org
http://lists.pentaho.org/mailman/listinfo/mondrian
<http://lists.pentaho.org/mailman/listinfo/mondrian>






--
http://cfo-portal.blogspot.com/


_______________________________________________
Mondrian mailing list
Mondrian (AT) pentaho (DOT) org
http://lists.pentaho.org/mailman/listinfo/mondrian