DimensionHierarchyCreate Vs HierarchyCreate

[Alan Kirk]

This is more random curiosity than anything.

There is a function called DimensionHierarchyCreate. Its description in online help is:

Last Updated: 2025-03-25
DimensionHierarchyCreate creates a new hierarchy in an existing dimension. The hierarchy cannot have the same name as the dimension.

This function is valid in TM1® TurboIntegrator processes only.

Syntax
DimensionHierarchyCreate(DimName, HierName);

DimName
The name of the existing dimension that will contain the hierarchy.

HierName
The name that you want to assign to the hierarchy. You cannot use the name of the dimension.

There is also a function named HierarchyCreate. Its description in online help is

Last Updated: 2025-03-25
HierarchyCreate creates a new hierarchy in an existing dimension. The hierarchy cannot have the same name as the dimension.

This function is valid in TM1® TurboIntegrator processes only.

Syntax
HierarchyCreate(DimName, HierName);

DimName
The name of the existing dimension that will contain the hierarchy.

HierName
The name you want to assign to the hierarchy. You cannot use the name of the dimension.

So, aside from the word "that" appearing one additional time in one description of the HierName argument... the two are identical. And my tests indicate that they perform identically.

So out of curiosity does anyone know why in the living hell IBM implemented two differently named, identically performing functions and did not bother to include in the documentation the fact that (a) such a cloned pair exists and (b) which of them the preferred one is?

(For me it would be HierarchyCreate just because it's in the same series as other related functions.)

[MarenC]

Maybe someone at IBM has a real OCD about symmetry?

[Alan Kirk]

Maybe someone at IBM has a real OCD about symmetry?

I'd probably buy that if it was an obsessive and compulsive need to "just make sh1t up as you go along without a plan". The deeper I dive into alternative hierarchies, the more I shake my head and mutter "You've GOT to be kidding me."

Let's take another example; the useless CreateHierarchyByAttribute function. When I first saw it I thought "Sounds good. I can see a need for this."

Then I looked at what it actually does.

First, it has to be a STRING attribute, because hey, nobody would ever want to create a hierarchy based on numeric attribute values. But of course, it HAS to be a string attribute so that the function can create the consolidation of each attribute value that nobody actually asked for. (Not that it's intrinsically a bad thing to have that as an option, but it's not an option. It just is. And it's not like a numeric attribute value could be converted to a string for use as a consolidated element name, of course. )

Then it also brings all of the elements which don't have that attribute value into the hierarchy. Not optionally, you get those too, whether you want them or not. You get every single freaking element from your first hierarchy in your newly created allegedly attribute-based hierarchy.

Oh, and the "rootname" argument that is shown as an "optional" supposed "override"? It's only really optional if you leave both the third and fourth arguments out completely. If you assign a value to the third argument (the name of the consolidation to contain all empty attribute elements that you probably don't actually want in the hierarchy), but not the 4th one (the rootname), you get a syntax error.

Or, assign the third argument and put an empty string for the 4th argument because you don't want to override the value? You get a runtime error.

Did anyone even test this thing for usability, much less fully document this? Well, I know the answer to the second question.

So useful was this function that it lasted one whole version before being pole-axed in V12.