Good morning, I would like to change the way a Pay...
# gooddata-platform
h
Good morning, I would like to change the way a Payment Method is displayed, new name Transaction Type. I updated the Text label property of that attribute in the LDM to Transaction Type I updated the Title property of the Label of that attribute in the Dataset editor to Transaction Type. Still both the Analyzer and the charts display the original physical name. Should I do something else?
t
Hello @Hans Cornette, have you updated an existing text label or added a new one? If you have added a new one, then switch the insight to use it in the Analyze tab.
h
Hi Tomas, I have updated the existing one. I want all Payment Methods to appear as they were a Transaction type. Without changing the original name because I've experienced this gives issues when updating the LDM.
i
Hi Hans, then you can make it the Default label of this label as mentioned here .
Yes, your approach is definitely safe and correct.
h
Hi Ivana, Alright, following the documentation link above, I didn't add a new label, but rather updated the default one. Still it keeps being displayed as Payment Method. I would expect into display as Transaction Type.
t
Hello @Hans Cornette, if you want to change the name of attribute in the catalog, then I think changing the attribute name is definitely the right approach (instead of changing the text label name). Could you share with us what kind of issues does this change cause? It should be a strictly logical operation without any consequences since the ID should stay the same.
1
i
Both options should be fine. I am just surprised, the Default label doesn’t show up as expected. Could you double-check if it is really set as default one after its renaming, please?
If this doesn’t work as expected. Please try to rename the Attribute as suggested by Tomas, or add a separate label and set it as default.
Also, if the direct renaming of default label(honestly, I’ve never tested it from my end this way) doesn’t work, I would revert the changes and start from the scratch.
h
@Tomas Muchka according to what @Ivana Gasparekova is describing and sharing I should be able to update the Default label. 🙃 @Ivana Gasparekova I can update the attribute name, but what's the point of having a label that's telling me its Labeling an attribute when it doesn't? Also, I would need to select it in every insight, and my goal is to work with the new name it in the analyzer.
@Tomas Muchka the issues I had was when I removed and introduced the new table, to change a datatype from another field from bit to a nchar(5). Even though it is the exactly same table and the bit was not used anywhere (check that) it told me it was finding dependencies across all insights and dashboards where the original (renamed) attribute was used. Since we are unable to change the attribute name (not mapping) in the LDM we cannot prevent this. And that's why I wanted to update only its label, through the default one.
i
@Hans Cornette The label that you renamed is the automatically created default label - it has the same title as the Attribute and it is most probably your loading label as well. This label shouldn’t be really removed this way. Please check this part of the article that I shared with you before.
I wrongly assumed that you are adding and renaming another label and making it the default one. I am really sorry for my confusion here.
Link to the article.
h
I read these articles before. My question to you is, what's the purpose of being able to update this Default label when it doesn't do anything? To be fair, my question is not purely philosophical 🙂: it still doesn't take away the issues it causes when making changes later to the LDM.
t
Sorry for the caused confusion @Hans Cornette. Let’s split the question to two. 1. Which LDM changes affects analytics 2. What is the purpose of default label Let me start with the first question. • Some changes (e.g., change of field name) are strictly logical and neither require to reload data, nor have impact on analytical objects. • Other changes (typically those changing the IDs) have impact on the analytical objects. ◦ The field type is part of the ID, so conversion of a field type has a potential impact on analytics objects. ◦ I have tried to delete an existing table and replace is with the same one + converting a single field, but in my case the dependency check stood calm. In the end changing a dataset name or a field name should be perfectly safe without any side effects.
h
Tomas, thanks for the update. I will try that again and will let you know what's the verdict 🙂
👍 2
t
Please check the ID before and after such a change to be sure if it remains the same. Btw any field can be converted without deletion of the whole dataset (table). There is a option in the UI to do so.
h
Hi Tomas, I understand the ID should stay the same. In my experience it will stay the same as long you do not change the field name in the sourcing data table. In my case I wanted to change a Field Is Credit Card from a database type bit 0 , 1 to a database type char(5): No, Yes and (N/A) for a null. My reason was convenience: I didn't want to create it myself and wanted to use the LDM, making the LDM chose the datatype. I wanted to do that because it automatically selects Text for a character value where if you delete and introduce a table the LDM picks up a proper value like varchar, bit etc. Example: See here the Some other field
t
Thanks for the explanation. • Field IDs are generated from DB names (table name, column name), if you change the name in the DB and regenerate the LDM dataset, then it will indeed impact all analytical objects. LDM will think it is a new object. • If you would like to keep the ID, then I suggest to do your changes in DB, but to keep the original LDM field and update only its properties (e.g., name and mapping). This will persist the ID. • Source type column in the Load configuration tab is informative and should not have any effect on data load or field usage.
h
In bullet 2 you say things can be updated in the DB without affecting the attribute. In my experience going from an int to a numeric(8,2) caused the LDM to complain that it would remove all dependencies even though the field name was exactly the same. That's why I wanted to updated the attribute's datatype properly in the first place.
t
Let me try to summarise the steps I described earlier: 1. Add a new table from DB. E.g. Player_Score. 2. Publish changes 3. Load data into newly added dataset 4. Create insight that uses the newly added dataset 5. Update the data type in the DB (from INT to numeric) 6. The workspace should work without any issues at this point, since the old data is still loaded in the workspace data mart. There is no change to the LDM, so there is no impact. 7. Try to reload the data - this will fail, because the workspace data mart type does not match the DB data type. 8. Update the dataset field data type to reflect the DB data type 9. Publish LDM changes and open the previously created insight
h
I follow the whole thing. Step 8. I didn't update it. I removed the table and re-introduced it. As long as the field name stays the same it's fine right?
t
As long as the field name stays the same and as long as the LDM type is the same (attribute vs fact), because it is all part of the ID.
h
I changed the ones on my Report table two weeks ago and the LDM complained about the dependencies. 4 fields going from an int to a numeric. But that's something I cannot reproduce anymore because I did the update through substituting them twice. I will follow your steps, to change the dataset through the LDM from now on! Thanks for your help!
👍 2