[Mondrian] ADOMD.Net/SSRS incompatible changes
tiago.ferreira at webdetails.pt
Wed Apr 9 15:26:47 EDT 2014
We've been working on mondrian ADOMD.Net and SSRS compatibility, and some
changes modify current mondrian behavior in ways that could break current
usages (new functions etc not included here).
Some functionalities depend on enabling certain properties, but even just
those that don't will change every xmla response.
We're currently working on bringing these to the master branch and would
like to get developer and community input on how to best approach this part.
Of particular concern is which functionalities should be enabled by
properties, which properties should be grouped together, and what can be
just accepted as new behavior.
Here is an overview of potentially breaking changes:
- New rowset columns
Most of the new xmla rowset columns were just added to prevent outright
failure when reading the response or exceptions when trying to access them
via the adomd api. Most of them have default values that aren't useful
beyond keeping things from breaking in these scenarios. Only
MDSCHEMA_MEMBERS's EXPRESSION and MEMBER_KEY expose new info.
MDSCHEMA_MEASUREGROUPS (new rowset)
- Restrictions DIMENSION_VISIBILITY, HIERARCHY_VISIBILITY,
- Intrinsic member properties ID and NAME were added as aliases to KEY and
- xmlns prefixes (xmla and cxmla) were removed for adomd.
This is an odd one but in at least one case adomd will throw a
NotSupportedException when accessing a field if adomd doesn't recognize the
provider version (even though the provider itself can still be mondrian).
This property was added to optionally spoof the xmla provider version.
- XMLA Tabular Cell changes
- Added FORMATTED_VALUE and FORMAT_STRING elements,
- VALUE element name now ends in .VALUE
- Members by key. This is probably the only one prone to break things that
don't use xmla.
Added the property mondrian.olap.SsasKeyLookup=true to allow keys to be
used in the same situations as names (after a member or hierarchy).
This only affects the current mondrian3 key access (level + full key) when
doing key lookups from the hierarchy: instead of looking at the lowest
level it will now look up the topmost.
- Xmla exceptions
The mondrian.xmla.UseMSSASError=true property changes mondrian xmla
exception format into something ADOMD can parse as an exception.
Any previous xmla exception parsing should break with this version.
It's mostly different structure, apart from the error code which has to be
an unsigned integer instead of string. In the current implementation this
number should be coherent but otherwise useless (it's just a part of the
- Full hierarchy names
mondrian.xmla.FullHierarchyNames=true property makes all unique names of
members, levels and hierarchies in xmla include the hierarchy name even
when it is the same as the dimension's.
Tiago Gomes Ferreira
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mondrian