[Mondrian] RE: Generic IIF implementation for your review

[Haridasan T]

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.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.com]
> *Sent:* Tuesday, April 10, 2007 6:39 AM
> *To:* julianhyde at speakeasy.net
> *Cc:* Matthew.Campbell at thomson.com; Ajit Vasudeo Joglekar;
> RenoMondrian at thoughtworks.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.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>
>


-- 
http://cfo-portal.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20070414/cac17309/attachment.html