[Olap4j-devel] [Mondrian] Convert Connection to OlapConnection
lucboudreau at gmail.com
Tue Apr 6 21:28:08 EDT 2010
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
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
On Tue, Apr 6, 2010 at 7:49 PM, Julian Hyde <jhyde at pentaho.com> 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.
> 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
> *From:* Luc Boudreau [mailto:lucboudreau at gmail.com]
> *Sent:* Tuesday, April 06, 2010 3:58 PM
> *To:* Mondrian developer mailing list
> *Cc:* olap4j-devel at lists.sourceforge.net
> *Subject:* Re: [Olap4j-devel] [Mondrian] Convert Connection to
> 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 :
> Luc Boudreau
> On Tue, Apr 6, 2010 at 5:38 PM, Luc Boudreau <lucboudreau at gmail.com>wrote:
>> This topic was discussed in olap4j forums.
>> 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 <jchappelle at 4redi.com>wrote:
>>> 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?
>>> Mondrian mailing list
>>> Mondrian at pentaho.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mondrian