Cube Dependency with DB Function - How Smart?

[raeldor]

We have an issue at the moment when updating a meta-data cube that is relied on heavily throughout our larger data cubes that it seems to be causing a constant recalc everytime a view is pulled once it's updated. The odd thing is, the measure that is being updated I do not believe is in ANY rules. So I guess my fundamental question is...

Do cube dependencies established by the DB function only force calculation on the dependent cube ONLY if the measure stated in the DB function is updated, or does it recalc if ANY of the measures are updated?

[lotsaram]

We have an issue at the moment when updating a meta-data cube that is relied on heavily throughout our larger data cubes that it seems to be causing a constant recalc everytime a view is pulled once it's updated. The odd thing is, the measure that is being updated I do not believe is in ANY rules. So I guess my fundamental question is...

Do cube dependencies established by the DB function only force calculation on the dependent cube ONLY if the measure stated in the DB function is updated, or does it recalc if ANY of the measures are updated?

TM1's calculation cache does not work how you think it works! There is no intelligence to the cache as to the dependency of calculations on slices of data. It's all or nothing. That is if ANY DATA ANYWHERE in an upstream cube is changed then all cached calculations of all downstream cubes will be dumped.

So what you are experiencing sounds like expected behaviour.

If you want to avoid hang times for user driven queries then after updating the "meta data cube" you would need to run ViewConstruct on the cubes users are querying in order to re-build the calculation caches.

[raeldor]

Appreciate you confirming my suspicion, many thanks.

[qml]

There is a bit of a hack, if you'd like to call it that, which lets you to get around the cube dependency cache invalidation problem.

Lotsa is right in saying that all DATA changes in upstream cubes will invalidate the cache in downstream cubes.

However, the same does not apply to METADATA changes. TM1 does not have a concept of the equivalent of cube dependency for dimensions.

So let's say you have a dimension element information function in your rules for cubeX, for example ELCOMP(dimA, ..., ...). As long as dimA is not part of cubeX, any updates to dimA do not invalidate the cache of cubeX. And you can find creative ways of storing DATA in the form of METADATA (element names, weights etc) and use this bug/feature to your advantage. We use this trick to represent all the attributes of our main time dimension in the form of element names of a separate, technical dimension. That way we avoid having cube dependency between the attribute cube of said time dimension and almost every other cube in our complex application with several hundred cubes.