[Mondrian] ADOMD.Net/SSRS incompatible changes

Tiago Ferreira tiago.ferreira at webdetails.pt
Thu Apr 24 16:01:20 EDT 2014


Thanks for the reply

- xmlns prefixes
The namespaces are still declared, inner elements just don't get prefixed.
Could still use the olap4j xmla driver with this version.

- Full hierarchy names
Looks like in SSAS the inclusion of dimension name can be defined by
dimension (http://technet.microsoft.com/en-us/library/ms126702.aspx), so it
should be coherent within the same dimension. We had a later issue where
just doing it on the xmla layer didn't cut it, and it turned out to be a
much simpler change.

- MONDRIAN-1991 - Members by key
We only focused on adomd and reporting services, this branch still has
issues with excel that we didn't get into. It does pass the tests for
MONDRIAN-951
apart from the null key that still has to be fixed.

- MONDRIAN-1993 - Xmla exceptions
 There is a NamespaceCompatibility attribute; although I couldn't find out
what it's for, is always used by ms clients and nothing else afaik. However
this is only sent when beginning the session, so we'd need proper session
tracking before being able to use that.
 There is an alternative, since mondrian clients expect <error>, adomd
expects <Error> and xml is case-sensitive. The property can just add the
adomd-friendly error besides the regular one and properly implemented
clients might still be able to get what they want (adomd didn't complain).


On 10 April 2014 21:02, Luc Boudreau <lucboudreau at gmail.com> wrote:

> Hey Tiago,
>
> Thanks for the write up. I've been waiting a long time for this. This is
> very cool work that your team has done.
>
>  My comments are below.
>
> Luc
>
>
>  - xmlns prefixes (xmla and cxmla) were removed for adomd
>
> This could cause a lot of problems. Have you tried the olap4j XMLA driver
> without the namespaces? I suspect that it will break apart. Maybe this
> should be also a property.
>
>  - Full hierarchy names
>
> Isn't this functionally equivalent to mondrian.olap.SsasCompatibleNaming?
> The way you've described it, it sounds like a part of the code in mondrian
> doesn't honor the value of that property. If you found a place in the code
> where this property, once set to true, still doesn't affect the output of
> unique names and the hierarchy isn't added to the unique name, we should
> probably fix it there.
>
>  - MONDRIAN-1991 - Members by key.
>
> There are clear rules in the MDX specs when resolving names. Is this
> compatible with Excel as well as SSAS? (Was mondrian the only one which
> differed on this?) This should probably also be controlled by
> mondrian.olap.SsasCompatibleNaming.
>
> Note that all the changes related to the SsasCompatibleNaming property
> become the standard in mondrian 4.X. As of now, mondrian 4 behaves as if it
> was mondrian 3 with the property on. As a matter of fact, there isn't a
> property anymore. It will remove some complexity in the code and should be
> easier to merge.
>
>  - MONDRIAN-1993 - Xmla exceptions
>
> I don't think we should use a property for this. The only way I think
> would work nicely is if we send back the correct message according to the
> client. If we use a property, we can only serve either Excel, or everyone
> else, but not both. That would be very unfortunate.
>
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>
>


-- 
Tiago Gomes Ferreira
Webdetails Dev

www.webdetails.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20140424/8b06b995/attachment.html 


More information about the Mondrian mailing list