TI process for creating MDX view using pFilter as parameter - similar to }bedrock.cube.view.create

[reddibhatini]

The pFilter parameter of TI process '}bedrock.cube.view.create' does not consider hierarchies. Are there any plans of enhancing '}bedrock.cube.view.create' to create mdx views??

[lotsaram]

Hi @reddibhatini Recognizing if pFilter contains a MDX SELECT statement rather than bedrock filter format is possible to do and something that has been considdered. However, what is the actual use case that you would use such a view for? You couldn't use such a view for any data processing due to the unpredictability of the variable assignments from an MDX view. So what would you use it for that you couldn't already use the cube.view.create.bymdx process for?

[reddibhatini]

@lotsaram

It is a lot flexible with '}bedrock.cube.view.create' where we just pass parameter(pFilter string) and the process creates desired view. I love it and using it for years.

Now that we have hierarchies, this process is unable to create views with elements(leaf) that are only in hierarchies which is not the default(same name as dimension). Currently I am using MDX expressions to create views that contains elements(leaf) from alternate hierarchies. Can we enhance '}bedrock.cube.view.create' TI process to create views that includes elements from alternate hierarchies?? I am completely aware, to do this we need to entirely re-write our beautiful TI process '}bedrock.cube.view.create'.

[reddibhatini]

@lotsaram Any update on above? Does it make sense?

[lotsaram]

Any update on above?

Bedrock is an open source project. If this is a feature your would like then you are more than welcome to fork the project, do the development, and create a pull request to merge your development back into the main project.

A simple implementation of supporting MDX in cube.view.create could be as simple as detecting whether pFilter starts with "select" and then calling cube.view.createbymdx directly. However, due to the flexibility of MDX and the way that MDX views work with possible intersects, unions and calculated members, this could result in a query with more or less variables than the cube data source, and anmost certainly with variables read in a different order than the cube dimension order. It doesn't seem that this would be what you want since you talk about only leaf members from alternate hierarchies ...

Does it make sense?

To be honest not really. If your goal is to create a leaf level processing view then there is no reason to involve herarchies or MDX. In fact it is much better not to as you can only gaurantee that the order of variables matches the cube dimension order with a trad view. For a generic TI process the order of variables must be known.