You may or may not be aware of the property mondrian.olap.SsasCompatibleNaming. It controls the naming of elements, in particular how Mondrian names hierarchies when there are multiple hierarchies in the same dimension.
Let's suppose that there is a dimension called 'Time', and it contains hierarchies called 'Time' and 'Weekly'.
If SsasCompatibleNaming is false, the dimension and the first hierarchy will both be called '[Time]', and the other hierarchy will be called '[Time.Weekly]'.
If SsasCompatibleNaming is true, the dimension will be called '[Time]', the first hierarchy be called '[Time].[Time]', and the other hierarchy will be called '[Time].[Weekly]'.
As you can see, SsasCompatibleNaming makes life simpler, if slightly more verbose, because it gives each element a distinct name. There are knock-on effects, beyond the naming of hierarchies. The most subtle and confusing effect is in the naming of levels when the dimension, hierarchy and level all have the same name. If SsasCompatibleNaming is false, then [Gender].[Gender].Members is asking for the members of the gender level, and yields two members. If SsasCompatibleNaming is true, then [Gender].[Gender].Members is asking for the members of the gender hierarchy, and yields three members (all, F and M).
Usually, however, Mondrian is forgiving in how it resolves names, and if elements have different names, it will usually find the element you intend.
The default value is false. However, that leads to naming behavior which is not compatible with other MDX implementations, in particular Microsoft SQL Server Analysis Services (versions 2005 and later).
From mondrian-4 onwards, the property will be set to true. (You won't be able to set it to false.) This makes sense, because in mondrian-4, with attribute-hierarchies, there will typically be several hierarchies in each dimension. We will really need to get our naming straight.
What do we recommend? If you are using Pentaho Analyzer, Saiku or JPivot today, we recommend that you use the default value, false. But if you are writing your own MDX (or have built your own client), try setting the value to true. The new naming convention actually makes more sense, and moving to it now will minimize the disruption when you move to mondrian-4.
I am just about to check in a change that uses a new, and better name resolution algorithm. It will be more forgiving, and standards-compliant, in how it resolves the names of calculated members. However, it might break compatibility, so it will only be enabled if SsasCompatibleNaming is true.
Are you using this property today? Let us know how it's working for you.
7 comments:
Could there be a function that's available to check?
ie. Saiku could ask the OLAP provider for the value of SsasCompatibleNaming, and if it gets an error, it can assume it's not talking to Mondrian. If it gets "false" it knows it's talking to an old Mondrian. If it gets "true", it knows to use SSAS style names.
Mondrian's properties (defined in mondrian.properties and elsewhere) are not exposed right now. In principle, we could make DISCOVER_PROPERTIES (XMLA) and OlapDatabaseMetaData.getDatabaseProperties() (olap4j) return the properties. But it is a potential security concern, so I will avoid it if possible.
It may just work. Hierarchy.getUniqueName(), for example, should return whatever string will resolve to that hierarchy in mondrian's MDX parser under the current property settings. Likewise Level.getUniqueName() and Member.getUniqueName().
Give it a try. If it works, we can start to advise Saiku users to set SsasCompatibileNaming=true.
How does this effect role security? I guess it will be more relyable with multiple hierarchies.
I just read this and I admit I'm a little bit worried.
If I understood correctly, this modes are not compatible between them.
I'm a hardcore mdx user, and my dashboards heavily rely on automagical mdx generation through the use of parameters.
Does this mean all of them will break in 4.0?
Also - if I aim to distribute a dashboard that uses mdx, do I need to write 2 query styles if I want to support both options? (I'm afraid the answer here is yes)
If so, how can I detect in which mode mondrian is? No xmla, pure client side mdx...
Pedro,
If you are generating MDX you should be fine. Just use the unique name of the hierarchy as it comes back from the metadata. E.g. the "Stores" hierarchy will have a unique name "[Store].[Stores]".
This post was mainly a "heads up" for people who are writing large amounts of MDX by hand and are using abbreviations that may not be supported in future.
If there are incompatibilities, they should be minor: you should be able to work around them with a couple of lines of code. There is currently no way to ask mondrian what its property settings are. We'll add something...
Julian
Jens,
Role security should continue to work in the same way in a schema that has lots of hierarchies. You may need to change unique names in role definitions. But mondrian is forgiving in resolving unique names -- e.g. if there is only one hierarchy called "Stores" you can refer to it as either [Store].[Stores] or just [Stores].
Something that would be a member-property in mondrian-3 will probably become an attribute-hierarchy in mondrian-4. Member-properties can't be access-controlled, but attribute-hierarchies can.
Julian
Go through this link
http://stackoverflow.com/questions/13535028/select-one-hierarchy-on-a-dimension-with-multiple-hierarchies
And also see point no. 3.3.5 in
http://mondrian.pentaho.com/documentation/schema.php#Multiple_hierarchies
Post a Comment