[Mondrian] Native Dimension Filter

Julian Hyde jhyde at pentaho.com
Sat Apr 18 17:23:26 EDT 2009


It sounds like a good enhancement.

The facility is of limited use if it only handles IN/NOT IN, so I would like
you to go a bit further. Can you also handle IS/IS NOT and expressions on
properties (all of which should translate to nice simple SQL predicates).
For example,

   Filter(
      [Product].[Product Family].Members,
      [Product].CurrentMember IS NOT [Product].[All Products].[Drink])

is equivalent to your example query; and

   Filter(
      [Product].[Product Family].Members,
      [Product].CurrentMember.Properties("Color") != "Red")

is typical of a query restricting on properties.

Do you have an estimated timescale for developing/delivering this feature?

Julian


> -----Original Message-----
> From: mondrian-bounces at pentaho.org 
> [mailto:mondrian-bounces at pentaho.org] On Behalf Of Rushan
> Sent: Thursday, April 16, 2009 6:52 PM
> To: 'Mondrian developer mailing list'
> Subject: [Mondrian] Native Dimension Filter
> 
> We have come across many reports here at LucidEra where the customer 
> always wants to exclude a few "exception" dimension values. The MDX 
> either enumerates all the desired values, or use a NOT IN 
> filter such as 
> the one below:
> 
>   Filter([Product].[Product 
> Family].Members,[Product].CurrentMember Not In 
> {[Product].[All Products].[Drink]})
> 
> Currently, this filter is not translated to SQL when Mondrian 
> loads the 
> Product Family members. I did some experiment and found that if they 
> were natively evaluated, and especially if the members 
> excluded are from 
> the lowest levels of a deep hierarchy, evaluating the filter natively 
> can help quite a bit with the MDX query performance.
> 
> I did some prototyping and sketched out the design here:
> 
> http://pub.eigenbase.org/wiki/MondrianNativeFilterImprovement
> 
> Note that the only dimension filter considered at this point 
> is In/Not 
> In. There are other candidates such as Matches/Not Matches filter. I 
> punted on this one because DBs have different levels of SQL regexp 
> support. Some are buggy such as LucidDB.
> 
> Please take a look and let me know if you have any questions with the 
> overall idea. Also, if you have use cases of other dimension filters 
> that fit in the constraints listed in the wiki, it will be 
> good to see 
> if they could be made native by using a similar approach.
> 
> Rushan
> 
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
> 
> 
> 





More information about the Mondrian mailing list