How to write Feeder with when there is no input Measure

[zachinton]

Hi all,

I've come up against this a couple of times and can't figure it out. If I have a Measure defined using a very simple rule which has no input Measures (more specifically, no input values from other cells in the cube) - eg a Counter used for averages - how does one make this consolidate?

e.g.

Code: Select all

SKIPCHECK;
['Counter'] =N: 1;
FEEDERS;

The above example will not sum at C: points because it is now rule-driven.

The answers I can see are:
a) Load the value through TI rather than the rules file. Downside is that this is a little less flexible, especially when quickly 'testing' rules by temporarily hard-coding a value in the Rules file. Also, it can reduce readability if the rest of your related logic is in the Rules file. However, I guess this is the most efficient solution.
b) Use a 'dummy' feeder and feed 'Counter' from a different Measure, even though there isn't a relationship between them. Downside is that this seems likely to be inefficient as there is an unnecessary (?) feeder. Also, I guess it might result in incorrect values if the feeding Measure is zero when the Counter isn't (?).
c) Use ConsolidateChildren, but everything I read about that makes it sound like a bad idea (and it applies to specific dimensions rather than generally over all dimensions).

Sorry if this has been covered before. I've been searching through the forums but there are so many questions about Feeders it's like finding a needle in a haystack!

Many thanks,
Zac

[Harvey]

You'll probably get a few answers that suggest there's no good justification to do what you are doing with the rule. However, I have come across similar situations before myself and felt entirely justified, so I won't tell you that! If you want a 1 somewhere, but you don't want it to be editable, even by yourself, it can make sense.

In my case, I simply fed from another value -- if I could think of one that made sense -- or created a dummy value where there wasn't one and made sure it was populated correctly.

The options you presented all sound reasonable to me, I'm really just posting to let you know you're not going crazy.

[tomok]

The answer is, of course, dependent on the business purpose for the "Counter" value. In your given example, a counter for calculating averages, I would just load the counter to the cube as values, not use a rule. Since you are going to have to have a "loaded" value in order to feed then why not just load a "1" into every cell via a TI and skip the rule? It's very easy to create a TI to do just that. This is what I have done when I wanted that functionality. Another option is to isolate the value into a separate cube and take off the SKIPCHECK statement. You can still reference the value in a rule, even if it is in a separate cube. Just be careful not to include unnecessary dimensions in the separate cube so as not to kill performance.

[zachinton]

Thanks Harvey & Tomok. Both sensible suggestions and comments.

For the example I gave - a counter for an average - I agree that a loaded value through a TI process fits best and I used this recently. However, in my case, I had a second averaging measure 'next to' this one, where the averaging counter is rule-based (as we are averaging values across a dimension only where they meet given criteria based on a different measure). Therefore whilst it works fine, this solution doesn't feel elegant as there are two similar averages implemented in different ways alongside each other - one with a dependency that's rule-based and one without a dependency that's TI based. But it works fine.

In a couple of different cases recently when testing a rule, I wanted to hard-code a value into a cell quickly and found that writing a rule and adding a feeder from a sensible similar value seemed the best/easiest way. However, this is a short-term quick-fix during development, and given that feeders are persistent through a server-session you have to be careful that this doesn't trip you up later when you remove it from the Rule file.

I'm sure there are other use-cases too as you pointed out Harvey. I think you're right Tomok that it's highly dependent on the business purpose. But I'll admit that as a newbie it took me some time to get my head around the best solutions to this (feeders to me are the least intuitive part of TM1).