Hitachi Vantara Pentaho Community Forums
Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: [Mondrian] Convert Connection to OlapConnection

  1. #1
    Josh Chappelle Guest

    Default [Mondrian] Convert Connection to OlapConnection

    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
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  2. #2
    Luc Boudreau Guest

    Default Re: [Mondrian] Convert Connection to OlapConnection

    This topic was discussed in olap4j forums.

    http://sourceforge.net/projects/olap.../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 <jchappelle (AT) 4redi (DOT) com> 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
    > Mondrian (AT) pentaho (DOT) org
    > http://lists.pentaho.org/mailman/listinfo/mondrian
    >
    >


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  3. #3
    Luc Boudreau Guest

    Default Re: [Mondrian] Convert Connection to OlapConnection

    As of olap4j revision 307 (
    http://olap4j.svn.sourceforge.net/vi...v&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 <lucboudreau (AT) gmail (DOT) com> wrote:

    >
    > This topic was discussed in olap4j forums.
    >
    > http://sourceforge.net/projects/olap.../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 <jchappelle (AT) 4redi (DOT) com>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
    >> Mondrian (AT) pentaho (DOT) org
    >> http://lists.pentaho.org/mailman/listinfo/mondrian
    >>
    >>

    >


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  4. #4
    Julian Hyde Guest

    Default RE: [Olap4j-devel] [Mondrian] Convert Connection to OlapConnection

    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...e-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:lucboudreau (AT) gmail (DOT) com]
    Sent: Tuesday, April 06, 2010 3:58 PM
    To: Mondrian developer mailing list
    Cc: olap4j-devel (AT) lists (DOT) sourceforge.net
    Subject: Re: [Olap4j-devel] [Mondrian] Convert Connection to OlapConnection



    As of olap4j revision 307 (
    http://olap4j.svn.sourceforge.net/vi...lap4j?view=rev
    <http://olap4j.svn.sourceforge.net/viewvc/olap4j?view=rev&revision=307>
    &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 <lucboudreau (AT) gmail (DOT) com> wrote:



    This topic was discussed in olap4j forums.

    http://sourceforge.net/projects/olap.../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 <jchappelle (AT) 4redi (DOT) com> 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
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian






    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  5. #5
    Luc Boudreau Guest

    Default 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 <jhyde (AT) pentaho (DOT) 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.
    >
    > http://www.olap4j.org/api/org/olap4j...e-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:lucboudreau (AT) gmail (DOT) com]
    > *Sent:* Tuesday, April 06, 2010 3:58 PM
    > *To:* Mondrian developer mailing list
    > *Cc:* olap4j-devel (AT) lists (DOT) sourceforge.net
    > *Subject:* Re: [Olap4j-devel] [Mondrian] Convert Connection to
    > OlapConnection
    >
    >
    > As of olap4j revision 307 (
    > http://olap4j.svn.sourceforge.net/vi...v&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 <lucboudreau (AT) gmail (DOT) com>wrote:
    >
    >>
    >> This topic was discussed in olap4j forums.
    >>
    >> http://sourceforge.net/projects/olap.../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 <jchappelle (AT) 4redi (DOT) com>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
    >>> Mondrian (AT) pentaho (DOT) org
    >>> http://lists.pentaho.org/mailman/listinfo/mondrian
    >>>
    >>>

    >>

    >


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  6. #6
    Julian Hyde Guest

    Default 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...e-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:lucboudreau (AT) gmail (DOT) com]
    Sent: Tuesday, April 06, 2010 6:28 PM
    To: jhyde (AT) pentaho (DOT) com
    Cc: Mondrian developer mailing list; olap4j-devel (AT) lists (DOT) sourceforge.net
    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 <jhyde (AT) pentaho (DOT) 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.

    http://www.olap4j.org/api/org/olap4j...e-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:lucboudreau (AT) gmail (DOT) com]
    Sent: Tuesday, April 06, 2010 3:58 PM
    To: Mondrian developer mailing list
    Cc: olap4j-devel (AT) lists (DOT) sourceforge.net
    Subject: Re: [Olap4j-devel] [Mondrian] Convert Connection to OlapConnection



    As of olap4j revision 307 (
    http://olap4j.svn.sourceforge.net/vi...lap4j?view=rev
    <http://olap4j.svn.sourceforge.net/viewvc/olap4j?view=rev&revision=307>
    &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 <lucboudreau (AT) gmail (DOT) com> wrote:



    This topic was discussed in olap4j forums.

    http://sourceforge.net/projects/olap.../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 <jchappelle (AT) 4redi (DOT) com> 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
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian







    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  7. #7
    Julian Hyde Guest

    Default RE: [Olap4j-devel] [Mondrian] Convert Connection to OlapConnection

    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:jchappelle (AT) 4redi (DOT) com]
    Sent: Wednesday, April 07, 2010 7:35 AM
    To: jhyde (AT) pentaho (DOT) com; 'Mondrian developer mailing list'; 'Luc Boudreau'
    Cc: olap4j-devel (AT) lists (DOT) sourceforge.net
    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: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On
    Behalf Of Julian Hyde
    Sent: Tuesday, April 06, 2010 8:57 PM
    To: 'Luc Boudreau'
    Cc: olap4j-devel (AT) lists (DOT) sourceforge.net; '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...e-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:lucboudreau (AT) gmail (DOT) com]
    Sent: Tuesday, April 06, 2010 6:28 PM
    To: jhyde (AT) pentaho (DOT) com
    Cc: Mondrian developer mailing list; olap4j-devel (AT) lists (DOT) sourceforge.net
    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 <jhyde (AT) pentaho (DOT) 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.



    http://www.olap4j.org/api/org/olap4j...e-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:lucboudreau (AT) gmail (DOT) com]
    Sent: Tuesday, April 06, 2010 3:58 PM
    To: Mondrian developer mailing list
    Cc: olap4j-devel (AT) lists (DOT) sourceforge.net
    Subject: Re: [Olap4j-devel] [Mondrian] Convert Connection to OlapConnection


    As of olap4j revision 307 (
    http://olap4j.svn.sourceforge.net/vi...lap4j?view=rev
    <http://olap4j.svn.sourceforge.net/viewvc/olap4j?view=rev&revision=307>
    &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 <lucboudreau (AT) gmail (DOT) com> wrote:


    This topic was discussed in olap4j forums.

    http://sourceforge.net/projects/olap.../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 <jchappelle (AT) 4redi (DOT) com> 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
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian








    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  8. #8
    Luc Boudreau Guest

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

    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 <jhyde (AT) pentaho (DOT) com> 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:jchappelle (AT) 4redi (DOT) com]
    > *Sent:* Wednesday, April 07, 2010 7:35 AM
    > *To:* jhyde (AT) pentaho (DOT) com; 'Mondrian developer mailing list'; 'Luc Boudreau'
    >
    > *Cc:* olap4j-devel (AT) lists (DOT) sourceforge.net
    > *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:* mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org]
    > *On Behalf Of *Julian Hyde
    > *Sent:* Tuesday, April 06, 2010 8:57 PM
    > *To:* 'Luc Boudreau'
    > *Cc:* olap4j-devel (AT) lists (DOT) sourceforge.net; '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...e-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:lucboudreau (AT) gmail (DOT) com]
    > *Sent:* Tuesday, April 06, 2010 6:28 PM
    > *To:* jhyde (AT) pentaho (DOT) com
    > *Cc:* Mondrian developer mailing list; olap4j-devel (AT) lists (DOT) sourceforge.net
    > *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 <jhyde (AT) pentaho (DOT) 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.
    >
    >
    >
    > http://www.olap4j.org/api/org/olap4j...e-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:lucboudreau (AT) gmail (DOT) com]
    > *Sent:* Tuesday, April 06, 2010 3:58 PM
    > *To:* Mondrian developer mailing list
    > *Cc:* olap4j-devel (AT) lists (DOT) sourceforge.net
    > *Subject:* Re: [Olap4j-devel] [Mondrian] Convert Connection to
    > OlapConnection
    >
    >
    > As of olap4j revision 307 (
    > http://olap4j.svn.sourceforge.net/vi...v&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 <lucboudreau (AT) gmail (DOT) com>
    > wrote:
    >
    >
    > This topic was discussed in olap4j forums.
    >
    > http://sourceforge.net/projects/olap.../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 <jchappelle (AT) 4redi (DOT) com>
    > 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
    > Mondrian (AT) pentaho (DOT) org
    > 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
    > olap4j-devel (AT) lists (DOT) sourceforge.net
    > https://lists.sourceforge.net/lists/...o/olap4j-devel
    >
    >


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  9. #9
    Julian Hyde Guest

    Default RE: [Olap4j-devel] [Mondrian] Convert Connection to OlapConnection

    Luc wrote:

    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.

    That would be great. I can think of a couple of ways to do it.

    One way to do that might be to provide a dummy driver. It might be easy:
    just a driver class, a connection class, and the only thing you can do with
    the connection is to call getParserFactory. Can't tell without looking at
    the code.

    Another way would be to have a way to instantiate a default parser factory.
    Say MdxParserFactory.DEFAULT.createMdxParser(null). I don't mind adding that
    to the olap4j API; I just didn't want an implementation class like
    DefaultMdxParserImpl to be forever part of the official API.

    Julian

    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  10. #10
    Luc Boudreau Guest

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

    I released mdx4j, a wrapper for olap4j's internal parser. It is under EPL so
    anyone can embed it. I think I'll send a submission to the Guinness World
    Records book for the smallest library ever.

    http://code.google.com/p/mdx4j/

    _____________________________
    Luc Boudreau


    On Wed, Apr 7, 2010 at 7:54 PM, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:

    >
    >
    > Luc wrote:
    >
    > 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.
    >
    > That would be great. I can think of a couple of ways to do it.
    >
    > One way to do that might be to provide a dummy driver. It might be easy:
    > just a driver class, a connection class, and the only thing you can do with
    > the connection is to call getParserFactory. Can't tell without looking at
    > the code.
    >
    > Another way would be to have a way to instantiate a default parser factory.
    > Say MdxParserFactory.DEFAULT.createMdxParser(null). I don't mind adding
    > that to the olap4j API; I just didn't want an implementation class like
    > DefaultMdxParserImpl to be forever part of the official API.
    >
    > Julian
    >


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Privacy Policy | Legal Notices | Safe Harbor Privacy Policy

Copyright © 2005 - 2019 Hitachi Vantara Corporation. All Rights Reserved.