[Mondrian] NoneEmpty caching question

Luc Boudreau lucboudreau at gmail.com
Mon Jan 19 09:41:02 EST 2015


That's because if I say that I want the NON EMPTY members of a given level,
it is dependent on the measure that I've evaluated. The empty members will
not be the same for a different measure / calculated member.

The cache of level members only applies to fully populated sections of the
level.

Once the full list of members is cached, it is easy for subsequent to cross
reference it with the cache of cells and filter out the empty tuples.

About mondrian.native.nonempty.enable. This property controls whether the
empty tuples are computed by the DBMS (native) or not. As a general rule of
thumb, it i always faster to compute non-empty tuples in the DBMS, because
we combine this operation with other optimizations, like cross joins and
filters.

On Fri, Jan 16, 2015 at 2:34 PM, Ganong, Kenneth <
ken.ganong at truvenhealth.com> wrote:

>  I am trying to understand the significance of storing vs. not storing
> non-empty members in cache. The test case “testLevelMembersWithoutNonEmpty”
> in the NonEmptyTest.java seems to be asserting that the NON EMPTY
> [Customers].[Name].Members is NOT in cache while it also asserts that
> [Customers].[Name].Members is in cache. Could someone please help me
> understand the purpose of this – why NON EMPTY members should not be in
> cache while we expect the [Customers].[Name].Members to be in cache?
>
>
>
> Setting the property mondrian.native.nonempty.enable=false in
> mondrian.properties seems to do the opposite. What does this property do
> with caching and NON-EMPTY?
>
>
>
>         Ken
>
> _______________________________________________
> 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/20150119/756eb88a/attachment.html 


More information about the Mondrian mailing list