Add option to pass element selection as iterator in get_value function

[tobiaskapser]

Hi together,

@MariusWirtz
We discussed the option to pass element coordinates as Iterators to the get_value()-function. That would remove the need to specify special separators for the element string.
You also had the idea to use the MDXpy Member object. I tried that and it worked out really nice! :)

It also simplifies the building of the MDX statement, because it provides the unique_name directly.
This could be used to create the Member directly from the splitted strings too. After that the MDX query can be build independently of the input type always from the Member object.
So I did some little restructuring to use the Member consistently throughout the function.

The get_value function is now callable without hierarchies like this:

get_value("CubeName", [(Dimension1, Element1), (Dimension2, Element2), (Dimension3, Element3)])

or with hierarchies like this:

get_value("CubeName", [(Dimension1, Hierarchy1, Element1), (Dimension1, Hierarchy2, Element2), (Dimension2, Element3)])

or directly with the mdxpy.Member objects

Unfortunately this has the disadvantage that the user has to always provide the dimension name. If not given it is not distinguishable if the next element belongs to the next dimension or to the same dimension but another hierarchy.
Does anyone see an option to determine that?

[MariusWirtz]

Hi @tobiaskapser,

thanks! I like it.
It's nice that you added tests with the change.
I think the function is more useful now IMO.

It's kinda disturbing that the argument is called element_string when in reality it accepts a range of types besides strings. I guess we couldn't change this though without breaking backward compatability.

I will merge it as is.

[MariusWirtz]

Or maybe we could change it. Like we could introduce a new argument as position 2 and call it elements, members or intersection.

Then we could extract element_string from kwargs in case someone is passing the "old" keyword argument to the function.
That would be backward compatible I guess.

Not sure if it's worth it though only to have descriptive argument names...

[MariusWirtz]

Unfortunately this has the disadvantage that the user has to always provide the dimension name. If not given it is not distinguishable if the next element belongs to the next dimension or to the same dimension but another hierarchy. Does anyone see an option to determine that?

I could not think of a way to resolve this

[tobiaskapser]

Or maybe we could change it. Like we could introduce a new argument as position 2 and call it elements, members or intersection.

Then we could extract element_string from kwargs in case someone is passing the "old" keyword argument to the function. That would be backward compatible I guess.

Not sure if it's worth it though only to have descriptive argument names...

That is a good idea! element_string really is misleading. I was also thinking about this problem while implementing it but did not came up with a solution.
I would implement this before we merge this. It is not a big change and would improve clarity.

[tobiaskapser]

Tested it. There is one problem with this approach:

Suppose the user passed element_string as a keyword argument, not as a positional argument. Like this:

get_value(cube_name, element_string="Element1,Element2,Element3")

This function call would be okay in the current version.

If we now change the second argument to elements (still positional) and extract the element_string from the kwargs the user gets an TypeError because the positional argument elements is not passed by the user.
That would break backwards compatibility for all function calls that pass the positional arguments as a keyword argument.

[MariusWirtz]

If we now change the second argument to elements (still positional) and extract the element_string from the kwargs the user gets an TypeError because the positional argument elements is not passed by the user.
That would break backwards compatibility for all function calls that pass the positional arguments as a keyword argument.

Would it work if we set the default value for elements to None then?

[tobiaskapser]

That seems to work! I added the commits to my fork.