MDX Parser

[luizfox]

About the issue MDX -> Query Model..

the "parser engine" should be able to parse any MDX typed or just the
MDX like those that Halogen itself generates?

This last case, I've built a parser that could deal with such cases.
With this option, the issue is almost done.

In the first case, a implementation of the interface
org.olap4j.mdx.parser.MdxParser, I was thinking into port the package
that is used on Pentaho Report Designer,
nickyb.sqleonardo.querybuilder.syntax, to the MDX language. This
solution is better and could even be used on Olap4J (more challenger,
too).

So, what do you think? What's the suitable option? And is there any
other "parser engine" that I could use, that is better than
SQLeonardo?

[luizfox]

Or Mondrian's parser.

[Julian Hyde]

> About the issue MDX -> Query Model..
>
> the "parser engine" should be able to parse any MDX typed or just the
> MDX like those that Halogen itself generates?
>
> This last case, I've built a parser that could deal with such cases.
> With this option, the issue is almost done.
>
> In the first case, a implementation of the interface
> org.olap4j.mdx.parser.MdxParser, I was thinking into port the package
> that is used on Pentaho Report Designer,
> nickyb.sqleonardo.querybuilder.syntax, to the MDX language.
>

> So, what do you think? What's the suitable option? And is there any
> other "parser engine" that I could use, that is better than
> SQLeonardo?

Olap4j contains an implementation of an MDX parser. The default
implementation is org.olap4j.mdx.parser.impl.DefaultMdxParserImpl, but you
shouldn't use that class directly. Get it via the connection's parser
factory:

OlapConnection connection;
MdxParser parser =
connection.getParserFactory().createMdxParser(connection);
SelectNode select = parser.parseSelect("SELECT FROM [Sales]");

If different servers have different variants of MDX, the driver will need to
create a specific parser by overriding the parser factory. I don't expect
that that will need to happen very often, because providers usually extend
MDX by adding new functions, not by adding new syntactic constructs.

But for a client application it is simple: just use the parser that your
olap4j connection gives you.

> This
> solution is better and could even be used on Olap4J (more challenger,
> too).

What's good about it? I'd like to learn/reuse if possible.

Julian

[luizfox]

> What's good about it? I'd like to learn/reuse if possible.

Yes, me too. I didn't know that Olap4J already contains a parser.
Thanks.

[william...@gmail.com]

I think when it come to Halogen what we need is the ability to parse
MDX into a Olap4J query model. Can Olap4J do that now? If it can
then things get really easy from the Halogen perspective.

[luizfox]

That's my doubt too. It *seems* that is possible, but I'm not able to
parse it yet.
I'll try with the Olap4J guys at their forum. The documentation seems
to be outdated.

[Julian Hyde]

> luizfox wrote:
> That's my doubt too. It *seems* that is possible, but I'm not able to
> parse it yet.
> I'll try with the Olap4J guys at their forum. The documentation seems
> to be outdated.

The olap4 functional spec has some sample code:

OlapConnection connection;
MdxParserFactory parserFactory =
connection.getParserFactory();
MdxParser parser =
parserFactory.createMdxParser(connection);

SelectNode select =
parser.parseSelect("SELECT FROM [Sales]");

MdxValidator validator =
parserFactory.createMdxValidator(connection);
select = validator.validate(select);

http://www.olap4j.org/olap4j_fs.html#MDX_parser

Does this code work? It should.

Julian

[luizfox]

Hi Julian. Thanks for helping me.

It does work, as well as the last code you post, without the factory.
But how about the members? Can you give me an example too?
Like:
SELECT {[Education Level].[All Education Levels], [Education Level].
[All Education Levels].Children} ON COLUMNS,
{[Geography].[All Geographys], [Geography].[All Geographys].[USA]} ON
ROWS
FROM [Sales Ragged]

how can I get "[Education Level]", "[All Education Levels]" (class
Member?) and children (class Selection.Operator?) values?

I've tryied play with Query, QueryAxis and QueryDimension classes, but
no success at all.

And by the way, the documentation I've mentioned that is outdated is
here:
http://olap4j.svn.sourceforge.net/viewvc/olap4j/trunk/doc/olap4j_fs.html#MDX_query_model

Thanks for any advance,
Luiz.

[luizfox]

Just adding to the previous post:
The only information I'm able to get back it the cube:
selectNode.getFrom().toString()

On 4 ago, 14:13, luizfox <luiz...@yahoo.com> wrote:
> Hi Julian. Thanks for helping me.
>
> It does work, as well as the last code you post, without the factory.
> But how about the members? Can you give me an example too?
> Like:
> SELECT {[Education Level].[All Education Levels], [Education Level].
> [All Education Levels].Children} ON COLUMNS,
> {[Geography].[All Geographys], [Geography].[All Geographys].[USA]} ON
> ROWS
> FROM [Sales Ragged]
>
> how can I get "[Education Level]", "[All Education Levels]" (class
> Member?) and children (class Selection.Operator?) values?
>
> I've tryied play with Query, QueryAxis and QueryDimension classes, but
> no success at all.
>
> And by the way, the documentation I've mentioned that is outdated is

> here:http://olap4j.svn.sourceforge.net/viewvc/olap4j/trunk/doc/olap4j_fs.h...

[luizfox]

Errata:
> The only information I'm able to get back *IS* the cube:
Sorry.

[Julian Hyde]

Luiz,

> I've tryied play with Query, QueryAxis and QueryDimension classes, but
> no success at all.
>
> And by the way, the documentation I've mentioned that is outdated is

> here: ...

If you want examples, look at the olap4j test suite. There are lots of them,
and they are all guaranteed to work. :)

> Bill Seyler wrote:
> I think when it come to Halogen what we need is the ability to parse
> MDX into a Olap4J query model. Can Olap4J do that now? If it can
> then things get really easy from the Halogen perspective.

I don't think it can. Query models are very incomplete right now. Not ready
for development unless you are willing to roll up your sleeves. I'd like to
have a discussion about the design of query models on the olap4j forums.

See also this thread discussing the difference between the MDX parse tree
model and the Query model in olap4j:

https://sourceforge.net/forum/message.php?msg_id=5011964

Julian

[william...@gmail.com]

Thanks for the background Julian,

I was hoping that we could make this bidirectional. So that if
someone wanted to start with a specific MDX query in Halogen they
could then continue manipulating it with the Query model interface and
(in a perfect world) when they went to persist the Query model it
would just persist the current MDX representation of that model.

If that can't be done then I have to serialize the query model. For
Halogen interoperability with other tools that only speak MDX it would
be a problem.

I really don't want to back Halogen down from using the Query model.
I really think that's the future of GUI manipulation of
Multidimensional data. Given that, I think the final answer is to as
you said:

"each component of the query model needs to be able to convert itself
to AND FROM mdx. Or equivalently, to an from a parse tree. That is, a
construct needs to be able to recognize itself in a parse tree. This
is quite hard to do, given that people can write MDX by hand. I would
like to hear proposals from developers for how to do that; maybe a
chain of responsibility pattern, where the various known query
constructs each look for themselves. But it's important that we get
the conversion to and from MDX parse trees working, so that we can
freely add query constructs."

In the interim for Halogen to proceed further I think we need to be
able to parse the MDX that it creates. When we can get Olap4J and the
query model to a state where it can perform that function we'll move
to that.

[luizfox]

Thanks for the help too, Julian.

The parser works for some cases, but not for all cases that Halogen
generates.
I really don't understand why it generates such "strange" MDXs, but it
seems that when we have a set of braces inside another one, like
"{something {more stuff}}", olap4j can't deal with it. The other
cases, works fine.

This problem gave me some headaches when developing my own parser (for
Halogen self-generated MDX), and I've got the feeling that I was
making some workaround. This is what worries me.

I'll provide you with two MDX strings that seems that olap4j can't
deal with:

SELECT
{[Education Level].[All Education Levels], [Education Level].[All

Education Levels].Children, {[Education Level].[All Education Levels],

[Education Level].[All Education Levels].Children}} ON COLUMNS,
{[Geography].[All Geographys], [Geography].[All Geographys].[USA]} ON
ROWS
FROM [Sales Ragged]

SELECT
{[Education Level].[All Education Levels], [Education Level].[All

Education Levels].Children, {[Education Level].[All Education Levels],
[Education Level].[All Education Levels].Children}, [Education Level].
[All
Education Levels].Siblings} ON COLUMNS,
{[Geography].[All Geographys], [Geography].[All Geographys].[USA],

[Geography].[All Geographys].[USA]} ON ROWS
FROM [Sales Ragged]

The code:
for (AxisNode axisNode: selectNode.getAxisList()){
ParseTreeNode ptn = axisNode.getExpression();
CallNode callNode = (CallNode) ptn;
Syntax syntax = callNode.getSyntax();
syntax.hashCode();
for (ParseTreeNode parseCallNode : callNode.getArgList()){
IdentifierNode identifierNode = (IdentifierNode)parseCallNode;
(...)

Exception (on the last line):
unexpected exception: java.lang.ClassCastException:
org.olap4j.mdx.CallNode cannot be cast to
org.olap4j.mdx.IdentifierNode

The same code does work with MDX that doesn't have such nested set of
braces.

I see the fact that many people will take a look at Halogen's code to
see a working example of Olap4J. I'd like to hear your suggestions
because for me, this issue (in Halogen's context) doesn't make sense
unless it fully uses Olap4J, as the project is a proof of concept,
even when my parser can deal satisfactorly with such cases.

Best regards,
Luiz Felipe

[luizfox]

A workaround I've found is unparse CallNode's string. However I think
it's no the most intuitive way to do it. I still have to deal with
string formating tricks.
I guess a class org.olap4j.mdx.SetExpression, with a method called
getSubSets would be fine.

What do you think?

[luizfox]

> I really don't understand why it generates such "strange" MDXs

Ok, I do understand it =]

[Julian Hyde]

A couple of months ago, I suggested on the olap4j forum that we had a design
discussion to figure out how the olap4j query & transform model should work.
No one seemed to be interested at the time.

Now you seem to be hack, hack, hacking away at a query & transform model.
Why don't we just have that design discussion?

Julian

[luizfox]

> No one seemed to be interested at the time.

Because I wasn't working heavy on this issue. I was justing knowing
the field to future works (now) as I wasn't very much familiarized
with olap4j.

> Why don't we just have that design discussion?

Ok, moving the discussion to the appropriate forum =]

[luizfox]

> Because I wasn't working heavy on this issue. I was justing knowing
> the field to future works (now) as I wasn't very much familiarized
> with olap4j.

Correcting: the biggest issue on that time, to me, was with GWT.

Cheers,
Luiz Felipe.