[Mondrian] RE: Generic IIF implementation for your review

Haridasan T haridasan.t at gmail.com
Sat Apr 14 13:41:30 EDT 2007

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" %>




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


select {
on columns,NON EMPTY

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

from ar


<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

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

More information about the Mondrian mailing list