TM1 Forum

Hello,

Sadly The wiki-article (http://wiki.olapforums.com/index.php?title=TM1_Feeders) lacks advanced information.
When I started three years ago, I was told, that I can feeed N=>C, must not feed C=>*
I read in forums, that C=>C is possible, but not a very perfromant idea.

In my model the only possibility was (an intercube) feeder C=>C on multiple dimensions of the cube.
The virtually Virtual Cube (there are some values in some scenarios, but most is calculated) is feedered by Cube A, like this:

['N1', 'C1', 'C2'] => DB('N1','N2','C1','C2','N2','C3');

which does not work. If the feeder is split to

['N1', 'C1N1', 'C2'] => DB('N1','N2','C1N1','C2','N2','C3');
['N1', 'C1N2', 'C2'] => DB('N1','N2','C1N2','C2','N2','C3');

it will work, altough tehre is still a C element involved on right and left side...

This is confusing, isn't it?

My Questions are:
c=>n ... works
n=>c ... works
c=>n better or equal n=>c ?
c=>c ... works
c=>c ... avoid when possible (whenever the consolidations children won't change - like cummulated months)

Did you have simmilar problems, where seemingly equivalent feeders work - or don't?

I know, that this isn't a very good formulated question - please forgive me this time - I'm desperate, again.

kr,
Lukas

Feeders can be written at the consolidated level on either side of the '=>' sign, but it is merely a shorthand.

An example for the sake of explanation only as it makes no sense, but hopefully explains the principal: Say I have 'All fish' is a consolidation of cod, carp and tuna. 'All mammals' is a consolidation of monkeys, humans and platypus (platypi?!) I can write a shorthand feeder like so...
or I can write it out explicitly like so A third option is All three are calculated exactly the same way, but obviously the first one is much faster to type out.

HTH,
Martin

Thank you!

So there is no reason why

['All Fish'] => ['Monkeys'];

doesn't work but

['Cod'] => ['Monkeys'];
['Carp']=> ['Monkeys'];
['Tuna']=> [Monkeys''];

works?
(There is no rule for C:'All Fish', but N:Cod, N:Carp and N:Tuna have heavy, but feedered, rules (therefore rules, which use a lookup cube, attributes, other rules, that use lookup cubes and attributes and ...))

This is my issue - the reason why i started this thread...
It makes no sense, doesn't it?

Lukas,
It will probably help if you post the exact thing that is not working plues details of the dimension, the key things to remember are
Feeders only happen at the N level, irrespective of how they are written.
If a ruled value is used to fed something else then it must be fed itself.
The only way to be sure that the results you are seeing are going to be true behaviour of the system when you are developing the rules and feeders is to unload the cube (for a single cube system) or restart the server. This is because feeder flags persist in the system after a rule save. It can be easy to get into the following situation.

1. Write the rule.
2. Write the correct feeder, the correct feeder flags are present in the system.
3. Write another rule.
3. Change the feeder from 2, so that rule 1 is no longer fed.
4. Rule 1 continues to work since the feeder flags from step 2 are still present even the feeder from step 2 is not present.
5. Rule 1 stops working following a restart of the server.

HTH

Steve Rowe wrote:Feeders only happen at the N level, irrespective of how they are written.

Hi Lukas,

Steve's point is a very good one and it is something that is not understood, or not understood very well, and is probably one of the more common causes for feeders not working when feeding from a consolidated cell. To keep going with Martin's somewhat odd example let's say you had the following feeder:
['All Mammals'] => DB('cube', !Version, !Year, !Month, !Vertebrates, 'measure');
When the feeder is evaluated, !Vertabrates will return the N level element names under the 'All Mammals' consolidation that contain values. That is !Vertebrates will evaluate to 'Monkeys', 'Humans', etc. and will never evaluate to 'All Mammals'. This usually catches people out when feeding an asymmetric cube where a C element in the source cube corresponds to an N in the target cube. Not sure if this applies in your case but something to watch out for. If this is your problem then you need to transform the N element name via an attribute in the feeder, something like this:
['All Mammals'] => DB('cube', !Version, !Year, !Month, AttrS('Vertebrates', !Vertebrates, 'Parent'), 'measure');

Martin Ryan wrote:
A third option is

Code: Select all

['Cod'] => ['Monkeys'], ['Humans'], ['Platypus'];
['Carp']=> ['Monkeys'], ['Humans'], ['Platypus'];
['Tuna']=> [Monkeys''], ['Humans'], ['Platypus'];

A 4th one:
[{'Cod','Carp','Tuna'}] => ['Monkeys'], ['Humans'], ['Platypus'];

Regards,
Peter