Re: [Olap4j-devel] [Mondrian] Convert Connection to OlapConnection

[Luc B. <luc...@gm...>]

Julian. Discussing with Jonathan Fuerth, I came to understand your point.
Olap4j does not promote a given MDX syntax nor should it ever do. I will
start a spin-off project able to provide external code with a MdxParser that
does not require a backend server connection.

I'll update this thread with links to the actual released code.

_____________________________
Luc Boudreau


On Wed, Apr 7, 2010 at 2:04 PM, Julian Hyde <jh...@pe...> wrote:

>  You should be able to use the olap4j public API for this. Hand-parsing,
> as you correctly observe, is brittle, and we made the parser part of the
> public API to solve this problem.
>
> Create an olap4j connection, downcast to OlapConnection, then call
> getParserFactory(), call createParser on that factory, then use the parser
> to parse a string. Your code does not need to reference
> DefaultMdxPArserImpl at all.
>
> Note that after you have manipulated the parse tree, you can re-creeate the
> MDX by calling String ParseTreeNode.unparse(ParseTreeWriter).
>
> And also node that you can create parse trees 'by hand' without using a
> parser.
>
> If you are using the mondrian olap4j driver the olap4j connection will
> contain a mondrian connection. You can unwrap it using the following code:
>
> java.sql.Connection olap4jConnection;
> mondrian.olap.Connection mondrianConnection =
>   olap4jConnection.unwrap(mondrian.olap.Connection.class);
>
> The connection will be an instance of
> mondrian.olap4j.MondrianOlap4jConnection but, as with DefaultMdxParserImpl,
> your code never needs to (nor should) reference that class directly.
>
> Julian
>
>
>  ------------------------------
> *From:* Josh Chappelle [mailto:jch...@4r...]
> *Sent:* Wednesday, April 07, 2010 7:35 AM
> *To:* jh...@pe...; 'Mondrian developer mailing list'; 'Luc Boudreau'
>
> *Cc:* ola...@li...
> *Subject:* RE: [Olap4j-devel] [Mondrian] Convert Connection to
> OlapConnection
>
>  The gui use case is exactly what we are doing. We have a web based
> application and we use wicket for our presentation layer. We have created a
> primitive mdx designer to create mdx views and save the mdx string to a
> database. When the user wants to edit the mdx then it poses an issue of
> parsing. We can do some ugly string manipulation but it starts to get ugly
> and as we all know that kind of thing is brittle. That’s why we need the
> parser. I’m assuming I can create a ParseTreeVisitor implementation that can
> parse the string and build up our objects.
>
>
>
> If there is another class that is better suited for that please feel free
> to let me know.
>
>
>
> Thanks,
>
>
>
> Josh
>  ------------------------------
>
> *From:* mon...@pe... [mailto:mon...@pe...]
> *On Behalf Of *Julian Hyde
> *Sent:* Tuesday, April 06, 2010 8:57 PM
> *To:* 'Luc Boudreau'
> *Cc:* ola...@li...; 'Mondrian developer mailing
> list'
> *Subject:* RE: [Olap4j-devel] [Mondrian] Convert Connection to
> OlapConnection
>
>
>
> I agree with the 4 bundles of functionality you have proposed. But did you
> realize that the parser bundle is already present? It's in the
> org.olap4j.mdx.parser package:
>
>
>
> http://www.olap4j.org/api/org/olap4j/mdx/parser/package-summary.html
>
>
>
> The GUI use case you cite is a good one. But it can be done today using
> MdxParser, MdxParserFactory, and the parse tree object model classes in the
> org.olap4j.mdx package. And by the way, to get a parser factory, you call
> OlapConnection.getParserFactory.
>
>
>
> Behind the scenes, the olap4j driver is probably using
> DefaultMdxParserImpl. (It is for both olap4j drivers that exist today.) But
> the app does not need to know about DefaultMdxParserImpl in order to do what
> it needs to do, only MdxParser.
>
>
>
> Julian
>
>
>  ------------------------------
>
> *From:* Luc Boudreau [mailto:luc...@gm...]
> *Sent:* Tuesday, April 06, 2010 6:28 PM
> *To:* jh...@pe...
> *Cc:* Mondrian developer mailing list; ola...@li...
> *Subject:* Re: [Olap4j-devel] [Mondrian] Convert Connection to
> OlapConnection
>
>
> Database drivers who implement their own parser and grammar are free to not
> use the one provided by olap4j. An OlapConnection still has to provide a
> parser factory to public code. Nothing should change there. Yet this does
> not constitute an argument for not exposing the internal parser. Olap4j
> contains the only MDX parser available as far as I know and it would be a
> shame to bury it at the bottom of the library.
>
> I agree with keeping DefaultMdxParserImpl part of the SPI only. There is no
> need to expose it and as I said in my previous email, I'd much rather see a
> unified standard way of obtaining a MdxParser implementation. I'm not
> talking about core API changes. Here's a very common and realistic use case
> for it; a syntax-aware GUI editor for MDX queries which is not a query tool.
>
> If your objection is related to the separation of intent of the different
> components of olap4j, then I can assure you that I am fully aware of the
> mixup that is already in place. Olap4j includes already an four distinctive
> components bundled together... We talked about separating those in the past
> and never got to doing it. Should we decide to do the actual work, I believe
> that the natural separation of components should be as follows.
>
>    - API (org.olap4j.* pagkages, minus the ones below)
>    This is the bulk of the olap4j code.
>    - XML/A Generic Driver (org.olap4j.driver.xmla.*)
>    The XML/A driver depends on the API only.
>    - Query Model (org.olap4j.query.*)
>    The query model classes would depend on the API only.
>    - MDX Parser (some package that is non existent yet)
>    The MDX parser would be a very simplistic wrapper over the default
>    parser SPI classes and exposed as a MdxParser factory. It would depend on
>    the API core only.
>
> Each of those components can be part of the olap4j source tree for now, but
> I'd like to take the opportunity to initiate a discussion about their
> separation and get feedback about the ramifications. I don't mind doing the
> actual work.
>
> _____________________________
> Luc Boudreau
>
>  On Tue, Apr 6, 2010 at 7:49 PM, Julian Hyde <jh...@pe...> wrote:
>
> I stand by the comments I made in that forum post. MdxParser is part of
> olap4j's public API, but DefaultMdxParserImpl is not and will never be.
>
>
>
> http://www.olap4j.org/api/org/olap4j/mdx/parser/package-summary.html
>
>
>
> The public API, remember, is for people building OLAP applications. To
> them, olap4j needs to look like JDBC, but with one exception. JDBC drivers
> don't supply a SQL parser, but parsing is more important to MDX applications
> so every olap4j driver must supply an MDX parser that implements the
> MdxParser interface.
>
>
>
> The other important audience is developers of drivers. To a limited extent,
> the olap4j code base gives them an SPI to help them build drivers.
> DefaultMdxParserImpl is part of that SPI, as are the classes in
> org.olap4j.impl. We will try to keep the SPI stable as olap4j eveolves but
> we won't bust a gut over it.
>
>
>
> Remember that different drivers might be talking to different OLAP engines,
> and different engines have different dialects of MDX, so naturally the
> driver writers might want to create their own parser. They can write a
> parser from scratch, or they can start with the default MDX parser.
>
>
>
> If you want to dismember the olap4j project to get the MDX parser, then go
> ahead. olap4j is after all an open source project. But you're on your own.
> You are in a small minority of olap4j users, and we don't intend to change
> the olap4j API for your benefit.
>
>
>
> It sounds like
>
>
>
> Julian
>
>
>
>
>  ------------------------------
>
> *From:* Luc Boudreau [mailto:luc...@gm...]
> *Sent:* Tuesday, April 06, 2010 3:58 PM
> *To:* Mondrian developer mailing list
> *Cc:* ola...@li...
> *Subject:* Re: [Olap4j-devel] [Mondrian] Convert Connection to
> OlapConnection
>
>
> As of olap4j revision 307 (
> http://olap4j.svn.sourceforge.net/viewvc/olap4j?view=rev&revision=307 )
> the default MDX parser does not depend on OlapConnection. It should not have
> been dependent on it in the first place.
>
> Mondrian developers: please modify the olap4j connection implementation and
> remove the now deprecated call to DefaultMdxParserImpl(OlapConnection).
> Modifications to the generic XML/A driver have already been performed.
>
> This does not mean that DefaultMdxParserImpl is part of the public API yet.
> There should be a default parser factory exposed to developers. In the
> meanwhile, developers can directly instantiate it, but be advised that we do
> not provide any guarantees on this object's signature and we reserve the
> right to modify it in the future. To create a parser, developers can call
> the empty constructor.
>
> A compiled binary which includes those changes can be picked from the CI
> server as of now :
>
> http://ci.pentaho.com/view/Analysis/job/olap4j/258/
>
> _____________________________
> Luc Boudreau
>
>  On Tue, Apr 6, 2010 at 5:38 PM, Luc Boudreau <luc...@gm...>
> wrote:
>
>
> This topic was discussed in olap4j forums.
>
> http://sourceforge.net/projects/olap4j/forums/forum/577988/topic/3545015
>
> Although Julian's last comment mentioned that the parser is not officially
> part of the public API, I for one would like to make it part of the public
> API. There are many use cases for it and your request confirms it.
>
> I'll see what I can do to detach the parser from the connection classes.
>
> _____________________________
> Luc Boudreau
>
>   On Tue, Apr 6, 2010 at 5:32 PM, Josh Chappelle <jch...@4r...>
> wrote:
>
>   Hi,
>
>
>
> We have a need to use the MdxParser component from the Olap4j project.
> However up until this point we have not been using olap4j at all. To
> instantiate a DefaultMdxParserImpl you have to provide an
> org.olap4j.OlapConnection object in the constructor. Our software is using a
> mondrian.olap.Connection. Is there a way to convert between these two
> connection objects? If not does it mean that we will have to use the
> org.olap4j.OlapConnection in order to use the MdxParser?
>
>
>
> Thanks,
>
>
>
> Josh
>
>
>
> _______________________________________________
> Mondrian mailing list
> Mon...@pe...
> http://lists.pentaho.org/mailman/listinfo/mondrian
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> olap4j-devel mailing list
> ola...@li...
> https://lists.sourceforge.net/lists/listinfo/olap4j-devel
>
>