[Mondrian] Mondrian 4 - Unsupported properties?

Roland Bouman roland.bouman at gmail.com
Mon Jun 1 05:59:23 EDT 2015


There is another thing that might be relevant to this issue. Here's the
formatted query you posted:

SELECT
  NON EMPTY Hierarchize(
    AddCalculatedMembers({
      DrilldownLevel({[Store].[Store Size in SQFT].[All Store Size in
SQFTs]})
    })
  )
  DIMENSION PROPERTIES
    PARENT_UNIQUE_NAME
  ,[Store].[Store Size in SQFT].[Store Sqft].[CATALOG_NAME]
  ,[Store].[Store Size in SQFT].[Store Sqft].[SCHEMA_NAME]
  ,[Store].[Store Size in SQFT].[Store Sqft].[CUBE_NAME]
  ,[Store].[Store Size in SQFT].[Store Sqft].[DIMENSION_UNIQUE_NAME]
  ,[Store].[Store Size in SQFT].[Store Sqft].[HIERARCHY_UNIQUE_NAME]
  ,[Store].[Store Size in SQFT].[Store Sqft].[LEVEL_UNIQUE_NAME]
  ,[Store].[Store Size in SQFT].[Store Sqft].[LEVEL_NUMBER]
  ,[Store].[Store Size in SQFT].[Store Sqft].[MEMBER_ORDINAL]
  ,[Store].[Store Size in SQFT].[Store Sqft].[MEMBER_NAME]
  ,[Store].[Store Size in SQFT].[Store Sqft].[MEMBER_UNIQUE_NAME]
  ,[Store].[Store Size in SQFT].[Store Sqft].[MEMBER_TYPE]
  ,[Store].[Store Size in SQFT].[Store Sqft].[MEMBER_GUID]
  ,[Store].[Store Size in SQFT].[Store Sqft].[MEMBER_CAPTION]
  ,[Store].[Store Size in SQFT].[Store Sqft].[CHILDREN_CARDINALITY]
  ,[Store].[Store Size in SQFT].[Store Sqft].[PARENT_LEVEL]
  ,[Store].[Store Size in SQFT].[Store Sqft].[PARENT_UNIQUE_NAME]
  ,[Store].[Store Size in SQFT].[Store Sqft].[PARENT_COUNT]
  ,[Store].[Store Size in SQFT].[Store Sqft].[DESCRIPTION]
  ,[Store].[Store Size in SQFT].[Store Sqft].[IS_PLACEHOLDERMEMBER]
  ,[Store].[Store Size in SQFT].[Store Sqft].[IS_DATAMEMBER]
  ,[Store].[Store Size in SQFT].[Store Sqft].[DISPLAY_INFO]
  ,[Store].[Store Size in SQFT].[Store Sqft].[VALUE]
  ,[Store].[Store Size in SQFT].[Store Sqft].[$member_scope]
  ,[Store].[Store Size in SQFT].[Store Sqft].[$scenario]
  ,[Store].[Store Size in SQFT].[Store Sqft].[CELL_FORMATTER]
  ,[Store].[Store Size in SQFT].[Store Sqft].[CELL_FORMATTER_SCRIPT]
  ,[Store].[Store Size in SQFT].[Store
Sqft].[CELL_FORMATTER_SCRIPT_LANGUAGE]
  ,[Store].[Store Size in SQFT].[Store Sqft].[DISPLAY_FOLDER]
  ,[Store].[Store Size in SQFT].[Store Sqft].[FORMAT_EXP]
  ,[Store].[Store Size in SQFT].[Store Sqft].[KEY]
ON COLUMNS
FROM [HR]
CELL PROPERTIES
  VALUE
, FORMAT_STRING
, LANGUAGE
, BACK_COLOR
, FORE_COLOR
, FONT_FLAGS

According to
https://msdn.microsoft.com/en-us/library/ms145528(v=sql.120).aspx, these
properties are "context insensitive intrinsic properties":

CATALOG_NAME
DIMENSION_UNIQUE_NAME
HIERARCHY_UNIQUE_NAME
LEVEL_UNIQUE_NAME
LEVEL_NUMBER
MEMBER_NAME
MEMBER_UNIQUE_NAME
MEMBER_TYPE
MEMBER_CAPTION
CHILDREN_CARDINALITY
PARENT_LEVEL
PARENT_UNIQUE_NAME
PARENT_COUNT
DESCRIPTION
IS_PLACEHOLDERMEMBER
IS_DATAMEMBER

The MSAS documentation reads:

"
PROPERTIES Syntax for Non-Context Sensitive Properties

Use the following syntax to specify an intrinsic, non-context sensitive
member property using the PROPERTIES keyword:

DIMENSION PROPERTIES Property

Notice that this syntax does not allow the property to be qualified by a
dimension or level. The property cannot be qualified because an intrinsic
member property that is not context sensitive applies to all members of an
axis. For example, an MDX statement that specifies the DESCRIPTION
intrinsic member property would have the following syntax:

DIMENSION PROPERTIES DESCRIPTION

This statement returns the description of each member in the axis
dimension. If you tried to qualify the property with a dimension or level,
as in Dimension.DESCRIPTION or Level.DESCRIPTION, the statement would not
validate.
"

So if this is true, and the [Store].[Store Size in SQFT].[Store Sqft] level
does not explicitly define custom properties of the same name (which I am
assuming it doesn't in this case), then the statement should not even
validate, if I understand the documentation correctly.

On Mon, Jun 1, 2015 at 11:01 AM, Roland Bouman <roland.bouman at gmail.com>
wrote:

> Ingo, Luc,
>
> sorry to interrupt but there is something that is not clear to me.
>
> Ingo you wrote:
>
> "we found the line in the source code, that breaks the XMLA call. Apparently
> in Mondrian 3.x  This call was made in a different class and passed false
> instead of true as parameter."
>
> But the links you provide both point to Mondrian 4 source, 4.2 and 4.3
> respectively.
>
> The relevant implementation of getProperties in MondrianOlap4jLevel looks
> identical in both 4.2 and 4.3:
>
>
> https://github.com/pentaho/mondrian/blob/4.2/src/main/java/mondrian/olap4j/MondrianOlap4jLevel.java#L98
>
> https://github.com/pentaho/mondrian/blob/4.3/src/main/java/mondrian/olap4j/MondrianOlap4jLevel.java#L98
>
> and so do the calls to getProperties in MondrianOlap4jExtra:
>
>
> https://github.com/pentaho/mondrian/blob/4.2/src/main/java/mondrian/olap4j/MondrianOlap4jExtra.java#L320
>
> https://github.com/pentaho/mondrian/blob/4.3/src/main/java/mondrian/olap4j/MondrianOlap4jExtra.java#L320
>
> Ingo, can you track back and verify where you made the change exactly?
> Since if this part of the code is identical and worked in an earlier
> version then it would seem the cause is somewhere else.
>
> On Mon, Jun 1, 2015 at 8:53 AM, Ingo Klose <Ingo.Klose at incuda.com> wrote:
>
>> Hello Luc,
>>
>> Thanks for the answer, but to be honest I have no direct access to nor
>> any knowledge of Microsoft SQL Server Analysis Services.
>>
>> All I know is that the tool that we try to use to connect Microsoft Excel
>> (XMLAConnect) has a problem with Mondrian 4 because this  method is
>> implemented differently between Mondrian 3.X and Mondrian 4. At this point
>> me and Tom are trying to figure out the reason for this change and if it is
>> reversible or what consequences that might have.
>>
>> Since we are going through Saiku as the "Server" we have another level in
>> which we might be able to handle the problem, but it would be good to
>> understand it better, especially from the Mondrian point of view.
>>
>> Best regards,
>> Ingo
>>
>>
>> Date: Tue, 26 May 2015 09:36:40 -0400
>> From: Luc Boudreau <lucboudreau at gmail.com>
>> Subject: Re: [Mondrian] Mondrian 4 - Unsupported properties?
>> To: Mondrian developer mailing list <mondrian at pentaho.org>
>> Message-ID:
>>         <CAKTEAx8c=Qn7PydZKWeRuvGMCqiPvjXDr8Wqjfp=_naWhyfS=
>> w at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> I'm not sure that the solution is without consequences. According to the
>> javadocs of the XmlaExtra interface:
>>
>>         /**
>>
>>          * Returns the defined properties of a level. (Not including
>> system
>>
>>          * properties that every level has.)
>>
>>          *
>>
>>          * @param level Level
>>
>>          * @return Defined properties
>>
>>          */
>>
>>         List<Property> getLevelProperties(Level level);
>>
>>
>> Have you tried similar calls on Microsoft Sql Server Analysis Services?
>> We shold compare their implementation with ours.
>> _______________________________________________
>> Mondrian mailing list
>> Mondrian at pentaho.org
>> http://lists.pentaho.org/mailman/listinfo/mondrian
>>
>
>
>
> --
> Roland Bouman
> blog: http://rpbouman.blogspot.com/
> twitter: @rolandbouman
> linkedin: http://www.linkedin.com/profile/view?id=5142800&trk=tab_pro
>
> Author of "Pentaho Solutions" (Wiley, ISBN: 978-0-470-48432-6
> http://tinyurl.com/lvxa88) and "Pentaho Kettle Solutions" (Wiley, ISBN:
> 978-0-470-63517-9 http://tinyurl.com/33r7a8m)
>



-- 
Roland Bouman
blog: http://rpbouman.blogspot.com/
twitter: @rolandbouman
linkedin: http://www.linkedin.com/profile/view?id=5142800&trk=tab_pro

Author of "Pentaho Solutions" (Wiley, ISBN: 978-0-470-48432-6
http://tinyurl.com/lvxa88) and "Pentaho Kettle Solutions" (Wiley, ISBN:
978-0-470-63517-9 http://tinyurl.com/33r7a8m)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20150601/6e3c4dfe/attachment.html 


More information about the Mondrian mailing list