[Mondrian] Cognos 8.3 & "VBA!" Functions

Thu Apr 24 13:13:25 EDT 2008

Tim,
I think the form you describe is correct, Tim:

   [library![class!]]function(args)

I'm not terribly familiar with VB, though.  Spofford describes the reference
as the VBA class ID-- do you know if such an ID can have further structure,
like library!package!class!function?

Also, I'm curious if there are any variations with SSAS 2005, since it
supports definition of UDF's via .NET classes.  I'm guessing that in that
case it might allow the full .NET namespace specification, which could be
arbitrarily deep.  If I get a chance I'll do some research on 2005 style
UDFs.

-m

On Thu, Apr 24, 2008 at 11:46 AM, <timothy.lambert at thomsonreuters.com>
wrote:

> So the library/package name itself can not be multi-leveled?
>
> So the general form is...
>
>    [library![class!]]function(args)
>
> Correct?
>
> ________________________________________
> From: mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org]
> On Behalf Of Matt Campbell
> Sent: Thursday, April 24, 2008 11:26 AM
> To: Mondrian developer mailing list
> Subject: Re: [Mondrian] Cognos 8.3 & "VBA!" Functions
>
>
> 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
>
>
> _______________________________________________
> 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/11432415/attachment.html 