fields

LookML
Version

On this Page
Docs Menu

Go to Explore Parameter List

This page refers to the fields parameter that is part of an explore

fields can also be used as part of a join, described here

fields can also be used as part of a view, described here

Usage

fields is a child of
explore
explore: view_name
...
1st
Tab
fields: [view_name.field_name]
one or more fully scoped
field or set names

Definition

fields enables you to specify which fields from an explore are exposed in the Explore UI. These fields can be in the explore’s base view or fields available from the explore’s joins. If you do not use fields, Looker defaults to exposing all fields.

A list of fields may be used like this: [view_name.field_a, view_name.field_b].

You can also reference a set of fields (which is defined in a view’s sets parameter), like [view_name.set_a*]. The asterisk tells Looker that you are referencing a set name, rather than a field name.

In both cases, please note that the field or set must be fully scoped. In other words, you must include both the view name and the field name.

There is a set called ALL_FIELDS that is automatically created, and contains all of the fields in the explore’s base view and joins. This is particularly helpful for excluding a handful of unwanted fields, like this:

- explore: view_name fields: [ALL_FIELDS*, -joined_view_name.unwanted_field]

Examples

Only show the field called name from the customer view in the customer explore:

- explore: customer fields: [customer.name]

Only show the fields called name, address, and age from the customer view in the customer explore:

- explore: customer fields: [customer.name, customer.address, customer.age]

Only show the set of fields in the export_fields set, from the customer view, in the customer explore:

- explore: customer fields: [customer.export_fields*]

Exclude the field called status in the customer view from the order explore:

- explore: order fields: [ALL_FIELDS*, -customer.status] joins: - join: customer sql_on: ${order.customer_id} = ${customer.id}

Things to Know

The fields Parameter That Is Part Of A join Can’t Use the ALL_FIELDS Set

This page refers to the fields parameter that is a child of explore. When used in this way, you can access the ALL_FIELDS set, then exclude unwanted fields as shown above.

There is also a fields parameter that is a child of join. When used in that fashion, you cannot use the ALL_FIELDS set.

The ALL_FIELDS Set Is Limited By The fields Parameter That Is Part Of A join

This page describes fields when it is nested under an explore parameter. There is also a similar fields parameter that is nested under join. It’s important to understand the implications of applying fields to both levels at the same time.

First, all of the fields parameters under join are applied. This creates the set of fields that the explore can choose from. Consider this example:

- explore: orders joins: - join: users fields: [name] sql_on: ${orders.user_id} = ${users.id}

In this case:

  • All fields from orders will be available, and included in ALL_FIELDS*
  • name from users will be available, and included in ALL_FIELDS*
  • Other fields in users would not be available or included in the ALL_FIELDS* set

Now, if we add a fields parameter under explore, we’re adding a restriction on top of that set. Suppose we did this:

- explore: orders fields: [orders.price, users.address] joins: - join: users fields: [name] sql_on: ${orders.user_id} = ${users.id}

In this case:

  • price from orders will show up as expected, because it is in the ALL_FIELDS* set we created
  • address from users won’t show up, because it wasn’t included when users was joined in (only name was)
  • name from users won’t show up either, because we didn’t add it to the explore in the row fields: [orders.price, users.address]
Still have questions?
Go to Discourse - or - Email Support
Top