[Mondrian] Unique Member Names for Calculated Fields in Mondrian 4

Tom Barber tom at analytical-labs.com
Wed Jan 20 11:24:23 EST 2016


And to add to that, i don't see why it would need to act any differently to
a standard non calculated member, ie: if the main members don't require a
level prepended, why does the calculated variant?

--------------

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart
<http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
goal, but you can always help by sponsoring the project
<http://www.meteorite.bi/products/saiku/sponsorship>)

On 20 January 2016 at 14:00, Tom Barber <tom at analytical-labs.com> wrote:

> I don't agree or disagree, but mondrian seems to respond with out the
> level but then require the level when constructing the mdx :)
> On 20 Jan 2016 1:56 pm, "Andy Grohe" <agrohe21 at gmail.com> wrote:
>
>> I would say it is better practice to fully qualify the member wth the
>> level if possible.
>> On Jan 20, 2016 4:09 AM, "Tom Barber" <tom at analytical-labs.com> wrote:
>>
>>> Hello Folks
>>>
>>> Trying to debug a problem that has cropped up in Mondrian 4.
>>>
>>> I have a schema that looks like this:
>>> https://gist.github.com/buggtb/6173b6ed547e0be77ce4
>>>
>>> And as you can see there is a calculated column that extracts the year
>>> from a date.
>>>
>>> The queries run, but when you use Saiku to select a member the unique
>>> name for the Year is [Test Date].[Test Date].[1997] which fails because it
>>> reckons is doesn't exist. That said, [Customers].[Customers].[USA] does
>>> exist, so for normal members it is fine. Anyway, if I drop to an MDX query,
>>> indeed:
>>>
>>> WITH
>>> SET [~COLUMNS] AS
>>>     {[Customers].[Customers].[USA]}
>>> SET [~ROWS] AS
>>>     Hierarchize({[Test Date].[Test Date].[1997]})
>>> SELECT
>>> NON EMPTY CrossJoin([~COLUMNS], {[Measures].[Unit Sales]}) ON COLUMNS,
>>> NON EMPTY [~ROWS] ON ROWS
>>> FROM [Sales]
>>>
>>> Doesn't work, but:
>>>
>>> WITH
>>> SET [~COLUMNS] AS
>>>     {[Customers].[Customers].[USA]}
>>> SET [~ROWS] AS
>>>     Hierarchize({[Test Date].[Test Date].[Year].[1997]})
>>> SELECT
>>> NON EMPTY CrossJoin([~COLUMNS], {[Measures].[Unit Sales]}) ON COLUMNS,
>>> NON EMPTY [~ROWS] ON ROWS
>>> FROM [Sales]
>>>
>>> Does. So from my point of view there is an issue with the member lookup.
>>> Anyway, does anyone have any bright ideas as a workaround/fix?
>>>
>>> Thanks
>>>
>>> Tom
>>> --------------
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
>>> goal, but you can always help by sponsoring the project
>>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>>
>>> _______________________________________________
>>> Mondrian mailing list
>>> Mondrian at pentaho.org
>>> http://lists.pentaho.org/mailman/listinfo/mondrian
>>>
>>>
>> _______________________________________________
>> Mondrian mailing list
>> Mondrian at pentaho.org
>> http://lists.pentaho.org/mailman/listinfo/mondrian
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20160120/ee33b63f/attachment.html 


More information about the Mondrian mailing list