[Mondrian] Mondrian 4 dialect issue

Tom Barber(Alabs) tom at analytical-labs.com
Wed Jun 5 12:10:18 EDT 2013


Haven't got it breaking in Foodmart yet, but there is Mondrian-1610 to 
keep you entertained.


On 05/06/13 16:25, Luc Boudreau wrote:
> Sure thing. Put anything you can share in a Jira case and let me know 
> the #.
>
>
> On Wed, Jun 5, 2013 at 11:24 AM, Tom Barber(Alabs) 
> <tom at analytical-labs.com <mailto:tom at analytical-labs.com>> wrote:
>
>     Okay I don't have a foodmart repro path Luc but I do know whats
>     causing it.
>
>     My client has written a schema which has a User dimension,
>
>     within that dimension it has a bunch of attributes that reference
>     more than one table one of them is:
>
>     <Attribute name="Path ID" keyColumn="PATH_ID" table="LKP_PATH"
>     hasHierarchy='false'/>
>           <Attribute name="Path Configuration"
>     keyColumn="CONFIGURATION" table="LKP_PATH" hasHierarchy='false'/>
>
>     and then they include those attributes in a Hierarchy:
>
>     <Hierarchy name='Path' allMemberName='All Path'>
>                 <Level attribute='Path ID' />
>                 <Level attribute='Path Configuration'/>
>             </Hierarchy>
>
>     This is all parsed fine by Mondrian and the schema loads.
>
>
>     But as soon as you enable that Hierarchy and then use the Path ID
>     field elsewhere in the schema, in their case they also have a
>     dimension called Path which also uses the LKP_PATH table, thats
>     when the SQL gets aliased incorrectly.
>
>     Luc I can send you their schema and SQL table structure offline if
>     that would help.
>
>     Tom
>
>
>
>     On 05/06/13 15:46, Luc Boudreau wrote:
>>     Can you reproduce this on FoodMart? I'd like to create an item in
>>     Jira so we address this ASAP.
>>
>>
>>     On Wed, Jun 5, 2013 at 10:03 AM, Tom Barber(Alabs)
>>     <tom at analytical-labs.com <mailto:tom at analytical-labs.com>> wrote:
>>
>>         Hi Luc, the SQL itself I'd stripped out,
>>
>>         All I'm doing it putting a Level.Member on Rows and a Measure
>>         on the columns.
>>
>>         And I get:
>>         Caused by: mondrian.olap.MondrianException: Mondrian
>>         Error:Failed to load segment form SQL
>>                 at
>>         mondrian.rolap.agg.SegmentLoader.createExecuteSql(SegmentLoader.java:643)
>>                 at
>>         mondrian.rolap.agg.SegmentLoader.loadImpl(SegmentLoader.java:195)
>>                 ... 8 more
>>         Caused by: mondrian.olap.MondrianException: Mondrian
>>         Error:Internal error: Error while loading segment;
>>         sql=[select `LKP_PATH`.`PATH_ID` as `c0`,
>>         count(`FCT_RESUMEUPLOAD`.`FACT_RESUMEUPLOAD_KEY`) as `m0`
>>         from `LKP_PATH` as `LKP_PATH_1`, `FCT_RESUMEUPLOAD` as
>>         `FCT_RESUMEUPLOAD` where `FCT_RESUMEUPLOAD`.`PATH_KEY` =
>>         `LKP_PATH`.`PATH_KEY` and `LKP_PATH`.`PATH_ID` = 'hello'
>>         group by `LKP_PATH`.`PATH_ID`]
>>
>>         Thats the real SQL generated. I'm using the latest Mondrian 4
>>         + Saiku build from our CI, its tagged 4.0.0-SNAPSHOT so I
>>         don't know what exact Mondrian 4 build it used but it was
>>         built 11 hours ago.
>>
>>         mysql  Ver 14.14 Distrib 5.5.31, for Linux (x86_64) using
>>         readline 5.1
>>
>>         I was actually trying to debug another issue for a client,
>>         but I can't even run this query.
>>
>>         Cheers
>>
>>         Tom
>>
>>
>>
>>         On 05/06/13 14:46, Luc Boudreau wrote:
>>>         Where is that SQL generated? Is this a tuple query? This
>>>         looks like a bug; not a dialect issue.
>>>
>>>         Luc
>>>
>>>
>>>         On Wed, Jun 5, 2013 at 9:09 AM, Tom Barber(Alabs)
>>>         <tom at analytical-labs.com <mailto:tom at analytical-labs.com>>
>>>         wrote:
>>>
>>>             Hello Mondrian fans,
>>>
>>>             I'm trying to get a schema running under Mondrian 4 and
>>>             Mysql and when a
>>>             query is run its generating SQL like this:
>>>
>>>             select `LKP_PATH`.`PATH_ID` as `c0` from `LKP_PATH` as
>>>             `LKP_PATH_1`;
>>>
>>>             which MySQL is getting upset over because the table name
>>>             at the start of
>>>             the select isn't the aliased table name but the original:
>>>
>>>               select `LKP_PATH_1`.`PATH_ID` as `c0` from `LKP_PATH`
>>>             as `LKP_PATH_1`;
>>>
>>>             The above is a valid query.
>>>
>>>             Any property I can set to get this working?
>>>
>>>             Thanks
>>>
>>>             Tom
>>>             _______________________________________________
>>>             Mondrian mailing list
>>>             Mondrian at pentaho.org <mailto:Mondrian at pentaho.org>
>>>             http://lists.pentaho.org/mailman/listinfo/mondrian
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         Mondrian mailing list
>>>         Mondrian at pentaho.org  <mailto:Mondrian at pentaho.org>
>>>         http://lists.pentaho.org/mailman/listinfo/mondrian
>>
>>
>>         _______________________________________________
>>         Mondrian mailing list
>>         Mondrian at pentaho.org <mailto:Mondrian at pentaho.org>
>>         http://lists.pentaho.org/mailman/listinfo/mondrian
>>
>>
>>
>>
>>     _______________________________________________
>>     Mondrian mailing list
>>     Mondrian at pentaho.org  <mailto:Mondrian at pentaho.org>
>>     http://lists.pentaho.org/mailman/listinfo/mondrian
>
>
>     _______________________________________________
>     Mondrian mailing list
>     Mondrian at pentaho.org <mailto: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/20130605/b844f2bc/attachment.html 


More information about the Mondrian mailing list