}bedrock.cube.dimension.add: Not allowing new dim to be added as last dimension in recreated target cube (and no error logging to explain why)

[SFinestone256]

Is your feature request related to a problem? Please describe. When running the ‘}bedrock.cube.dimension.add’ process and attempting to add a new dim in the last position of an existing cube , the process completes successfully but the target cube is recreated without the new dimension (i.e. no change). There is also no clues in the TM1Server log even when logging is enabled to provide feedback to developer of why the process did not add the new dim to existing cube.

As an example. When trying to add TestDim as the 4th dimension in an existing cube (TestCube) that orginally has 3 dimensions, '}bedrock.cube.dimension.add' completes successfully but TestCube is recreated with only the original 3 dimensions. The value of sDimString (used to recreate TestCube) only contains the original 3 dimensions as it seems the loop that builds the value of sDimString breaks out after 3.

Describe the solution you'd like Assuming that this behavior is intentional as it is assumed that last dimension in a target cube contains measure elements that may include both string and numeric element types, the request is include a validation section early in the Prolog of ‘}bedrock.cube.dimension.add’ that breaks the process and writes out feedback for the developer in the TM1Server log. The validation should check if the Index parameter is larger than the number of original dimensions in the target cube, and if this is the case then should cause the process to break and LogOutput.

Describe alternatives you've considered An alternative is to allow for the process to add new dimension as the last element in the target cube but this may result in errors when copying string data from clone cube to numeric placeholder element in last dim of recreated cube (or indeed when copying numeric data to string placeholder element in last dim of recreated cube).

A way around this issue above is to expand the parameters of the ‘}bedrock.cube.dimension.add’ to allow user to specify a numeric AND a string placeholder element in the case that there are both numeric and string elements in the last dimension of the original cube. However, this may over-complicate the process for a typical end-user as well as requiring two passes of the cube copy data (once for numeric data and again for string data).

Additional context See screenshot below at my attempt to add extra validation in the ###Validate Parameters### section of the Prolog. Breaks process and writes out error if new is attempted to be inserted as the last dimension in recreated cube (or any value higher than the original cube dimension count for that matter).

[lotsaram]

Fixed in #350

[SFinestone256]

Hi @lotsaram,

Thank you for your lightening responsiveness!

Quick question. I've tested the updated version of '}bedrock.cube.dimension.add' as per #350 release. The unfortunate consequence of this change is that if a user does decide to add a new dim as the last dimension in the target cube (and select a numeric-type pEle in the parameters of the process), then any string values in the original cube are lost in the recreated cube (since the new 'measures' last dim only allows for numeric data).

Perhaps this should be a caveat for users in the Parameters section or near the top of the Prolog until a permanent workaround for this (whereby, for example, numeric data is copied onto a pEleNum and string data is copied onto pEleStr) can be implemented.

Apologies for causing more issues than may be worth it!

[lotsaram]

Hi @SFinestone256

I think this is a bit of an edge case. As I mentioned if someone is adding a dimension to a cube then they should know what they are doing. If someone is adding a dimension to a cube and making it the last dimension and retaining data then they REALLY should know what they are doing. Caveat emptor!

Should someone want to do this then they can always make pTemp=0 in which case the exact clone of the original cube (with data) will still be present and they could run an additional cube.data.copy.intercube process to deal with the string data.

Again, the possibility of lost data can only happen if

1. new dimension added last
2. keep cube data
3. mix of string and numeric data

In such an edge case I don't think there is a justification to add additional complexity and automate a solution when a manual workaround is possible with existing parameters and one extra step.

[SFinestone256]

Hi @lotsaram,

On the same page as you are here :)

The issue original cropped up when a customer super-user was trying to add dim as the last dimension in a cube that contained both string and numeric data. But even in this case, the user was cautious enough to retain the cloned cube so that they could perform a recon once the new cube had been created. So this proves your point.

I'm new to the Code community so really appreciate the responsiveness and pleasant introduction to this communication channel. Will be sure to use this channel again in future!