[Mondrian] adding warning support to Mondrian's Connection/Query API

[Julian Hyde]

Sounds fine to me.

Please include some statement about the thread safety (or non-safety) of
the list if two statements are executing in the same connection.

Julian 

> -----Original Message-----
> From: mondrian-bounces at pentaho.org 
> [mailto:mondrian-bounces at pentaho.org] On Behalf Of John V. Sichi
> Sent: Wednesday, April 04, 2007 1:08 PM
> To: mondrian at pentaho.org
> Subject: [Mondrian] adding warning support to Mondrian's 
> Connection/Query API
> 
> olap4j would address this by inheritance from the warning support in 
> JDBC.  Until that's available, would it be OK to add warning 
> support to 
> the existing Mondrian API?  Here's enough of a sketch for comment on 
> whether the addition is something people would approve of; if it is, 
> I'll send out a proper spec proposal at the Javadoc level.
> 
> Following JDBC:
> 
> - introduce MondrianWarning subclassed from MondrianException
> 
> - add getWarnings and clearWarnings methods to Connection and Query 
> (return List<MondrianWarning> instead of JDBC's linked list)
> 
> - implicitly clear warning queue on certain events (JDBC is fairly 
> specific here)
> 
> Here's a use-case.  We would like to add a property 
> mondrian.rolap.ignoreInvalidMembersDuringQuery (similar to 
> the existing 
> mondrian.rolap.ignoreInvalidMembers, which only affects schema 
> validation).  When this property is enabled, missing members would be 
> replaced with the null member (same rule Zelaine added for schema 
> validation).  This allows a saved report to be resilient to data 
> changes, even if it refers to members explicitly.  MSAS 2005 
> introduced 
> a "missing member" mode for this:
> 
> http://sqljunkies.com/WebLog/mosha/archive/2005/06/09/mdx_miss
> ing_members_mode.aspx
> 
> However, we may want to let the user know that there's a 
> mismatch with 
> what was requested at the time the report was saved.  Posting 
> a warning 
> at the point where we detect the invalid member would be easy if the 
> infrastructure were there.
> 
> JVS
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>