Hierarchy-aware functions

[Wim Gielis]

Hi all,

We have been using functions like DIMIX, ELISANC, … for ages in rules and Turbo Integrator. While these functions can often be made hierarchy-aware (e.g. DIMSIZ( ‘Customer:By Region’ )), a new set of functions was developed. In the examples given it would be Elementindex and ElementIsAncestor. Or consider the example of DIMENSIONELEMENTINSERT that turns into HIERARCHYELEMENTINSERT.

Similar arguments, but in general the dimension parameter receives a second argument for the hierarchy name.
Below is my own list of regular expressions to swap out the older function names for the newer function names.

Maybe a collective effort within the TM1 community could extend and optimize this list ? Any regex pro’s out there ?

CAVEATS:
- functions with the dim:hier construct cannot be identified !
- constructs like DType( '}ElementAttributes_' | vDim are not found entirely, the regex stops at the pipe symbol.

Code: Select all

 # hierarchy-aware functions



DIMSIZ
------
dimsiz\s*?\(\s*?([A-Za-z\w'\}]+)\s*?\)
ElementCount\( \1, \1 \)

DNLEV
-----
dnlev\s*?\(\s*?([A-Za-z\w'\}]+)\s*?\)
LevelCount\( \1, \1 \)

DFRST
-----
dfrst\s*?\(\s*?([A-Za-z\w'\}]+)\s*?\)
ElementFirst\( \1, \1 \)

DimensionDeleteAllElements
--------------------------
DimensionDeleteAllElements\s*?\(\s*?([A-Za-z\w'\}]+)\s*?\)
HierarchyDeleteAllElements\( \1, \1 \)



ATTRS and ATTRN
---------------
\battr(s|n)\s*?\(\s*?([A-Za-z\w'\}]+)\s*
ElementAttr\U\1\( \2, \2

ATTRPUTS and ATTRPUTN
---------------------
\battrput(s|n)\s*?\(\s*?([A-Za-z\w'\}]+)\s*,\s*([A-Za-z\w'\}]+)\s*
ElementAttrPut\U\1\( \2, \3, \3

ELLEV
-----
ellev\s*?\(\s*?([A-Za-z\w'\}]+)\s*
ElementLevel\( \1, \1

DIMNM
-----
dimnm\s*?\(\s*?([A-Za-z\w'\}]+)\s*
ElementName\( \1, \1

DIMIX
-----
dimix\s*?\(\s*?([A-Za-z\w'\}]+)\s*
ElementIndex\( \1, \1

DTYPE
-----
dtype\s*?\(\s*?([A-Za-z\w'\}]+)\s*
ElementType\( \1, \1

ELPAR
-----
ElPar\s*?\(\s*?([A-Za-z\w'\}]+)\s*
ElementParent\( \1, \1

ELPARN
------
ElParN\s*?\(\s*?([A-Za-z\w'\}]+)\s*
ElementParentCount\( \1, \1

ELISPAR
-------
ElIsPar\s*?\(\s*?([A-Za-z\w'\}]+)\s*
ElementIsParent\( \1, \1

ELCOMP
------
ElComp\s*?\(\s*?([A-Za-z\w'\}]+)\s*
ElementComponent\( \1, \1

ELCOMPN
-------
ElCompN\s*?\(\s*?([A-Za-z\w'\}]+)\s*
ElementComponentCount\( \1, \1

ELISCOMP
--------
ElIsComp\s*?\(\s*?([A-Za-z\w'\}]+)\s*
ElementIsComponent\( \1, \1

DIMENSIONELEMENTINSERT and DIMENSIONELEMENTINSERTDIRECT
-------------------------------------------------------
DimensionElementInsert(Direct|)\s*?\(\s*?([A-Za-z\w'\}]+)\s*
HierarchyElementInsert\1\( \2, \2

DIMENSIONELEMENTCOMPONENTADD
----------------------------
DimensionElementComponentAdd\s*?\(\s*?([A-Za-z\w'\}]+)\s*
HierarchyElementComponentAdd\( \1, \1

SUBSETGETELEMENTNAME
--------------------
\bSubsetGetElementName\s*?\(\s*?([A-Za-z\w'\}]+)\s*
HierarchySubsetGetElementName\( \1, \1

SUBSETGETSIZE
-------------
\bSubsetGetSize\s*?\(\s*?([A-Za-z\w'\}]+)\s*
HierarchySubsetGetSize\( \1, \1

SUBSETEXISTS
------------
\bSubsetExists\s*?\(\s*?([A-Za-z\w'\}]+)\s*
HierarchySubsetExists\( \1, \1

SUBSETALIASSET
--------------
\bSubsetAliasSet\s*?\(\s*?([A-Za-z\w'\}]+)\s*
HierarchySubsetAliasSet\( \1, \1

SUBSETCREATE and SUBSETDESTROY
-------------------------------
\bSubset(Create|Destroy)\s*?\(\s*?([A-Za-z\w'\}]+)\s*
HierarchySubset\1\( \2, \2

DIMENSIONELEMENTPRINCIPALNAME
-----------------------------
DimensionElementPrincipalName\s*?\(\s*?([A-Za-z\w'\}]+)\s*
HierarchyElementPrincipalName\( \1, \1

DIMENSIONSORTORDER
------------------
DimensionSortOrder\s*?\(\s*?([A-Za-z\w'\}]+)\s*
HierarchySortOrder\( \1, \1

SUBSETELEMENTINSERT and SUBSETELEMENTDELETE
-------------------------------------------
\bSubsetElement(Insert|Delete)\s*?\(\s*?([A-Za-z\w'\}]+)\s*
HierarchySubsetElement\1\( \2, \2

ATTRS and ATTRN for CUBES
-------------------------
\battr(s|n)\s*?\(\s*?'}Cubes'\s*,\s*
CubeAttr\U\1\(

ATTRS and ATTRN for DIMENSIONS
------------------------------
\battr(s|n)\s*?\(\s*?'}dimensions'\s*,\s*
DimensionAttr\U\1\(

[MarenC]

Hi Wim,

useful to see that in a list, though what \ / * symbols mean escapes me. And regex stops means nothing to me either!

Anyway, what about SubsetAliasGet and HierarchySubsetAliasGet

Maren

[lotsaram]

I would question the need for such a find/replace. Any code using the dimension functions without dim:hier for the dimension argument is by definition operating on the same named hierarchy and can be left untouched. Any dimension function already using dim:hier to operate on other hierarchies is already sufficient (behind the scense the hierarchy function are just a mapping to the dimension function anyway).

A decision to rebuild any existing model to utilize hierarchies is not a small decision. Rollups will probably need to be split out as separate hierachies. Names of elements may be changed, etc, etc. This involves a rewrite which requires planning and can't be autometed.

[Wim Gielis]

I would question the need for such a find/replace. Any code using the dimension functions without dim:hier for the dimension argument is by definition operating on the same named hierarchy and can be left untouched. Any dimension function already using dim:hier to operate on other hierarchies is already sufficient (behind the scense the hierarchy function are just a mapping to the dimension function anyway).

In your opinion, what is the need of these new functions, then ? Zero ?

[Wim Gielis]

A decision to rebuild any existing model to utilize hierarchies is not a small decision. Rollups will probably need to be split out as separate hierachies. Names of elements may be changed, etc, etc. This involves a rewrite which requires planning and can't be autometed.

Even if it is planned and even if it involves more than TI and rules changes, why would there be a willingness to do this tedious task manually ?

[lotsaram]

In your opinion, what is the need of these new functions, then ? Zero ?

Well actually yes. Absolutely zero.
Baring a very, very few all of the new Hierarchy functions the same functionality can be achieved using the Dimension functions but with dim:hier as the dimension argument. The Hierarchy functions are then essentially clutter. They aren't actually needed and add much complication (e.g. number of TI functions is 3x or 4x what it was). Why IBM decided to introduce all these new functions when changeing one argument of all the existing Dimension functisn to accept dim:hier is beyond me. Zero added value IMO.

Even if it is planned and even if it involves more than TI and rules changes, why would there be a willingness to do this tedious task manually ?

The scenario I imagine you're thinking of is a dimension where nothing changes. That is no hierarchies are added and the dimension continues to have only the same named hierarchy. In this case we just update
DimensionElementInsert( cDimTgt, '', vEle, 'N' );
to
HierarchyElementInsert( cDimTgt, cDimTgt, '', vEle, 'N' );

Here I agree 100%. This is a tedious tast which should just be automated, and can be. However, in this scenario I woudl argue there is zero net benefit of performing this task. So even if it can be automated there is simple no reason to do it.

The scenario I'm thinking of is where a dimension contains multiple alternate rollups and the decision is made to convert the rollups to separate hierarchies. E.g. a Product dimension that had rollups for brand, size, color, etc. With a single hierarchy the top node or root elements of each rollup need to be uniqually named (Total Product by brand, Total Product by color, etc) but if using alternate hierarchies we might have hierachies Brand, Color, Size, ... and the root element of all the hierarchies might be called simply "Total Product".
Yes it might be possible to automate some of the work (e.g. just the change from DimensionElement... to HierarachyElement... in a find/replace) but it isn't going to be a meaningful proportion of the work as it is going to be wrong except for the same named hierarchy and need to be modified by a developer. In such a situation I would argue it is more efficient to rewrite from scratch versus automating a find/replace and then checking and correcting.

[Wim Gielis]

Hi Lotsaram,

I agree with what you wrote. We all know these 'older' functions inside out and if it's just a wrapper, the benefit is limited.

However, it also seems a little bit more neat to have separate arguments to a function for dimension and hierarchy. It sometimes looks a bit silly to concatenate things. Maybe we should even throw an Expand in the mix for the first argument

Code: Select all

Expand( %vDim%:%vHier% ), ...

Then I really prefer separate arguments.

[gtonkin]

Still curious as to whether or not the older functions will be deprecated in V12 or not.

[lotsaram]

Still curious as to whether or not the older functions will be deprecated in V12 or not.

Yes agree. This remains to be seen.