Getting started with Looker

Best Practices

Documentation

Community

Training

Certification

Articles in this section

See more

fields (for Explores)

Avatar
Looker Support
  • Updated
Follow

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

fields can also be used as part of a join, described on the fields (for joins) parameter documentation page.

fields can also be used as part of a set, described on the set parameter documentation page.

Usage

explore: explore_name {
  fields: [
    field-or-set-specification,
    field-or-set-specification,
    …
  ]
}

Hierarchy

explore
fields

Default Value

ALL_FIELDS*

Accepts

Square brackets containing a comma-separated list of fields or sets

Special Rules

  • All fields and sets must be fully scoped (use view_name.field_name syntax)
  • Fields and sets may be excluded by preceding them with a hyphen (-)
  • Set names always end with an asterisk (*)
  • You may use the built-in set name ALL_FIELDS*, which includes all fields in the Explore
  • You may use the built-in set name view_name*, which includes all fields in the referenced view.

Definition

fields lets you 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 set 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.

Looker automatically creates a set called ALL_FIELDS*, which contains all 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] }

Looker also automatically creates sets that contain all the fields in a given view, which can be referenced with the format view_name*. For example, the following Explore includes only fields in the customers view:

explore: all_people { fields: [customers*] }

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] join: customer { sql_on: ${order.customer_id} = ${customer.id} ;; } }

Things to know

You can exclude individual items or sets of items by using fields with explore

You can use fields under the explore parameter in order to take advantage of the ALL_FIELDS* set and then exclude fields. For example:

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

We were able to reference fields from the joined view customer in the Explore level’s fields parameter by using the syntax view_name.field_name.

Using the - syntax, you can also exclude defined sets of fields:

explore: orders { fields: [ALL_FIELDS*, -users.statezip*] join: users { sql_on: ${orders.user_id} = ${users.id} ;; relationship: many_to_one } } view: users { set: statezip { fields:[state, zip] } }

The fields parameter that is part of a join cannot 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 the fields parameters under join are applied. This creates the set of fields that the Explore can choose from. Consider this example:

explore: orders { 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] 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].

Related articles