This page refers to the
fieldsparameter that is part of an
fieldscan also be used as part of an explore, described here
fieldscan also be used as part of a view, described here
fields is a child of
join is a child of
joins is a child of
|one or more field or set names|
fields at the join level enables you to specify which fields from a joined view are brought into an explore. If you do not use
fields Looker defaults to adding all fields from the view.
A list of fields may be used, like
You can also reference a set of fields (which are created by the
sets parameter), like
[set_a*]. The asterisk tells Looker that you are referencing a set name instead of a field name.
Only add the field called name from the customer view to the order explore:
Add the fields called name, address, and age from the customer view to the order explore:
Add the set of fields called order_fields from the customer view to the order explore:
fields Can Only Reference Fields From Its Own
fields will be a child of a
join, which references a view. Any dimensions or measures that are referenced in
fields must be a part of that view. For example, suppose we have:
In order to work properly, a dimension or measure called name must exist in the customer view.
Things to Know
fields Can Only Include Items When Used With
join, But Can Also Exclude Items When Used With
fields is nested under a
join parameter, you can only include fields. For example, if you had 100 fields, and you only wanted to exclude one of them, you would need to list out all 99 fields that you did want.
However, there is a better method. If you nest
explore instead, you can take advantage of the ALL_FIELDS set and then exclude fields. For example:
Notice how 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.
Different Types Of
fields Parameters Are Applied At Different Times
This page describes
fields when it is nested under a
join parameter. There is also a similar
fields parameter that is nested under
explore. When both are used at the same time, you need to understand the order in which they are applied so that you can create the desired behavior.
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:
In this case the fields that will be available are everything from orders, and name from users. This is the group of fields what would be in the
ALL_FIELDS* set (described above).
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]