Back to the start – MDX parametrization revisited

After a million or so complaints about the complexity of building parametrized queries with the PARAMETER function within MDX, today I indulged to the demands of the crowd.

Beginning with Milestone 2 of the Pentaho Report-Designer 3.6,we now support parameter injection via the ${parameter} syntax. Parameter values injected via that syntax will not be checked in any way, so it is the designer’s responsibility to ensure that everything is quoted correctly to cause no harm or to break the query. With great powers comes great responsibility.

The ${parameter} syntax for MDX is not just a toString() conversion. It follows the MessageFormat syntax and thus allows to format Date and Number objects properly before inserting them into the MDX query. An extended format rule allows to produce quoted MDX-string literals by specifying the subformat string. These strings start and end with a double-quote and all double-quote characters found in the original string get escaped according to the MDX grammar.

So now I can finally answer the question on how to parametrize a Date-Axis from a Date-parameter. To produce a member string like [2009].[10].[4] from a parameter called dateparam use [${dateparam,date,"yyyy"}].[${dateparam,date,"MM"}].[${dateparam,date,"dd"}] in your MDX query.

I still haven’t found out how to do the same with the PARAMETER function.

Support for the PARAMETER function will remain there (as in theory it is a good idea to have prepared/explicit parameter).

You can test this functionality with either the latest CI build or with the upcoming Milestone 2 of the Report-Designer 3.6.

This entry was posted in Development on by .
Thomas

About Thomas

After working as all-hands guy and lead developer on Pentaho Reporting for over an decade, I have learned a thing or two about report generation, layouting and general BI practices. I have witnessed the remarkable growth of Pentaho Reporting from a small niche product to a enterprise class Business Intelligence product. This blog documents my own perspective on Pentaho Reporting's development process and our our steps towards upcoming releases.

4 thoughts on “Back to the start – MDX parametrization revisited

  1. Bill W.

    Ok, so then is it possible to simply place a ${variable} in a MDX query to have dynamic rows or columns? Thus,
    select ${myVariable} on COLUMNS,
    {[Measures].[MyMeasure1], [Measures].[MyMeasure2]} on ROWS
    from [Monthly Data]

    Where myVariable can be [Client].[Location].[All Locations] or {[Client].[Location].[WASHINGTON], [Client].[Location].[COLORADO]}

    I have been trying to get this in PRD and have not been able to do so.

  2. Bill W.

    Ok, so then is it possible to simply place a ${variable} in a MDX query to have dynamic rows or columns? Thus,
    select ${myVariable} on COLUMNS,
    {[Measures].[MyMeasure1], [Measures].[MyMeasure2]} on ROWS
    from [Monthly Data]

    Where myVariable can be [Client].[Location].[All Locations] or {[Client].[Location].[WASHINGTON], [Client].[Location].[COLORADO]}

    I have been trying to get this in PRD and have not been able to do so.

  3. Bill W.

    Interestingly, JPivot seems to strip curly braces and some other “complete” member identification. I need to test a bit more, but find that if I submit {[Client Location].[Client Location.Clients].[All Clients].[COLORADO]} it will reformat the MDX to [Client Location.Clients].[COLORADO].

    In PRD, I have found that once a query is parameterized and you cannot get to the variables anymore, PRD can lose connection to the field variables. You can copy and paste information from one report to another, and the second report will not work. I have had to pull the variables from the PRD query to get the fields to place on the report.

    I really like 3.6. I have been using Pentaho off and on for 4 years and this version rocks. I am already hearing 3.7 and 4.0 upgrades that will be even mo’ better yet.

Comments are closed.