-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PROPERTIES in MDX does not work #470
Comments
The For the time being, if you want to see attribute values on the column headers, you can do a small additional query like this: from TM1py import TM1Service
with TM1Service(address="", port=12354, user="admin", password="apple", ssl=True) as tm1:
mdx = """
SELECT
{Tm1SubsetAll([d1])} ON ROWS,
{[d2].[e1], [d2].[e2], [d2].[e3]} ON COLUMNS
FROM [c1]
"""
df = tm1.cells.execute_mdx_dataframe_shaped(mdx)
mdx = """
SELECT
{[}ElementAttributes_d2].[Alias]} ON ROWS,
{[d2].[e1], [d2].[e2], [d2].[e3]} ON COLUMNS
FROM [}ElementAttributes_d2]
"""
values = list(tm1.cells.execute_mdx_values(mdx))
df.columns = ["d1"] + values
print(df) |
yes for workaround would be querying the }ElementAttributes cube and replacing the dataframe header... yes it would be nice if this can be done inside tm1py functions! as usually principal name is just a code but actually user wants to see the alias/attribute name. |
@MariusWirtz This is one thing that stopped working from v1.4 to v1.5. The content endpoint handled attributes but the new cellset parsing does not. I am trying to figure out a fix and I have enlisted Hubert to help me out. Just in my initial research I have found 2 potential solutions, neither of which I like very much. Since the server returns all attributes if none are specified, this becomes quite difficult
|
@rclapp thanks for raising the issue. I agree this is something we need to take care of in TM1py. Perhaps we can just leave it to the user. Like in the Obviously, the user would have to specify the The downside of this approach is that if the user does not specify the from TM1py import TM1Service
with TM1Service(address="", port=12354, user="admin", password="apple", ssl=True) as tm1:
mdx = """
SELECT
{Tm1SubsetAll([d1])} PROPERTIES [d1].[Attribute Something] ON 0,
{Tm1SubsetAll([d2])} ON 1
FROM [c1]
"""
data = tm1.cells.execute_mdx_dataframe(mdx, display_attribute=True) |
Agree.
Today, this works if attributes are introduced as a calculated member, maybe we just use that as our preferred path.
I'll update more as my analysis progresses.
…Sent from my mobile phone
On Feb 1, 2021 5:28 AM, Marius Wirtz <notifications@github.com> wrote:
@rclapp<https://github.com/rclapp> thanks for raising the issue. I agree this is something we need to take care of in TM1py.
I hope we don't have to parse or augment the MDX.
Perhaps we can just leave it to the user. Like in the execute_mdx_dataframe or the execute_mdx_dataframe_shaped function we could add an optional boolean argument like display_attribute that controls if we use the element name in the data frame or the first attribute (from the response JSON).
Obviously, the user would have to specify the PROPERTIES in the MDX correctly and TM1py would have to retrieve the Attributes as part of the element properties and build the data frame accordingly.
The downside of this approach is that if the user does not specify the PROPERTIES in the MDX all attributes are retrieved and it gets really slow.
from TM1py import TM1Service
with TM1Service(address="", port=12354, user="admin", password="apple", ssl=True) as tm1:
mdx = """
SELECT
{Tm1SubsetAll([d1])} PROPERTIES [d1].[Attribute Something] ON 0,
{Tm1SubsetAll([d2])} ON 1
FROM [c1]
"""
data = tm1.cells.execute_mdx_dataframe(mdx, display_attribute=True)
-
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#470 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AEK7GZXGB5GBJ43TQVCDE2DS42T6ZANCNFSM4WRKVWZQ>.
|
Guys, I am not a python expert but here is my 2 cents. we develop our Js
framework and several times we got the conclusion handle attributes in
calculated members much cleaner then somehow do work around with notations
or parsing.
…On 2021. Feb 1., Mon at 18:58, Ryan Clapp ***@***.***> wrote:
Agree.
Today, this works if attributes are introduced as a calculated member,
maybe we just use that as our preferred path.
I'll update more as my analysis progresses.
Sent from my mobile phone
On Feb 1, 2021 5:28 AM, Marius Wirtz ***@***.***> wrote:
@rclapp<https://github.com/rclapp> thanks for raising the issue. I agree
this is something we need to take care of in TM1py.
I hope we don't have to parse or augment the MDX.
Perhaps we can just leave it to the user. Like in the
execute_mdx_dataframe or the execute_mdx_dataframe_shaped function we could
add an optional boolean argument like display_attribute that controls if we
use the element name in the data frame or the first attribute (from the
response JSON).
Obviously, the user would have to specify the PROPERTIES in the MDX
correctly and TM1py would have to retrieve the Attributes as part of the
element properties and build the data frame accordingly.
The downside of this approach is that if the user does not specify the
PROPERTIES in the MDX all attributes are retrieved and it gets really slow.
from TM1py import TM1Service
with TM1Service(address="", port=12354, user="admin", password="apple",
ssl=True) as tm1:
mdx = """
SELECT
{Tm1SubsetAll([d1])} PROPERTIES [d1].[Attribute Something] ON 0,
{Tm1SubsetAll([d2])} ON 1
FROM [c1]
"""
data = tm1.cells.execute_mdx_dataframe(mdx, display_attribute=True)
-
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<
#470 (comment)>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/AEK7GZXGB5GBJ43TQVCDE2DS42T6ZANCNFSM4WRKVWZQ
>.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#470 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHNEK3DXUR4J25RM3O7UN5LS43TUPANCNFSM4WRKVWZQ>
.
|
Thanks Zsolt I agree.
The more I dig into this the more I realize that the Dimension Properties notation is not the best place to specify attributes anymore. It only helped when using the Watson Analytics connector and the content endpoint.
|
use `display_attribute=True` and user PROPERTIES in MDX query Related to #470
I also used the Calculated Members to retrieve attributes together with data in my previous projects. |
Hi @yyzz1010, the Please upgrade to the feature branch and test if it works as expected: Make sure you pass from TM1py import TM1Service
with TM1Service(address="", port=12354, user="admin", password="apple", ssl=True) as tm1:
mdx = """
SELECT
{Tm1SubsetAll([d2])} PROPERTIES [d2].[Number] ON 0,
{Tm1SubsetAll([d1])} PROPERTIES [d1].[Attribute Something] ON 1
FROM [c1]
"""
data = tm1.cells.execute_mdx_dataframe_shaped(mdx, display_attribute=True)
print(data.head()) |
the |
use `display_attribute=True` and user PROPERTIES in MDX query Related to #470
Describe what did you try to do with TM1py
in cube view mdx query using PROPERTIES can show attribute name in column/row, but when using tm1py querying the same mdx, column/row name still showing principal name. is it possible for tm1y to show attribute name when querying cube view mdx?
Describe what's not working the way you expect
Didn't get the expected result? Describe:
in cube view, column names are showing "SALES_DESC_EN" attribute
![image](https://user-images.githubusercontent.com/45536868/105676777-f3952a80-5f25-11eb-932c-cfcd39336c08.png)
but in tm1py still showing principal name
![image](https://user-images.githubusercontent.com/45536868/105676351-5afeaa80-5f25-11eb-8579-bfe1702f3a9d.png)
The text was updated successfully, but these errors were encountered: