Hello, question about hierarchical workspace data ...
# gooddata-cloud
s
Hello, question about hierarchical workspace data filters: • In the examples provided here: https://www.gooddata.com/docs/cloud/workspaces/workspace-data-filters/ ◦ It suggests creating the wdf_Region in the root of the hierarchy ◦ then applying the filter to the schema ◦ in the child you then specify the region, or regions to use for that ◦ then in a second level child you have to add a data extension to do the wdf_State? • Could we create two WDF's in the parent instead: ◦ wdf_Region ◦ wdf_State ◦ Map them both in the parent LDM ◦ Then in the 1st level (region) enforce the Region by specifying values for the wdf: ie North ◦ Then in the 2nd level (state) enforce the state: California Benefits here would be that both WDF mappings are setup in the ldm through the GUI.
m
Hi Steve, I think I know what you mean and agree that it would be more elegant, but I am afraid this won’t work like this at the moment (or at least not that easily). Last time I checked there was a failsafe that prevented displaying ANY data if there is a WDF defined (in the parent) but there is no WDFSetting (the values) defined for it for a particular child workspace. So if you set both WDFs in the root/parent and then in child level 1 only defined values for the Region but no values for the State, I believe you get exactly this error and no data. And as far as I know there is currently no way to say “allow all values of this WDF on this level”. So for making this to work, you would probably also need to define WDFSetting for State on level 1 and explicitly list all the states (or at least all the states for North region). In case of states (which are not added very often) this might work OK. If it were products or some other changing dimensions, you would also need to make sure you keep adding newly added values to the filters over time. But I fully agree that this approach would be more user friendly and will try to suggest it to our product team as an improvement for the future.
s
Thank you for the response. Question though, the example on the WDF of how to setup multi-tiered data filters doesn't follow your example of having every state in the WDF for the 1st level child. I did follow the example -> meaning I used the demo dataset in our gooddata instance and added the structure: • parent: wdf_region ◦ child level 1: • wdf_region: [North] • wdf_state ▪︎ child level 2: • wdf_state: [California]
I wish I could do: • parent: wdf_state ◦ child level 1 • wdf_state: [California, Texas, Nevada] ▪︎ child level 2 ◦ wdf_state: [California] But it won't let us modify the WDF within the hierarchy
In our situation we have customer ids and we could easily use the same id for both level 1, 2 as above, but we cannot use it that way.
Unfortunate that we cannot take advantage of the WDF in the root so we can use the GUI to specify the 2nd layer WDF.
m
I am not sure I follow you now. If there would be only one filter to apply like in your example (wdf_state), would you still need two-level hierarchy? Wouldn’t a setup with just single level do the same job? • parent: wdf_state ◦ child 1 (level 1) • wdf_state: [California, Texas, Nevada] ◦ child 2 (level 1) • wdf_state: [California] Or do you need multiple levels for some other inherited customizations? Or was this just some simplified example?
s
The example was from the GD website on how multi level hierarchies work for workspace filters. In your example above it would be your child 2 would be nested under child 1. But in the end the way you have it structure also works since there won’t be any benefit to the hierarchical structure at this time.