[Mondrian] Cognos 8.3 & "VBA!" Functions

Matt Campbell mkambol at gmail.com
Thu Apr 24 11:25:37 EDT 2008


Spofford' s MDX Solutions book says that you disambiguate the conflicting
function names using the classID of the library it is defined in.  An
example he gives is:

  EFStatsPackage!FunctionClass!PctDiff([time],[time].prevMember)

So it appears you *can* have multi-level qualification.

Also, I ran a quick test in SSAS2005 and spaces are permitted on either side
of the !.


On Wed, Apr 23, 2008 at 9:23 PM, <timothy.lambert at thomsonreuters.com> wrote:

> The way I understood the problem was that VBA!FOO was an alias for FOO.
>  Not that VBA was a package name qualification of the function.
>
> Looking at things as a package name qualifier issue completely changes
> things - I retract everything I said in my original email. :)
>
> Since I didn't realize that VBA is a package name and the ! is a separator,
> I also don't know whether or not they can be multi-leveled.  But I'll try to
> find out and open the bug.
>
> Thanks.
>
>
> -----Original Message-----
> From: mondrian-bounces at pentaho.org on behalf of Julian Hyde
> Sent: Wed 4/23/2008 8:07 PM
> To: 'Mondrian developer mailing list'
> Subject: RE: [Mondrian] Cognos 8.3 & "VBA!" Functions
>
> For tracking purposes, can you please log a bug for this.
>
> How general does MDX syntax allow package names to be? Does it allow
> multiple levels of qualification (e.g. 'Foo!Bar!MyFun()')? Does it allow
> spaces (e.g. 'VBA ! Len("foo")).
>
> We should change the scanner to handle the most general case. I think that
> will mean that a function is a list of names rather than the current single
> name. Then FunTable.getDef() will become
>
>    public FunDef getDef(
>        Exp[] args,
>        Validator validator,
>        List<String> funNames,
>        Syntax syntax)
>
> Initially we can change getDef to ignore all but the last member of the
> name
> list, that is, assume that functions are globally unique.
>
> Julian
>
>
>
> > -----Original Message-----
> > From: mondrian-bounces at pentaho.org
> > [mailto:mondrian-bounces at pentaho.org] On Behalf Of
> > timothy.lambert at thomsonreuters.com
> > Sent: Wednesday, April 23, 2008 3:33 PM
> > To: mondrian at pentaho.org
> > Subject: [Mondrian] Cognos 8.3 & "VBA!" Functions
> >
> > Cognos 8.3 generates MDX VBA functions prefixed with "VBA!";
> > e.g. VBA!LEN(<string>).  The signatures and semantics of the
> > functions are the same.
> >
> > I've investigated a number of ways to enhance Mondrian to
> > support this prefix.
> >
> > With all these following solutions, the Mondrian lexical
> > analyzer needs to be enhanced to support an identifier token
> > that contains a '!'.  This is trivial since the grammar does
> > not specify the use of '!'.  Specifically, at line 640 in
> > Scanner.java#21, add " case '!':
> >
> > After this is done, one of the following can be done...
> >
> > 1) At the scanner level strip "VBA!" from identifiers.
> >
> > 2) When functions are being resolved during parser reduction
> > action processing, strip "VBA!" from the function name being resolved.
> >
> > 3) Some variation of 1 or 2 in which an alias map is used
> > instead of just handling "VBA!".
> >
> > 4) In the Vba class, make a new method for each VBA! alias.
> > Each new method would delegate to its non-VBA! counterpart.
> >
> > 5) Enhance FunDef and Resolver to support the notion of aliases.
> >
> > ----
> >
> > While 1 and 2 are really quick to implement, I view them as
> > hacks.  Hacks because they are disjoint from the code that
> > sets up function definitions, and does not fit well within
> > the OO design of the rest of the system.
> >
> > I view 3 as only slightly better.  Depending on how the map
> > is constructed it may have the same design flaw as 1 and 2.
> >
> > The forth option is also easy and pretty clean.  The only
> > problem is that it only handles the VBA! problem.  Other
> > functions are setup differently and would require a different
> > (albeit similar) approach.  Furthermore it's very verbose.
> >
> > I would like to promote some variation of 5.  The question is
> > how to best incorporate general alias information into the
> > rest of the processing.
> >
> > One idea that I was playing with is to create a Resolver
> > decorator/wrapper that exposes the aliased name but delegates
> > to the same Resolver instance setup for the "normally" named FunDef.
> >
> > There would be a bit of code that processes the aliases and
> > adds Resolver instances to the map that is part of FunTableImpl.
> >
> > Once that map is setup, the rest of the code should operate as is.
> >
> > Feedback appreciated.
> >
> > - Tim
> >
> >
> >
> >
> > _______________________________________________
> > Mondrian mailing list
> > 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
>
>
>
>
>
>
> _______________________________________________
> 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/20080424/242767a9/attachment.html 


More information about the Mondrian mailing list