Importing Objects from FM into Other FM Models - Drawbacks

There are so many issues when trying to use this feature provided by Cognos. For a simple activity I tried importing 2 Data Source Query Subjects from Physical Layer of Model A into Test Layer of Model B. But the objects got imported into Physical Layer of Model A. To add on to my woes, it also imported a whole lot of other objects that had no dependency on the imported Query Subjects. These objects were Functions. So don't know if this has to do only with functions.

Another issue I found with this approach is that relationships between imported objects also get imported. And unlike Data Source based imports where users are prompted to choose to either create relationships or not, in case of model based imports this option is not provided requiring me to manually look up the imported objects and clean out those not required.

Copies of source model packages were also created which may be because the imported objects are part of the source model packages.

This is a powerful feature when you want to save time by re-using objects designed in other models but with all the issues listed out above, it seems to be a painful feature to use for the time being, until Cognos fixes these bugs. What can make this feature easier to use apart from fixing of the bugs would be options to select the kind of objects to import like 'relationships', 'calculations' etc. that may be dependent on the imported objects rather than having Cognos import all such dependent objects.

Folders/Namespaces and Loops

As we all know loops are a complete no-no in Cognos. So having said that, I didn't want to write up this article, but thought that someone out there might benefit in knowing how folders/name spaces impact loops.

I stumbled on this while trying to help a colleague on his FM model. The model was based on an ER data model and not a dimensional data model. So loops were bound to be present but luckily there were just 12 tables to deal with, still a developer's nightmare. The issue the user was facing was with unpredictable queries getting generated which was bound to occur with loops.

I am simplifying the scenario here. Lets say there are 5 tables A, B, C, D and E. A is joined to D through B and C. A is also joined to D through E.

A-B-C-D
A-E-D

As you can see there are now 2 ways to get to D from A. If a user were to pull in items from A and D, Cognos may or may not include B/c or E. Assuming Cognos takes the shortest path (think I read this somewhere, but I may be wrong), it shouldn't have included B and C, but in the user's case it was.

After digging we found that the query subject E was placed inside a sub-folder under the main folder. So when object E was moved to the main folder where all the other objects were residing the query took the path through E.

So here's my assumption on how Cognos evaluates loops. It looks for the shortest path in the same folder as most of the objects involved in the query and only when such a path doesn't exist it evaluates other paths that involve other folders and name spaces.