Open lbrowncubewise opened 11 months ago
Hi Luke @lbrowncubewise
It sounds like a good enhancement but I'm not sure exactly how it would work in practice.
pChangeElType can really only be "C" as if it was "N" then this would create issues either with elements getting converted to C anyway as components are added or the process fails due to name conflict with Leaves hierarchy.
I guess the dimension being built is more detailed than the source file? And there would be some subsequent processing to hang the leaves on the lowest level parents?
If yes to the question above, then it seems like a pretty reasonable use case and generic enough that it could be in the standard bedrock library rather than customer specific variant. However I would consider a Boolean parameter "pCreateElesAsConol" since pChangeElType = 'N' (or 'S') would not really lead to valid results.
Happy to review a pull request for how this would work in practice.
@lotsaram your suggestion of creating a new parameter of pCreateElesAsConol makes a lot of sense as this is in essence what I am doing to clone an existing dimension into an alternate hierarchy as a base structure.
Is your feature request related to a problem? Please describe. I have created a client specific version of the }bedrock.,hier.import process to overcome a limitation of the current process which I think could be a good enhancement for the current version.
Describe the solution you'd like This update allows me to clone dimensions from their source to an alternate hierarchy and change the incoming element type to a consolidation or alternate element type to reflect its position within the alternate hierarchy.
Describe alternatives you've considered Create a custom version of the current process to reflect this need
Additional context