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:
view_labelbegins the name of the field, and is the view name by default (“User” in the example above)
labelends 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.
Suppose you had the following model:
- explore: order
- join: user
- join: user_order_facts
- view: user
- dimension: age
- view: user_order_facts
- dimension: lifetime_orders
The resulting explore would have three separate views named:
- User Order Facts
The two dimensions would be displayed as:
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:
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
- join: user
- join: user_order_facts
view_label: User # Change the view_label
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
label for individual fields:
- view: event
- dimension: user_name
- dimension: user_id
- measure: user_count
In LookML these fields are called:
However, they would appear in the field picker as:
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!
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.
Really glad to see this feature in development, thanks to everyone @ Looker for being receptive to the feedback + picking this one up!
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!
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.
This is sweet! I spent a few minutes with it. The view-level rename worked perfectly (diff attached).
For whatever reason the field-level
Dogrename 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)
I think you wan’t
If it didn’t warn you, that’s a problem. I’ll take a look.
How embarrassing. Thanks Lloyd.
LOVE this update
It seems that
view_labelcan be used as a parameter of
explorealso. Specifically, in version 3.48.7, the following code causes the field picker to display only “Bar” as the view:
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
exploredocumentation, where it belongs; nor is it mentioned in the documentation for
view_labeldeclared 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’)?
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:
Yes, certainly. But the very existence of a
exploreis what I was asking about. The documentation, and the original post on this page, only mention a
join, afaict. Is
explorehere to stay, despite its being essentially an Easter egg?
Ah, yes, in that case it is a “real parameter” and can basically be thought of as a view-level
view_labelthat 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!
Thanks for the info,
Is there an equivalent to a “label prefix”?
Here’s the use case:
There’s a User table. I create a view named
In the model there’s another view named
Orders have an “opening user” and a “closing user”.
So I join twice to the User table using the
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
userview has a
Does this make sense? How do I accomplish this?
Since you don’t want both User tables to get their own folder,
view_labelisn’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_prefixfit your use case? I imagine LookML like:
This is perfect!