[Mondrian] scenarios

Julian Hyde jhyde at pentaho.com
Mon Dec 10 18:00:39 EST 2012

On Dec 7, 2012, at 5:44 AM, Paul Stoellberger <p.stoellberger at gmail.com<mailto:p.stoellberger at gmail.com>> wrote:

I just saw your recent commit in lagunitas about scenarios and I have 2 questions:

1) do we still have to manually define a scenario dimension / hierarchy (I see we have to have 1 hierarchy called "Scenario" in the code) in the schema?
In the old schema format we added something like:

<Dimension name='Scenario' foreignKey='time_id'>
<Hierarchy primaryKey='time_id' hasAll='true'>
<InlineTable alias='_dummy'>
<ColumnDef name='foo' type='Numeric'/>
<Level name='Scenario' column='foo'/>

It would be great if this were a property on the cube instead of introducing such a dummy dimension.
<Cube scenarioEnabled="true"> and the rest would be automatic. Makes it easier for people to try it.

I'm putting in something very similar. If you set

   <Cube ... enableScenarios="true">

then the cube will automatically contain a dimension called Scenario.

I remember you talked about improved hanger dimension support in Mondrian 4?

I am also working on hanger dimensions. First, I need to figure out what they are. A hanger dimension has two defining qualities: 1. it is not linked to any measure groups, 2. it contains only calculated members.

1 is easy to achieve in Mondrian 4. Just don't create a link. (Optionally, create a NoLink so that Mondrian doesn't nag you.)

For 2, you still need a level based on an attribute based on a column. So I've created a hidden table _extra with one column c. If you define an <Attribute  ... hanger='true'/> you are not allowed to use any tables and all attributes will be

When you define a hanger attribute, you must either enable its all member or define at least one calculated member. Otherwise you end up with a hierarchy with no members at all, and Mondrian doesn't allow that.

I'm fixing some a bug during the bootstrap process where a hierarchy has no real members and therefore its default member is a calculated member.

Also this hanger dimension seems to cause some troubles on the drill through (thats why we enable only either drillthrough or scenarios) because of the generated SQL

I will try to remember to test scenarios with drill-through. But please log a jira case that scenarios don't currently work with drill-through and we'll fix it for 4.

2) Whats your plan on improvements? We would be happy to work on this together and at least expose it nicely in saiku.
I think it would be easy to persist scenarios in our query files as well, by saving the cell's tuples and new values so it can be "applied" again.

Saving scenarios would be a good feature. I'd implement it by recording all calls made to Cell.setValue as XML (or JSON if you prefer). This could go to a file or to a database table. Saving could occur at the time the calls are made, or when someone presses the 'save' button.

We'd also need to be able to delete scenarios.

Its a great feature and people seem to like it so we should take this to the next level and make it a real feature!

Glad you like it!


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

More information about the Mondrian mailing list