TM1 Forum

Hi all, just want to know under which circumstances, we need to set this parameter as false and refresh dependencies manually in TI?

macsir wrote:Hi all, just want to know under which circumstances, we need to set this parameter as false and refresh dependencies manually in TI?

Never.
What would be the point of dependencies not being read from rules and feeders on startup?

I once worked with a model where a start up chore essentially destroyed all rules and then rewrote them. As part of a standard operating day various TIs would do similar things and rewrite rules (changing sources and targets)... it was a strange and very specific use case.

That could have benefited from this as it would start up quicker but if I recall it started in about a minute anyway...

But as Lotsa says 99.999999% of cases wouldn't have any reason to ever consider it.

Thanks, guys.

I am just checking a model which is using process and dependency cube to refresh dependencies although this parameter is set true. Since I never touched this parameter, so just curious about it.

In a release that I worked on a while back the server was not picking the attribute links in the rules. These are still regarded as cube links under the hood and the server was then setting these up on the fly on first use leading to locking problems with TI processes.

We were therefore setting the cube links up as part of single threaded launch job in our multi threaded sequence.

May have been fixed in current releases, have not gone back to check.

(I think I may have mis-read the question...)

macsir wrote:Thanks, guys.

I am just checking a model which is using process and dependency cube to refresh dependencies although this parameter is set true. Since I never touched this parameter, so just curious about it.

Personally I have set up quite a few models doing this (and I still keep it in my models even though it shouldn't be needed anymore). So if the model is an old one it might even be one of mine.

When PI was first introduced in 9.5 the server didn't pre-set dependencies and to avoid locking and get PI to work you had to do it yourself.
Then on server startup in 10.1 dependencies were read from inter-cube feeders
Then in 10.2 dependencies were parsed from rules as well as feeders (but there was a bug and the order of dependency was reversed for attribute cubes)
Then in 10.2.2 they more or less got it all worked out but dependencies still can't be read if say the cube name domes from a "dynamic reference" (say a DB or AttrS), this will only be picked up on a CellGet or ViewConstruct

You can automatically populate a cube dependency mapping cube by reading the tm1server.log file and parsing out the Cube.Dependency loggers. So although you don't need this technique anymore in 99% of cases I do still keep it around in the (rare) case of a dynamic reference.

lotsaram wrote:Personally I have set up quite a few models doing this (and I still keep it in my models even though it shouldn't be needed anymore). So if the model is an old one it might even be one of mine.

When PI was first introduced in 9.5 the server didn't pre-set dependencies and to avoid locking and get PI to work you had to do it yourself.
Then on server startup in 10.1 dependencies were read from inter-cube feeders
Then in 10.2 dependencies were parsed from rules as well as feeders (but there was a bug and the order of dependency was reversed for attribute cubes)
Then in 10.2.2 they more or less got it all worked out but dependencies still can't be read if say the cube name domes from a "dynamic reference" (say a DB or AttrS), this will only be picked up on a CellGet or ViewConstruct

You can automatically populate a cube dependency mapping cube by reading the tm1server.log file and parsing out the Cube.Dependency loggers. So although you don't need this technique anymore in 99% of cases I do still keep it around in the (rare) case of a dynamic reference.

Thanks for the sharing, dude. Possibly, the one I am looking at was from your hands.