Question

Explore view_label don't over-ride dimension view_label?

  • 12 October 2015
  • 2 replies
  • 181 views

We’re trying to make use of the view_label attribute on dimensions/measures to make our explore UI more intuitive. It’s worked super-well for most use-cases, but we’re running into some problems when we want to make an explore that joins to the same view multiple times.



The issue is that even though we specify a new view_label in the explore, the view_label defined in the view still gets used. This means that in the new explore, there’s no way to figure out which variable is which. In the example below, it’s impossible to tell from the UI wether dim1 is from View A or View B because two dim1 dimensions show up under the ‘Separate View’ header.



# Filename: otherview.view.lookml

- view: otherview

fields:

- measure: count

type: count



- dimension: dim1

view_label: 'Separate View'

sql: ${TABLE}.dim1











# Filename: base.model.lookml

- explore: multi_explore

view: base_view

label: 'My Sweet Explore'

view_label: 'Base'

joins:

- join: other_view_1

from: other_view

view_label: 'View A'

relationship: one_to_one

sql_on: ${base_view.a_other_id} = ${other_view.id}

- join: other_view_2

from: other_view

view_label: 'View B'

relationship: one_to_one

sql_on: ${base_view.b_other_id} = ${other_view.id}

2 replies

Userlevel 4
Badge

Hey Michael,



The intended behavior of view_label is that the field’s view_label will take precedence over the join’s. I believe the best way to handle this situation would be to give the fields in the view specific labels, and allow the view_label at the join to bucket the fields.



For the case where you want the view_label for specific fields given the explore you are in, a recommendation would be to make duplicate fields, one with a view_label and one without, in the view. From there the fields parameter on the explore will enable you to decide whether you use the field which uses its own view_label, or the field which adheres to the view_label of the join.

Okay cool. Thanks for explaining the intended behavior here. I’ll keep thinking about how we want this to function in practice. I don’t love the idea of duplicating all of the fields, so I’ll brainstorm. Thanks @Zam!

Reply