Looker Connect Training

Help Center

Documentation

Community

Cloud Certifications

Labeling Views to Make Your Models More Understandable (3.20+)

lloydtabb
Rank
Userlevel 6
Badge

Looker 3.20 introduces new ways to label fields.



Until now, you’re probably familiar with fields appearing like User Age. You’ll now have much greater freedom about how you want fields to appear to users in the field picker.



Field labels now consist of two parts:





  • The view_label begins the name of the field, and is the view name by default (“User” in the example above)


  • The label ends the name of the field, and is the dimension or measure name by default (“Age” in the example above)




If you’ve enabled the new field picker that was introduced in 3.18 (by going to the Labs section of Looker’s admin settings), fields are grouped by their view.



In 3.20, views can now be re-labeled so that they are logically grouped together in for end users in the field picker. You’ll still reference the fields in the way you’re used to when writing LookML.



Default Behavior



Suppose you had the following model:



- explore: order


  joins:


  - join: user


    foreign_key: user_id


  - join: user_order_facts


    foreign_key: user_id





- view: user


  fields:


   - dimension: age





- view: user_order_facts


  fields:


   - dimension: lifetime_orders


The resulting explore would have three separate views named:





  • Order


  • User


  • User Order Facts




The two dimensions would be displayed as:







  • User Age




  • User Order Facts Lifetime Orders




Both of these fields are really attributes of User. The fact that “Lifetime Orders” exists in a separate view isn’t all that interesting to the person exploring the data. It would be really nice if “User Order Facts Lifetime Orders” displayed as “User Lifetime Orders” instead.



In 3.20 there are a couple of mechanisms to do this:



Change the view_label for All Fields in a View



In the following example, all the fields in the User Order Facts view would appear as User instead:



- explore: order


  joins:


  - join: user


    foreign_key: user_id


  - join: user_order_facts


    view_label: User        # Change the view_label


    foreign_key: user_id


Change the view_label for Individual Fields



There are times (e.g. in a wide events table) that you might want to label attributes. In these cases you might want to declare the view_label and label for individual fields:



- view: event


  fields:


  - dimension: user_name


    view_label: User


    label: Name


    sql: ${TABLE}.user_name





  - dimension: user_id


    view_label: User


    label: ID


    sql: ${TABLE}.user_id





  - measure: user_count


    view_label: User


    label: Count


    type: count_distinct


    sql: ${user_id}


In LookML these fields are called:





  • event.user_name


  • event.user_id


  • event.user_count




However, they would appear in the field picker as:







  • User Name




  • User ID




  • User Count


17 replies

Alison

Lloyd,


I love this solution. It solves for so many use cases and divorces the UI from the SQL JOINs.


Thank you to you and the rest of the team!


Alison

V

My first Discourse post. This is wonderful news! We’ll be doing away with some awkward naming conventions, like the “_” on view and dimension names to mimic the “right” UI name.


Thanks team

E

Really glad to see this feature in development, thanks to everyone @ Looker for being receptive to the feedback + picking this one up!

J
Userlevel 2

This is so good. As I read this, I almost literally see user confusion, renaming gymnastics, maintenance cost, and other pain disappear. Can’t wait to use this!

lloydtabb
Rank
Userlevel 6
Badge

We’ve spun up learnbeta.looker.com. Its a clone of Learn that is running the latest release (so if you have a learn login, you should have one on learnbeta too). If you would like to try out the feature, it would be great to get feedback so we can make sure it’s right when it gets into your hands.

J
Userlevel 2

This is sweet! I spent a few minutes with it. The view-level rename worked perfectly (diff attached).


For whatever reason the field-level Dog rename didn’t. I hardly ever want to rename on a field-by-field basis though. To my thinking, views represent distinct nouns, so mixing nouns within a view begs for a separate view anyway.


Really nice feature. Thank you so much.


view-rename.diff.lookml (2.1 KB)

lloydtabb
Rank
Userlevel 6
Badge

I think you wan’t


view_label: Dog

not


view_name: Dog

If it didn’t warn you, that’s a problem. I’ll take a look.

J
Userlevel 2

How embarrassing. Thanks Lloyd.

T

LOVE this update

M
Userlevel 2

It seems that view_label can be used as a parameter of explore also. Specifically, in version 3.48.7, the following code causes the field picker to display only “Bar” as the view:


explore: foo

view_label: Bar

# It also works without the following lines.

joins:

  - join: baz

    view_label: Bar

Is this intended, and not subject to change/removal in future versions?


(If so, it should be documented somewhere. I don’t see it in the explore documentation, where it belongs; nor is it mentioned in the documentation for view_label for join afaict.)

cutler
Rank
Userlevel 5
Badge

@Michael, a view_label declared at the explore level should apply to that explore’s “base view”, but should not carry through to all joined-in views. With something like the following, do see two view-level headers in the field picker (‘Bar’ and ‘Baz’)?


- explore: foo

  view_label: Bar

  joins:

    - join: baz

I just recently modeled something out like that on an internal instance and got the expected two-label behavior. If that’s not what you’re seeing, I’d reach out to us at help.looker.com or on chat and we can dig into this.


Also, for the sake of completeness, here’s a more in-depth sample of what I’m doing:


- explore: foo

  label: 'Prettier Foo'

  view_label: 'Bar'

  joins:

    - join: foo_facts

      view_label: 'Foo Plus'

      [more joins and parameters, etc., etc., etc.]
M
Userlevel 2

Yes, certainly. But the very existence of a view_label parameter for explore is what I was asking about. The documentation, and the original post on this page, only mention a view_label parameter for join, afaict. Is view_label for explore here to stay, despite its being essentially an Easter egg?

cutler
Rank
Userlevel 5
Badge

Ah, yes, in that case it is a “real parameter” and can basically be thought of as a view-level view_label that applies to the base view of that explore. There isn’t currently any documentation on using it on the base view, but I’ve talked to our documentation folks and it is slated to be written. They’re also working on some slick new design stuff!

M
Userlevel 2

Thanks for the info, @cutler.

A

Is there an equivalent to a “label prefix”?


Here’s the use case:


There’s a User table. I create a view named user.

In the model there’s another view named order.

Orders have an “opening user” and a “closing user”.

So I join twice to the User table using the from functionality.

For organization, I don’t want User objects for each from to get their own folder. I want to use the Order folder. I just want to prefix the label - Opening User Name, Closing User Name, assuming that the user view has a name dimension.


Does this make sense? How do I accomplish this?

sam
Rank
Userlevel 5
Badge

Hi @alyssackwan-clara!

Since you don’t want both User tables to get their own folder, view_label isn’t going to be the perfect solution. I can pass on your use case to our product team, though! Would something like a field_label_prefix fit your use case? I imagine LookML like:


explore: order {

  join: user_opening {

    from: user

    field_label_prefix: "Opening User "

  }

  join: user_closing {

    from: user

    field_label_prefix: "Closing User "

  }

}
A

This is perfect!

Reply


Terms of Service