Looker Connect Training

Help Center

Documentation

Community

Cloud Certifications

Question

Preserving a hidden measure from visualization, even after drilling down?

  • 26 December 2017
  • 12 replies
  • 868 views
K

When creating a Look, I understand that I can hide a measure from a visualization. However, it seems that when I drill down on the visualization, the hidden measure seems to reappear in the visualization. Is there a way to keep a measure hidden from the visualization while drilling down?


Essentially, I am trying to create grouped bar charts of various statistics (averages), but I want the end users to be able to see the total number of records in each row to give context.

12 replies

paola
Rank
Userlevel 3

Hey @kao_phet, are you drilling into your values using the drill_fields parameter? If so, the values that appear in the drill modal are defined through this parameter. For example, if you want your drill to include the fields foo.bar1 and foo.bar2, then we would define the drill fields parameter in your dimension/measure as


drill_fields: [foo.bar1, foo.bar2]

If the drill is being defined a different way, would you mind sharing how that is currently defined?


Thanks!

K

Hi @paola, if I’m understanding the question correctly, I’m actually drilling into a dimension from a visualization (tile in a UI defined dashboard).


For example, I have this tile. Which has a dimension “County”, and 4 measures that are averages, and 1 measure that is a count type, that is hidden from the visualization:


Ideally, when drilling down into a dimension from this tile, I’d like to keep the visualization settings. However, when I drill in, the bar chart now looks like this due to the Total Count being included in the visualization.


Here is the associated table for the above visualization:




The LookML for the dimension is:


dimension:  reg_county {

view_label: "Geography"

type: string

sql: ${TABLE}.vb__vf_county_name ;;

drill_fields: [reg_municipality]

}

The LookML for the measure (Total) is:


measure: total_people {

type: count_distinct

sql:  ${EID} ;;

drill_fields: [EID, first_name, middle_name, last_name, name_suffix, mail_full_address, mail_city, mail_state, mail_zip, mail_zip4, reg_full_address, reg_city, reg_state, reg_zip, reg_zip4, phone, phone_type, phone_wireless, phone_wireless_conf_score, registration_status, voter_status, party, modeled_party, age, gender, race, partisan_score, ideology_score, 2017_general_turnout_score, local_voter_score, reg_ld, reg_sd, reg_cd, reg_county, reg_municipality, reg_precinct_id, reg_precinct_name ]

}
Ellio
Rank

Hi @kao_phet,


Currently, after drilling into a dimension, the measures you had on the pre-drill explore are also carried over. However, whether they were hidden or not does not carry over.


I will go ahead and let our product team know that you’d like to see hidden measures remain hidden after drilling!


Best,

Elliot

Aditya_K

Hi Ellio,


Is the above issues been resolved or taken care. If yes , Can you please let me know. We are also stuck with the same situation

izzy
Userlevel 7
Badge +1

This functionality has not yet been addressed— But we understand the context here and why it would be valuable to maintain hidden-ness upon drill. It’s an open issue with our engineering team, but has not been prioritized highly.


In this use case, would it be possible to remove the measure from the explore, rather than just Hide from Visualization?

Aditya_K

Hi Izzy,


There are times where we are required to perform certain calculations at the explorer end. Soo that the target column is obtained based on that table calculations. Soo if we try to remove those table calculations we are not achieving the desired output. Soo its a bad idea to always remove the table calculation column for drill down.


I have one more question for you. For Filters , Is it possible to assign a default value from sql rather than string. Bcz if we are passing a string value its a hardcoded value we are passing. Rather than it should get it value based on some sql.

izzy
Userlevel 7
Badge +1

That makes sense, thanks for highlighting the use case. I’ll pass it along.



This isn’t possible straight out of the box using “default_value”. You could perhaps do some trickery using sql_always_where: in the explore and referencing the relevant filter in a liquid if statement.


sql_always_where:

 {% if _filters['view.field'] == "Default" %}

  view.field = sql_string_you_want_to_filter_with

{% else %}

 1=1

{% endif %}

Or something like that. Do you see how that might work? It’s not 100% dynamic since you have to think about what conditions they might apply, but it could work.

Aditya_K

Hi Izzy,


Thanks for the reply. But Just to update on your solution for dynamic default values to filters. _Filters[‘view.field’] doesn’t works with sql and sql_on parameters as per the looker documentation




Is there any other solution you can suggest?

izzy
Userlevel 7
Badge +1

Oh no! You’re totally right, my bad. You can use {% parameter view.field %} in the sql parameter instead, as long as it’s a filter of type: string.

Avantika_Banerjee

I have a similar use case. Do we have a solution for the same?

J

We are facing the same issue. Any update on this yet?

jhaar

We are also having this issue and would like it addressed. Is there a feature ticket we can vote on or anything like that?

Reply


Terms of Service